HI, the attached patch demonstrates a speed issue, of which i am surprised to be an issue with modern computers. It seems that the fastest time to count from 0 to 30 is 310 ms. If I go faster some numbers are omitted. (actually there are already some number drop outs, but 13 is still in - i was trying to detect CarriageReturns / ascii 13 in Serial communication)
There is probably a formula that takes vector size into account to compute the max. speed i can rely on.
Or maybe i there is a programming mistake?
On 1/11/19 12:09 PM, michael strohmann wrote:
HI, the attached patch demonstrates a speed issue, of which i am surprised to be an issue with modern computers. It seems that the fastest time to count from 0 to 30 is 310 ms.
i don't see any counting in your patch. [line] is for interpolation between numbers over time. if you want to count, you should use [+].
If I go faster some numbers are omitted. (actually there are already some number drop outs, but 13 is still in - i was trying to detect CarriageReturns / ascii 13 in Serial communication)
There is probably a formula that takes vector size into account to compute the max. speed i can rely on.
Or maybe i there is a programming mistake?
could you post an example that doesn't require externals (no cyclone)?
gf,rdsa IOhannes
ok, then there might be the problem. i was thinking that [line] runs thru ALL the numbers in different speeds.
which, come to think of it, might be a problem if i ask it to run from 0 to 100000 in 10 ms.
so, what is the actually algotithm the [line] object is using?
On 11 Jan 2019, at 12:30, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 1/11/19 12:09 PM, michael strohmann wrote:
HI, the attached patch demonstrates a speed issue, of which i am surprised to be an issue with modern computers. It seems that the fastest time to count from 0 to 30 is 310 ms.
i don't see any counting in your patch. [line] is for interpolation between numbers over time. if you want to count, you should use [+].
If I go faster some numbers are omitted. (actually there are already some number drop outs, but 13 is still in - i was trying to detect CarriageReturns / ascii 13 in Serial communication)
There is probably a formula that takes vector size into account to compute the max. speed i can rely on.
Or maybe i there is a programming mistake?
could you post an example that doesn't require externals (no cyclone)?
gf,rdsa IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Fri, 2019-01-11 at 13:20 +0100, michael strohmann wrote:
ok, then there might be the problem. i was thinking that [line] runs thru ALL the numbers in different speeds.
No.
which, come to think of it, might be a problem if i ask it to run from 0 to 100000 in 10 ms.
That's not the problem. You can create something in Pd that counts to 100'000 in zero logical time. Your initial question suggests that you lack an understanding of some fundamental design aspects of Pd. One important thing to know is that Pd does everything in a deterministic manner. Regardless of whether it runs on a very slow or very fast computer, the generated results are always the same. The only difference is that it might be able to do it in real time on one computer while it suffers drop-outs and glitches on another. When you know that, you know that the rate at which [line] is emitting numbers is not related to the speed of the CPU.
Forgive me if I sound patronizing, but let me say it anyway: Pd is much more fun when you understand how it works. Read at least the manual that is shipped along with the software.
so, what is the actually algotithm the [line] object is using?
Check the help of line. I cannot explain it better than that. Key words are 'time grain' and 'grain rate'.
Roman
On Friday, January 11, 2019, 8:12:46 AM EST, Roman Haefeli reduzent@gmail.com wrote:
so, what is the actually algotithm the [line] object is using?
Check the help of line. I cannot explain it better than that. Key words
are 'time grain' and 'grain rate'.
Hi Roman, What does "grain rate" mean? Specifically-- if the default grain rate is 20ms, what does that mean for the schedule upon which [line] will output messages over the course of a given ramp's duration?
-Jonathan
Roman
On Sat, 2019-01-12 at 20:44 +0000, Jonathan Wilkes wrote:
On Friday, January 11, 2019, 8:12:46 AM EST, Roman Haefeli <
reduzent@gmail.com> wrote:
so, what is the actually algotithm the [line] object is using?
Check the help of line. I cannot explain it better than that. Key
words are 'time grain' and 'grain rate'.
Hi Roman,
What does "grain rate" mean?
The rate at which [line] outputs an update of the current value. I'd probably call the second argument "grain period" as "grain rate" implies a frequency.
Specifically-- if the default grain rate is 20ms, what does that mean for the schedule upon which [line] will output messages over the course of a given ramp's duration?
I'm not sure I fully understand what your asking. Upon receiving a two- float list, [line] starts sending out messages at the given rate. The time period between the message reflects the second argument, except for the time period between the second to last and last message where the period might be shorter so that the sum of all grains equals the ramp time given.
Roman
On Sunday, January 13, 2019, 4:16:38 PM EST, Roman Haefeli reduzent@gmail.com wrote:
I'm not sure I fully understand what your asking. Upon receiving a two-
float list, [line] starts sending out messages at the given rate. The time period between the message reflects the second argument, except for the time period between the second to last and last message where the period might be shorter so that the sum of all grains equals the ramp time given. I don't believe you can deduce that behavior from the help file for [line]: https://github.com/pure-data/pure-data/blob/master/doc/5.reference/line-help...
I think your description above is a much better response to the question of, "what is the algorithm" than the link you provided the OP. It's also a better response to the question, "what is the behavior of [line]?" So I think it belongsin the help file for [line] (and I'll add something like it in Purr Data[1]). -Jonathan
Roman
michael strohmann wrote:
ok, then there might be the problem. i was thinking that [line] runs thru ALL the numbers in different speeds.
[line] is definitely the wrong tool for your task. it works basically the same like MAX's [line 0. 20], meaning it outputs float numbers and has a grain size of 20 by default. so there's always some interpolation at work, which will result in missing numbers.
to reliably get numbers from 0 - 30 i attached 3 easy examples (one of them uses IEMLIB's [for++] which is exactly what you're looking for), the others are vanilla.
mind that the [bang~] driven counter is driven by PDs blocksize (default 64), which you could also change in a subpatch to make it faster or slower.
best
oliver
-
IOhannes m zmölnig -
Jonathan Wilkes -
michael strohmann -
oliver -
Roman Haefeli