On Tue, 28 Jan 2003, Thomas Grill wrote:
It's important if one wants to move away from the visual top-in bottom-out style. For many applications flexible polyphonic sound production is necessary and vital. I suggest to have a look at the SuperCollider language which has the ability to create massively parallel patches, with fully dynamical voice allocation - this is really impressing, but otoh the scripts can be quite hard to comprehend.
One major feature missing from PD/jMax is special objectboxes that have subpatchers as arguments. This would give PD/jMax more of the flexibility that other dataflow environments such as LabView has.
(Note: I haven't tried LabView yet).
Then it would be easy to specify massive and/or variable-width parallelism.
If there is no such feature, then the way out is using lists and vector-values and create a lot of new classes that behave like the existing ones except that they operate like N objects of the same class at once. This would not require changing PD/jMax itself. It would be a lot of effort to make all classes work this way, and it's not really doable, and there are things that are more difficult to do with this approach than the ones above. However there are also advantages (speed).
The PD/jMax external closest to that latter ideal is, of course, GridFlow. But it's not like GridFlow can even get close to that ideal because there are way too many classes/externals to rewrite, and it does not handle DSP at all, etc.
So it gets me back to the subpatcher-as-argument. Let's see what would be required to get there.
jMax already has subpatchers; you double-click on it and a separate window opens; however the subpatcher is stored in the same file as the patcher. PD could get this feature.
(the advantage of jMax stops here.)
Then it would be good for abstractions to be embeddable in the same file as a main patcher. The difference between a subpatcher and an abstraction is that an abstraction may have several instances of itself inside the same patcher. The advantage of embedding abstractions is that it makes it more convenient (or less inconvenient) to build heavily structured patch-systems; you can put what would be 42 different .pd files inside only one, no need to give it a directory of its own, no use for zipping it to distribute it.
Then it would be good to allow visually-embedded subpatchers. Then allow non-text inside objectboxes (so that I can put matrix literals inside object boxes in a nice form; see game_of_life.pd to get an idea of how ugly matrix-literals may get). Then allow processing-objects inside objectboxes; this implies subpatchers (incl. the visually-embedded ones) are allowed inside objectboxes.
From there it would be nice to have an object that can vectorize GUI
objects so that I can get a matrix of checkboxes or a vector of sliders.
I actually often wish I had some kind of vector-of-sliders in jMax that would send out lists of integers. I have a use for that, as I often copypaste sliders and align them side-to-side and pack their outputs into vectors.
I would also wish the same for PD, but I don't really use PD, for several reasons. (if PD had some of the above features I could quickly consider it as superior to jMax)
That's why i'm developing dyn~ right now. It's a very simple approach to dynamically manage all kinds of pd objects invisibly inside an external. It can serve as a poly~ but also for other applications.
May you explain how dyn~ would work?
Mathieu Bouchard http://artengine.ca/matju