> The attached patch lets you see Pd's "control rate" in action.
this is not the best way to measure this, cause [*~ 0] is not able to convert data to audio as you expect, it's best to use [vline~]. cheers 2015-03-13 14:55 GMT-03:00 Martin Peach <chakekat...@gmail.com>: > On Fri, Mar 13, 2015 at 3:51 AM, Alexandre Torres Porres <por...@gmail.com > > wrote: > >> >> About the "control rate" paradigm in Pd, I have to admit that when I >> asked about it I was thinking about it in relation to what that means in >> supercollider and Csound, but I also always considered that Pd doesn't >> really have that kind of "control rate" per se. It's nice that we can look >> deeply into what it all means in the Pd context. >> >> But yeah, I think everyone gets the question anyway, but the final >> detailed answer is still out there somewhere. >> >> This is what I get so far, anyway: By thinking of more of a general >> concept from the SC/Csound realm, a control rate is something that is >> slower than audio rate and it doesn't make sense that it can go higher than >> audio rate (thus some may consider it "curious"). Simply put, since Pd >> does not have this kind of paradigm in its structure, control messages have >> no real boundary and are free to be fired at any rate that your computer >> can manage and restricted only to bit float limitations. >> >> By making it more straightforward, it has no limits, it can go faster >> than you'll ever need it to until it kills your CPU. >> >> The attached patch lets you see Pd's "control rate" in action. It shows a > graph of a wave being chopped at control rate. It won't chop any faster > than about 1ms and it's irregular. > > Martin >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list