[PD] Switch from PureData!
Mathieu Bouchard
matju at artengine.ca
Wed May 11 00:53:52 CEST 2011
On Mon, 2 May 2011, Jonathan Wilkes wrote:
> Now it's perfectly fine that it shows one example that gives the
> strengths of supercollider and a completely different example for the
> strengths of pure data. But it certainly begs the question
http://en.wikipedia.org/wiki/Begging_the_question
> what each example would look like in the other enviroment.
> So: what's the simplest way to implement that supercollider example
> above using pure data? Using nqpoly? Dynamic patching? Is there a #many~
> in GF? Etc.
[#many] is designed to be used for GUI objects. There's nothing preventing
it from being used for non-GUI objects, except that it currently requires
objects that support the 'receive' and 'send' methods, for setting
receive-symbols and send-symbols, and that is pretty much limited to the
IEMGUI family, currently.
Would [#many~]'s components have signal-outlets, signal-inlets, or both ?
Would the grid-input ever represent the right-inlet configurations of N
objects, if those objects each have a left-inlet common signal input ?
etc. I think that there would be several different useful combinations of
[#many]-style concepts with signals.
You can process multiple channels using a single chain terminated by
[#to~], without dynamic patching and perhaps even faster than Pd's DSP,
but it requires doing that using only GridFlow objects, because in the
GridFlow framework, there's a lot of stuff that compute 1 channel or N
channels in the same manner, without any copy-paste. But there's no
ready-to-use equivalent of [osc~] made with grids... you'd have to build
one by yourself, as an abstraction.
_______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
More information about the Pd-list
mailing list