That would be excellent to hear about useful forgotten patches.
In the meantime maybe I can hijack this thread with a practical question. Look at the supercollider and pure data example at the beginning of the following tutorial:
http://en.flossmanuals.net/pure-data/ch002_graphical-programming/
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 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.
-Jonathan
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
--- On Wed, 5/11/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Switch from PureData! To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Derek Holzer" derek@umatic.nl, pd-list@iem.at Date: Wednesday, May 11, 2011, 12:53 AM 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
I meant "raises 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.
Do you have an example other than #to~-help.pd that I can look at?
-Jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
Jonathan Wilkes -
Mathieu Bouchard