undefined | Better HN

0 pointsssfrr8y ago0 comments

I think the issue of control rate in PD is often confusing for folks, because there isn’t any “control rate” that is fundamental to the language. There are audio rate signals that are processed every block, and there are messages that get handled ASAP when they are received, and are decoupled from the audio rate graph. These messages could be once an hour or once per millisecond. The control rate thing comes up because most PD objects (e.g. osc~) only update their parameters on block boundaries, which creates timing jitter (variable delay between when a message is received and when it takes effect). You could definitely have an audio-rate object that took into account the precise timing of the messages it received and scheduled the parameter changes a constant amount of time in the future, which eliminates jitter at the expense of a fixed latency. The vline~ object is useful for generalizing this approach to any object that can take audio-rate parameters, but there’s no reason you couldn’t make a vosc~ object that had the functionality built in.

This is different from supercollider (and I think sound), which have an explicit control rate.

0 comments

1 comments · 1 top-level

jancsika8y ago

> The control rate thing comes up because most PD objects (e.g. osc~) only update their parameters on block boundaries, which creates timing jitter (variable delay between when a message is received and when it takes effect).

Just to reiterate so that people don't get confused:

If you give signal input to "osc~"-- let's say `[noise~]--[osc~]`, then "osc~" will update its frequency parameter every sample. If "osc~" didn't do that it would be a lot cheaper (because you'd only need to do one calculation and copy it 64 times at default blocksize), but you would of course immediately hear the loss in quality.

What you are describing is what happens when you send a message containing a single floating point number payload to the input of "osc~." In that case Pd treats that number as if it were a vector of samples all with that same value. That's fast and cheap.

> there’s no reason you couldn’t make a vosc~ object that had the functionality built in.

You can do that. But it's interesting to dissect it a bit:

* "vosc~" would only see a performance bump over `[vline~]--[osc~]` in cases where you aren't sending a signal to the input. (Because if you are sending input, the code that does precision timing of control messages is wasted cycles.) So you'd probably want to make the input a control input that can't take signals.

* With "vline~", users can control the ramp by putting more objects in between "vline~" and "osc~". But with "vosc~" they'd be stuck either with the default linear interpolation, or a selection of interpolation schemes that you code into the object. In other words, potential functionality moves from userspace to compiled classspace.

Edit: remove duplicated thingy

j / k navigate · click thread line to collapse