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
Hi,
another pitfall, after selecting a receive-send pair, if you click another
receive, the last selected send will still be active, and the connection
will be made with only 1 click. Or maybe this is more clear:
- create "in receive foo1", "out send bar", "in receive foo2"
- make a connection by clicking foo1 and bar
- if you now press foo2, bar will connect with it.
A way to prevent unwanted connections would be to force the left->right
connection order.
Wouldn't it make more sense to put the sends in the left side, and the
receives in the right side? (unless for arabic or hebrew speakers)
Nice patch, I've done a similar one to manage jack connections in my
ardourjack-gui, but without the nice data-s gui with cables and dynamic
patching, just a dynamic list of sends/receives. The graphical part would
be the next step, but for now I'm not using ubuntu that often.
The [ardourjack-gui] is packed only with 0.43-ext, but a version is here.
You can use it to both control ardour from pd, and to create/delete jack
connections. It only works with linux, as it relies on [ggee/shell] (last
time I tried it in macos it didn't work).
João
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
On Fri, 2012-01-13 at 11:09 +0100, João Pais wrote:
Hi,
another pitfall, after selecting a receive-send pair, if you click another
receive, the last selected send will still be active, and the connection
will be made with only 1 click. Or maybe this is more clear:
- create "in receive foo1", "out send bar", "in receive foo2"
- make a connection by clicking foo1 and bar
- if you now press foo2, bar will connect with it.
A way to prevent unwanted connections would be to force the left->right
connection order.
it's a design choice, you can untoggle 'bar' by clicking it twice. a future release will auto-untoggle with a delay. i leave 'bar' toggled in this case as it becomes easy to disconnect the wore by clicking foo1 again.
Wouldn't it make more sense to put the sends in the left side, and the
receives in the right side? (unless for arabic or hebrew speakers)
this concept seems backwards, yes, but as the patchbay is only acting as a go between using s/r pairs the roles get reversed. it makes more sense if you say add an 'out dac~ 1' or 'in adc~ 1' (this causes a type mismatch here, as '1' is not a float not a valid symbol, but you get the idea). essentially you're going from somewhere (left) to somewhere (right), but yeah i get your point - it's confusing!
Nice patch, I've done a similar one to manage jack connections in my
ardourjack-gui, but without the nice data-s gui with cables and dynamic
patching, just a dynamic list of sends/receives. The graphical part would
be the next step, but for now I'm not using ubuntu that often. The [ardourjack-gui] is packed only with 0.43-ext, but a version is here.
You can use it to both control ardour from pd, and to create/delete jack
connections. It only works with linux, as it relies on [ggee/shell] (last
time I tried it in macos it didn't work).
feel free to rip the guts out of it if you think you can make the gui work with the jack manager, most of the concepts will be pretty similar.
thanks for the feedback :)
João
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
dmotd -
i go bananas -
João Pais -
Patrick King