4 ms·

> There is no concept of a control rate signal, a traditional feature in other computer-music languages like Csound, SuperCollider, MaxMSP, or PD. Hm... what i

> There is no concept of a control rate signal, a traditional feature in other computer-music languages like Csound, SuperCollider, MaxMSP, or PD. Hm... what is a control rate signal in Pd?

pierrec 8y ago
"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.
zebproj 8y ago
In PD, the normal thin cables carry control-rate signals. The thicker cables are the audio-rate cables. Objects like "osc~" and "+~" produce audio-rate signals. Objects like "mtof" and "stripnote" produce control-rate signals.
- jancsika 8y ago
  > Objects like "mtof" and "stripnote" produce control-rate signals. A theoretical "control-rate" "mtof" object would take its input value and compute a frequency value once every block when DSP is turned on. But that's not what "mtof" does. Instead, it computes the frequency for an inputted MIDI value at the time it receives that value. That time could be once every block, once a minute, a single time when I load the program, at random intervals on Tuesday, or even never. The thin line boxes constitute a kind of visual procedural scripting language. Kind of like shell scripting if pipes could have multiple prongs fanning out into multiple destinations.
  - zebproj 8y ago
    > A theoretical "control-rate" "mtof" object would take its input value and compute a frequency value once every block when DSP is turned on. In Sporth, the "mtof" unit-generator does a MIDI to frequency conversion for every audio sample, thus making it audio rate. Perhaps it is better to think of control-rate signals as input signals rather than output signals. The "osc~" object, for instance, will update the frequency at every audio block. This would be the control rate. In Sporth, oscillator frequency values are updated every sample inside the audio block. > But that's not what "mtof" does. Instead, it computes the frequency for an inputted MIDI value at the time it receives that value. That time could be once every block, once a minute, a single time when I load the program, at random intervals on Tuesday, or even never. The important distinction here is that the resolution can't be smaller than the audio-block size, which in turn defines the control-rate.
    - jancsika 8y ago
      > The "osc~" object, for instance, will update the frequency at every audio block. You're just talking about sending a float from a control object to "osc~", right? To be clear: If "osc~" is receiving a float atom from a control object (thin line), then yes, it will implicitly convert that float to an input vector on block boundaries. If "osc~" is receiving signal data from a DSP object (thick line), every sample of the input is used to calculate every sample of the output. If "osc~" is receiving signal data from "vline~", the user can supple subsample accurate frequency changes to "osc~" bound by the precision of float precision, at the expense of performance.

> There is no concept of a control rate signal, a traditional feature in other computer-music languages like Csound, SuperCollider, MaxMSP, or PD. Hm... what is a control rate signal in Pd?

pierrec 8y ago

"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.

zebproj 8y ago

In PD, the normal thin cables carry control-rate signals. The thicker cables are the audio-rate cables. Objects like "osc~" and "+~" produce audio-rate signals. Objects like "mtof" and "stripnote" produce control-rate signals.

jancsika 8y ago
> Objects like "mtof" and "stripnote" produce control-rate signals. A theoretical "control-rate" "mtof" object would take its input value and compute a frequency value once every block when DSP is turned on. But that's not what "mtof" does. Instead, it computes the frequency for an inputted MIDI value at the time it receives that value. That time could be once every block, once a minute, a single time when I load the program, at random intervals on Tuesday, or even never. The thin line boxes constitute a kind of visual procedural scripting language. Kind of like shell scripting if pipes could have multiple prongs fanning out into multiple destinations.
- zebproj 8y ago
  > A theoretical "control-rate" "mtof" object would take its input value and compute a frequency value once every block when DSP is turned on. In Sporth, the "mtof" unit-generator does a MIDI to frequency conversion for every audio sample, thus making it audio rate. Perhaps it is better to think of control-rate signals as input signals rather than output signals. The "osc~" object, for instance, will update the frequency at every audio block. This would be the control rate. In Sporth, oscillator frequency values are updated every sample inside the audio block. > But that's not what "mtof" does. Instead, it computes the frequency for an inputted MIDI value at the time it receives that value. That time could be once every block, once a minute, a single time when I load the program, at random intervals on Tuesday, or even never. The important distinction here is that the resolution can't be smaller than the audio-block size, which in turn defines the control-rate.
  - jancsika 8y ago
    > The "osc~" object, for instance, will update the frequency at every audio block. You're just talking about sending a float from a control object to "osc~", right? To be clear: If "osc~" is receiving a float atom from a control object (thin line), then yes, it will implicitly convert that float to an input vector on block boundaries. If "osc~" is receiving signal data from a DSP object (thick line), every sample of the input is used to calculate every sample of the output. If "osc~" is receiving signal data from "vline~", the user can supple subsample accurate frequency changes to "osc~" bound by the precision of float precision, at the expense of performance.