This is from the jmax list ( a post by John Whitley) and I had some questions about the description of PD.
<snipped portion describes block~ for jmax users>
Miller's DSP graph abstraction technique solves a problem that has been bugging me for years: how, within the visual language of Max, to avoid needless rote duplication.
A class that abstracts over a portion of the DSP graph can have considerable expressive power. Two more sample applications of this technique immediately come to mind:
"voice~" A voxalloc class reimplemented via DSP graph abstraction within a patcher. voice~'s leftmost input is a control data input, similar to the current voxalloc. Other inputs are duplicated in a straightforward fashion. The contents of the patcher represents a single prototypical voice, duplicated according to the number of voices required. Each voice is transparently switch~'ed on only when required, and the outputs of all voices are summed as with block~.
A "bus~ <N>" class, that causes N copies of the patcher to be connected in series, the output of each connected to the input of the next. (Offhand, I recall seeing a Shepard tone patch on the ISPW that used this bus technique.)
Is the block~ object the only one that implements this type of abstraction at the moment? Has anyone done something like voice~? Any clarification about how this is currently implemented would be appreciated.
Karl
Karl MacMillan writes:
Is the block~ object the only one that implements this type of abstraction at the moment? Has anyone done something like voice~? Any clarification about how this is currently implemented would be appreciated.
AFAIK, block is the only object that uses the "summing outlets". We had a short discussion some time ago about the problem of multiple voices. It somehow vanished as soon as it came up. I think it's definitely possible to write something like that based on the mechanism used in block~.
Having the necessary amount of spare time to do it is another problem .....
Guenter