[PD] maximum "control rate" in Pd

Martin Peach chakekatzil at gmail.com
Fri Mar 13 20:43:51 CET 2015


Yes with [vline~] it goes finer, but try using numbers around 756 in the
upper number box in this patch, I get long intervals, it's as though the
control rate is aliasing.

Martin

On Fri, Mar 13, 2015 at 3:16 PM, Alexandre Torres Porres <porres at gmail.com>
wrote:

> > 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 <chakekatzil at gmail.com>:
>
> On Fri, Mar 13, 2015 at 3:51 AM, Alexandre Torres Porres <porres at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150313/ec8f5728/attachment.html>
-------------- next part --------------
#N canvas 314 466 825 322 10;
#X obj 178 117 metro 100;
#X obj 40 272 tabwrite~ \$0-wave;
#X obj 178 94 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X obj 59 115 metro 1;
#X obj 59 8 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1
;
#X obj 170 272 table \$0-wave 1000;
#X obj 40 209 noise~;
#X text 303 273 <- click here to se the table;
#X text 197 92 <-start writing to the table;
#X text 80 6 <-start chopping the sound;
#X obj 424 10 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X msg 424 42 \; pd dsp \$1;
#X text 444 9 <- start dsp;
#X obj 59 176 vline~;
#X obj 40 232 *~;
#X obj 59 140 f;
#X obj 88 140 + 1;
#X obj 117 140 % 2;
#X floatatom 105 32 5 0 0 0 - - -, f 5;
#X obj 105 51 * 1e-005;
#X floatatom 119 83 9 0 0 0 - - -, f 9;
#X connect 0 0 1 0;
#X connect 2 0 0 0;
#X connect 3 0 15 0;
#X connect 4 0 3 0;
#X connect 6 0 14 0;
#X connect 10 0 11 0;
#X connect 13 0 14 1;
#X connect 14 0 1 0;
#X connect 15 0 16 0;
#X connect 15 0 13 0;
#X connect 16 0 17 0;
#X connect 17 0 15 1;
#X connect 18 0 19 0;
#X connect 19 0 3 1;
#X connect 19 0 20 0;


More information about the Pd-list mailing list