4 ms·

"As with most DSP software, there are two primary rates at which data is passed: sample (audio) rate, usually at 44,100 samples per second, and control rate, at

"As with most DSP software, there are two primary rates at which data is passed: sample (audio) rate, usually at 44,100 samples per second, and control rate, at 1 block per 64 samples" (https://en.wikipedia.org/wiki/Pure_Data https://en.wikipedia.org/wiki/Pure_Data) This is actually kind of annoying with Pd as it's not always clear what rate an object is running at.

jancsika 8y ago
Can you give an example? I maintain a fork of Pd, and I'm still not clear what the Sporth author, that Wikipedia article, nor you are talking about.
- jdmoreira 8y ago
  I've never used Pd or any of the others so I'm guessing here. Could it be the equivalent to an 'lfo input'. The rate at which it controls parameters?
  - jancsika 8y ago
    That could be the implication, but it's not the way Pd works. For example, when you make a signal connection (thick wires) in Pd you immediately get a signal "flowing" through that part of the diagram. It is similar to making a connection between two modules on a Buchla synthesizer. That is very useful for prototyping because you immediately get aural feedback as you connect things together. (It's also efficient because you are doing computation on vectors of data.) That doesn't happen with control objects in Pd. When you make a control connection (thin wires) no function gets called until you somehow trigger an event that causes the object to output some data. That is very useful for prototyping because you can make arbitrary turing-complete scripts full of branches of heterogeneous data which only get computed sporadically. I guess someone could write a library cloning the core DSP objects and have them do "control rate" computations. That is, have them do a single computation per block, and copy that value for the remaining samples of the block. I imagine no one has done that for the same reason Pd only has a single numeric (float) type-- it's good enough as is.
- pierrec 8y ago
  OK, an example is trying to use threshold~ to sculpt a wave. You can't, because threshold~ is supposed to be a "control" object and runs at control rate. https://forum.pdpatchrepo.info/topic/7906/control-as-signal-generator https://forum.pdpatchrepo.info/topic/7906/control-as-signal-...
  - jancsika 8y ago
    Ah, I see what you're talking about now. There are indeed a handful of classes-- some in d_ctl.c-- (and probably externals, too) which take signal input and output some message like "bang" on block boundaries (by using a clock callback). Still, there's no "control rate"-- "threshold~" doesn't output data every block. It outputs data only when the threshold value is exceeded, quantized to block boundaries. At least in my fork (Purr Data), the control outlets are visually distinct from signal outlets. So upon instantiating [threshold~] you can immediately see that it doesn't output signal data.

jancsika 8y ago

Can you give an example? I maintain a fork of Pd, and I'm still not clear what the Sporth author, that Wikipedia article, nor you are talking about.

jdmoreira 8y ago
I've never used Pd or any of the others so I'm guessing here. Could it be the equivalent to an 'lfo input'. The rate at which it controls parameters?
- jancsika 8y ago
  That could be the implication, but it's not the way Pd works. For example, when you make a signal connection (thick wires) in Pd you immediately get a signal "flowing" through that part of the diagram. It is similar to making a connection between two modules on a Buchla synthesizer. That is very useful for prototyping because you immediately get aural feedback as you connect things together. (It's also efficient because you are doing computation on vectors of data.) That doesn't happen with control objects in Pd. When you make a control connection (thin wires) no function gets called until you somehow trigger an event that causes the object to output some data. That is very useful for prototyping because you can make arbitrary turing-complete scripts full of branches of heterogeneous data which only get computed sporadically. I guess someone could write a library cloning the core DSP objects and have them do "control rate" computations. That is, have them do a single computation per block, and copy that value for the remaining samples of the block. I imagine no one has done that for the same reason Pd only has a single numeric (float) type-- it's good enough as is.
pierrec 8y ago
OK, an example is trying to use threshold~ to sculpt a wave. You can't, because threshold~ is supposed to be a "control" object and runs at control rate. https://forum.pdpatchrepo.info/topic/7906/control-as-signal-generator https://forum.pdpatchrepo.info/topic/7906/control-as-signal-...
- jancsika 8y ago
  Ah, I see what you're talking about now. There are indeed a handful of classes-- some in d_ctl.c-- (and probably externals, too) which take signal input and output some message like "bang" on block boundaries (by using a clock callback). Still, there's no "control rate"-- "threshold~" doesn't output data every block. It outputs data only when the threshold value is exceeded, quantized to block boundaries. At least in my fork (Purr Data), the control outlets are visually distinct from signal outlets. So upon instantiating [threshold~] you can immediately see that it doesn't output signal data.