Presentation mode with subpatchers
Like i said in a previous post, I'm currently building a synth and experimenting for the first time with presentation mode.
With the patch becoming huge, and i'd like to encapsulate sections of it.
But when i do this, the interface element that were present in the presentation of the main patch disappears from it, and appear at the sub level, so becoming useless.
Is there a way for objects in subpatchers, to be included in the presentation of the main patcher (crossing the subpatch frontier), or do these objects have to stay at main patcher level to be displayed ?
Thanks in advance for your replies
Philippe
[bpatcher] is what you're looking for !
Ch.
> [bpatcher] is what you're looking for !
> Ch.
A good way to make it is to use the Encapsulate function, then save the new
subpatcher as an abstraction, then import it in a bpatcher.
I wish there were an object for embedded bpatcher (that would be to bpatcher
what patcher is to an abstraction), but there isn't.
J-F.
--
Jan 28th update: Audio Freeze - From Melody to Harmony
http://www.jeanfrancoischarles.com
So, apparently no straightforward solution to this...
I think i'll investigate further into the bpatcher object then...
thanks for the replies
ph
I'd say it's fairly straightforward. You can set different sizes and positions for [bpatcher] in patching and presentation mode so it's not in the way while you're editing. You can also specify which part of your patch you want the [bpatcher] to display using the "offset" attribute which is good for showing multiple user interfaces for the same subpatch.
lh
ok, but correct me if I'm wrong, but you need to configure your bpatcher in such a way so that the unneeded elements doesn't appear in the main patch, which requires much more cleaning and organizing than the way presentation mode works, by only selecting the elements you want to appear...
Or am I missing something completely here ?
Ph
You can set the bpatcher to display in presentation mode too so it works exactly like any other patcher. In the patch you load in to the [bpatcher] you can select "open in presentation".
lh
Sure, creating a bpatcher involves this extra step of saving the abstraction and the loading it into a bpatcher object, but once that's done you can edit it as easily as an abstraction using Max 5's Modify Read-Only feature.
See the instructions at the bottom of this page:
https://cycling74.com/docs/max5/vignettes/core/patcher_views.html
Once you do that, you can edit the bpatcher in its window, and see the changes reflected in the main patcher window. Pretty slick!
ok, got it, i was missing the small "open in presentation" checkbox in patcher inspector...
thanks !
>> I wish there were an object for embedded bpatcher (that would be to bpatcher
>> what patcher is to an abstraction), but there isn't.
>
> There is a way (luckily not an object...;-), a checkbox called "Embed
> Patcher in Parent" in the inspector.
> You can still open a new view of that embedded patcher and edit it to
> your will...
>
> Stefan
Yes, that's it! Everyday, a new thing to learn in Max.
Thanks Stefan,
J-F.
Ok, most of this thread is clear and i've successfully been using the [bpatcher] with presentation mode and the modify read only function. Thanks for that.
Now my question is if y'all know of a way to have multiple [bpatcher] objects referencing 1 file that update each other?
I'd like to use a few bpatcher objects as "windows" to different areas of my UI patch. I can get multiple instances of the same patch, but they don't update, which means i have to reselect the target file in each bpatcher for this to happen.
don't worry.
I'll just use multiple patches. No reason why not i guess. In the end its going to be a standalone anyway.
--->
Now my question is if y'all know of a way to have multiple [bpatcher] objects referencing 1 file that update each other?
I'd like to use a few bpatcher objects as "windows" to different areas of my UI patch. I can get multiple instances of the same patch, but they don't update, which means i have to reselect the target file in each bpatcher for this to happen.
--->
They don't update? They should... so you use multiple bpatchers with the correct offset parameters to view different parts of the big bpatcher, good idea for space-saving, then when you want to make a change, change the original target file, and they all update when you save. Unless I'm misunderstanding?
The "update anywhere you use them" is the main idea behind bpatchers and abstractions. If you think about it, it really can't be any other way, since they all reference the same master file. So for patches where you need some modifications to each, use subpatches instead; if they're all pretty much the same, use bpatchers or abstractions.
One trick is to have some default settings in a preset in the bpatcher, then using an argument to the bpatcher, it will load a different preset into each when you open the main patch. as a simple example, you could have a panel as a background, and have each instance with its own color. Just do a loadmess #1 (not $1) to the preset to utilize the argument you supply in the bpatcher inspector; the preset sets the panel color using number boxes or a swatch. (For a simple preset like this you'd want to manually hook it up to only the elements you want to control, not have a "global" preset which isn't hooked to anything and thus tracks all the presettable elements).
my apologies for the confusion. This is a great thread for searches on the subject.
Without "Embed Patcher in Parent" checked, [bpatcher] objects will reference a file. It is possible to have multiple bpatcher objects referencing the same file and they will update when the file is saved.
If "Embed Patcher in Parent" is checked the reference file is saved within the main patcher. If multiple bpatchers referred to 1 file but have embedding checked, they can be edited individually, but make no reference to changes in the original file.
What puzzled me initially is that the "choose patcher file" value still points at the reference file even if "Embed Patcher in Parent" is checked. Maybe this should be cleared instead.