Brian H.

Is it possible to have a subpatcher or abstraction appear in 2 different forms, but the same instance, in a main patch? So for example, I'd like a bpatcher for an object so its controls/images are available, but rather than patching in and out of that bpatcher, have the object appear (as an abstraction, not a bpacther) elsewhere in the patch? And not have this be 2 separate instances of the same abstraction, but different 'views' of the same one?

Essentially I'm trying to keep the interface elements (bpatchers) and patching/routing separated in the main patch. I've got a few ideas for other ways, but this what strikes me as being a 'best way.' Set me straight?

Hi,
Is it possible to have a subpatcher or abstraction appear in 2 different forms, but the same instance, in a main patch?  So for example, I'd like a bpatcher for an object so its controls/images are available, but rather than patching in and out of that bpatcher, have the object appear (as an abstraction, not a bpacther) elsewhere in the patch?  And not have this be 2 separate instances of the same abstraction, but different 'views' of the same one?

Essentially I'm trying to keep the interface elements (bpatchers) and patching/routing separated in the main patch.  I've got a few ideas for other ways, but this what strikes me as being a 'best way.'  Set me straight?

bpatcher-possibility

Are you using Max 5? This is exactly the sort of thing that presentation mode is for. You can shrink the bpatcher down for routing purposes in the patching view, then add the bpatcher and any other GUI controls to the presentation view and resize/place them however you want in that view.

There is another option that will also work in Max 4. You can use [pattr] objects inside your bpatcher to control all the GUI objects. Then give your bpatcher a scripting name and create some [pattrs] at the same level as the bpatcher that bindto the pattrs inside the bpatcher. So something like [pattr @bindto bpatcher_name::inner_pattr_name]. Then you can route all your logic through these outer pattrs. This is a bit more complicated to setup, but if you want to store presets for your patch it's worth looking into the pattr system anyway.

The bindto approach may not be the best option depending on how your patch is setup. I definitely recommend presentation mode if you have Max 5.

There is another option that will also work in Max 4. You can use [pattr] objects inside your bpatcher to control all the GUI objects. Then give your bpatcher a scripting name and create some [pattrs] at the same level as the bpatcher that bindto the pattrs inside the bpatcher. So something like [pattr @bindto bpatcher_name::inner_pattr_name]. Then you can route all your logic through these outer pattrs. This is a bit more complicated to setup, but if you want to store presets for your patch it's worth looking into the pattr system anyway. 

The bindto approach may not be the best option depending on how your patch is setup. I definitely recommend presentation mode if you have Max 5.


By the way, for a bpatcher with GUI objects like knobs and sliders, you can bind a pattr directly to the GUI objects if you give them a scripting name. So there is no need for extra pattrs inside the bpatcher (unless you need to control non-gui objects).

Nothing like a late night post to overcomplicate things. This isn't that hard. I can give an example later if you are interested.

Thanks Adam! Yes, I'm using Max 5 and really digging Presentation Mode. Your simple solution could work just fine- It was fairly obvious and I missed it, trying to think 'around' it a more complicated way. For clarity of logic, lots of bpatchers in the patching logic wouldn't be my favorite choice, but it will work fine I suspect, with some comments and enough screen real-estate. I think I am doing something similar to your pattr suggestion now, only from the top > down (but I'm still working to understand the totality of the pattr system). But I was trying to figure out if that was the best structure before going much further, and this helps.

Thanks Adam!  Yes, I'm using Max 5 and really digging Presentation Mode.  Your simple solution could work just fine- It was fairly obvious and I missed it, trying to think 'around' it a more complicated way.  For clarity of logic, lots of bpatchers in the patching logic wouldn't be my favorite choice, but it will work fine I suspect, with some comments and enough screen real-estate.  I think I am doing something similar to your pattr suggestion now, only from the top > down (but I'm still working to understand the totality of the pattr system).  But I was trying to figure out if that was the best structure before going much further, and this helps.

bpatcher possibility?