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@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@gmail.com>:

On Fri, Mar 13, 2015 at 3:51 AM, Alexandre Torres Porres <porres@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