[PD] Pd and jack (again)

[Mathieu Bouchard]

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.