[PD] [zyx-patchbay] graphical patchbay/router for control and signal connections.

[dmotd]

hi folks,

it's the start of a new year and i've had some free time to work on pd
stuff after a long break.

wanting to get myself back in the data structures head-space, i
developed this little project, a graphical patchbay/router for control
and signal connections.

the premise is pretty simple, the interface provides a symbolic
representation of an object pool which is created dynamically - when you
make connections through the interface those same connections are
created in the object pool.

the main patch is 'zyx-patchbay.pd', which has a GOP container holding
the data-structure, a subpatch holding the object pool and a subpatch
for the logic.

the secondary patches are 'zyx-pbi.pd', 'zyx-pbo.pd', 'zyx-pbi~.pd' and
'zyx-pbo~.pd', which act as wrappers to objects (typically
s/r/s~/r~/throw~/catch~) and dynamically insert themselves into the
patchbay object pool. there is an example patch for these objects at
'patchbay-test.pd'.

i use the patchbay to provide a single patching interface for
connections that may be scattered over many patches or in hard to reach
places, for example to quickly reroute a signal generator to an effect
and back to the dac. this has been particularly useful on the
constricted screen space of my n900 phone, which also tends to be
painful to draw connections manually.

some features:
* purepd (tested in 0.43 and 0.42-6)
* colour coded object handles
* multiple object handles can be selected to connect to another object
* objects handles can be dragged around and rearranged for better
readability (drag the tip of a connection wire or use edit mode to move
object handles within data structure window).
* state saving between saves - the object pool and connections are
maintained and it's still possible to add more object handles.
* full $0 namespace handling in case someone wants to hack it into a
multiple instance GOP.

some pitfalls:
* currently no safeguards for bad connections (signal to wire etc).
* arbitrary width of object handle - this is set to 50px, i've begun
experimenting with allowing the width to be dragged but but it will
require more tinkering to get right.
* fixed GOP window size for patchbay interface - a trivial change but
i've not needed to alter this yet and dynamically altering GOP can have
some undesired consequences.

i know that there are folks on this list that would consider this patch
set blasphemous for using dynamic construction and abstracted interface
to obscure workflow, but it fulfills my requirements and hopefully
others will find it useful. if anything it's another example of
data-structures that people can learn from or tear apart.

i'm going to use the prefix 'zyx' for abstractions, so there aren't any
namespace clashes, if you want to edit and release your own version
please use a different prefix.

i welcome any questions, comments or feature requests!

cheers,
dmotd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zyx-patchbay.zip
Type: application/zip
Size: 13417 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120113/495aaf70/attachment-0001.zip>