Joe Bell

Does anyone have any systems they would like to share for opening up subpatches 'on the fly'? How to manage the control interface, for example I assume some people have the control objects pop up when you load up a particular subpatch? Does anyone have a system for dynamically allocating the names of "s" and "r" for routing signals to a centralised 'patch bay' of controller objects?

I'm really interested to research flexible ways of managing processes that could be audio or visual or both, and making chains of effects where I can control key parameters (the tricky bit being the fact that the number and type of controls would have to be flexible).

systems-for-controlling-and-routing-sub-patches-opened-up-on-the-fly

There are so many ways to do this, it's tough to give an answer. It depends on a lot of factors: how many you might want, how complex they are, how cluttered or clean you want the patch, etc. One route is to have many subpatches, so the main patch has them all within it, and small variations (like having different presets) are possible in each. Another route is to have bpatchers, so you have an external file to the main patch, but can have tons of them easily and if you want to edit, you only change the master one. Pros and cons to both.

Definitely use "open" and "close" to pcontrol to your subpatches, since this is easier than a double-click and looks more intuitive than the actual object. Also these can be activated remotely, or with a keystroke... and a special one might close all of them, for example. This is a great time-saver even while developing, not just for the finished interface.

Look into floating vs. non-floating windows for the subpatch / controls, though with the caveat that text can't be entered into a floating window... like command-V for paste doesn't work, for example, nor can you type anything else in. Strange at first... only the mouse is active. So you can make it floating at the very end, when you're done tweaking it (look into thispatcher for the commands).

The send and receive can be set dynamically, but I'd just as soon use a gate 8 or a switch 8 (for 8 subpatches), then go to whatever outlet etc. you want. Another way is to "prepend 1" or "2" etc. on any messages/lists you send to the subpatches, then "route 1" etc. at the receiving end. Using #1 arguments can make this happen automatically if you have a ton of them---look into the docs about #1 etc. arguments (very useful).

Lots more possible, this is just some food for thought. Matrixctrl and route objects, or with max 5 the cool tabs object, can also add to your interface's intuitiveness and provide the controls you want---sending commands like "open" or preset-accessing numbers, etc. to the subpatches is then straightforward.

Definitely use "open" and "close" to pcontrol to your subpatches, since this is easier than a double-click and looks more intuitive than the actual object. Also these can be activated remotely, or with a keystroke... and a special one might close all of them, for example. This is a great time-saver even while developing, not just for the finished interface. 

> Does anyone have any systems they would like to share for opening up 

> subpatches 'on the fly'? How to manage the control interface, for 

> example I assume some people have the control objects pop up when you

The way to go is to use poly~ or vst~. These are the only objects

capable of loading dynamically subpatchers without rebuilding the audio

As dynamically loading into poly~ isn't around for such a long time, you

might need to wait a bit. I started something, but that's far from

You can look into Jamoma though which is the most spread framework for

such a thing. I don't know about the Max 5 state of Jamoma, but it does

> Does anyone have a system for dynamically allocating the names of "s"

> and "r" for routing signals to a centralised 'patch bay' of

look at setting the target for receive and forward as well as for 

receive~ and send~. If you are about to create feedback with audio, or 

to change targets for signals dynamically, you need to use receive~/send~...

Joseph Bell schrieb:
> Does anyone have any systems they would like to share for opening up 
> subpatches 'on the fly'? How to manage the control interface, for 
> example I assume some people have the control objects pop up when you
>  load up a particular subpatch?

The way to go is to use poly~ or vst~. These are the only objects
capable of loading dynamically subpatchers without rebuilding the audio
chain (which would create a dropout...).

As dynamically loading into poly~ isn't around for such a long time, you
might need to wait a bit. I started something, but that's far from
shareable.
You can look into Jamoma though which is the most spread framework for
such a thing. I don't know about the Max 5 state of Jamoma, but it does
work in Max 4.6.3...

> Does anyone have a system for dynamically allocating the names of "s"
> and "r" for routing signals to a centralised 'patch bay' of
> controller objects?

look at setting the target for receive and forward as well as for 
receive~ and send~. If you are about to create feedback with audio, or 
to change targets for signals dynamically, you need to use receive~/send~...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


On 30 juin 08, at 10:31, Stefan Tiedje wrote:

> I don't know about the Max 5 state of Jamoma, but it does work in 

a beta version compatible with 5.0.3 has just been released:

> I don't know about the Max 5 state of Jamoma, but it does work in  
> Max 4.6.3...

Systems for controlling and routing sub-patches opened up 'on the fly'