[PD] Switch from PureData!

[Mathieu Bouchard]

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