Re: [PD] speed
> On Sunday, January 13, 2019, 4:16:38 PM EST, Roman Haefeli > 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.pd 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 [1] https://git.purrdata.net/jwilkes/purr-data/issues/498 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] speed
On Sat, 2019-01-12 at 20:44 +, Jonathan Wilkes wrote: > >On Friday, January 11, 2019, 8:12:46 AM EST, Roman Haefeli < > reduz...@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 signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] speed
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 #N canvas 247 273 645 308 10; #X obj 81 149 until; #X msg 119 124 0; #X obj 81 172 f; #X obj 109 173 + 1; #X obj 81 100 t b b; #X obj 81 255 print UNTIL; #X msg 81 125 31; #X msg 465 143 0; #X obj 405 171 f; #X obj 433 172 + 1; #X obj 396 118 bang~; #X obj 438 93 t b b; #X msg 438 118 1; #X obj 405 143 spigot; #X obj 438 236 print BANG~; #X obj 514 65 loadbang; #X msg 514 88 \; pd dsp 1; #X obj 81 46 bng 40 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 438 45 bng 40 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 405 194 sel 31; #X msg 405 237 0; #X obj 342 237 realtime; #X floatatom 342 261 5 0 0 0 - - -, f 5; #X obj 19 233 realtime; #X floatatom 19 257 5 0 0 0 - - -, f 5; #X obj 64 208 sel 30; #X obj 213 45 bng 40 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 213 96 t b b; #X obj 240 168 realtime; #X floatatom 240 192 5 0 0 0 - - -, f 5; #X obj 213 218 print FOR++; #X msg 272 53 1; #X msg 280 76 0.5; #X obj 213 139 for++ 0 30 1; #X text 275 31 "speed"; #X msg 290 100 0.25; #X connect 0 0 2 0; #X connect 1 0 2 1; #X connect 2 0 3 0; #X connect 2 0 5 0; #X connect 2 0 25 0; #X connect 3 0 2 1; #X connect 4 0 6 0; #X connect 4 1 1 0; #X connect 4 1 23 0; #X connect 6 0 0 0; #X connect 7 0 8 1; #X connect 8 0 9 0; #X connect 8 0 19 0; #X connect 9 0 8 1; #X connect 10 0 13 0; #X connect 11 0 12 0; #X connect 11 1 7 0; #X connect 11 1 21 0; #X connect 12 0 13 1; #X connect 13 0 8 0; #X connect 15 0 16 0; #X connect 17 0 4 0; #X connect 18 0 11 0; #X connect 19 0 20 0; #X connect 19 0 21 1; #X connect 19 1 14 0; #X connect 20 0 13 1; #X connect 21 0 22 0; #X connect 23 0 24 0; #X connect 25 0 23 1; #X connect 26 0 27 0; #X connect 27 0 33 0; #X connect 27 1 28 0; #X connect 28 0 29 0; #X connect 31 0 33 2; #X connect 32 0 33 2; #X connect 33 0 30 0; #X connect 33 1 28 1; #X connect 35 0 33 2; ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] speed
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 10 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 signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] speed
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 10 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 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] speed
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? PD_SpeedTest.pd Description: Binary data ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
