sten

I've searched the forum, but couldn't find an answer to the question. I understand that for elements of a sub-patcher to be visible in presentation mode, the subpatch must be loaded using a bpatcher. What I don't understand is why. Would it be possible in a future update for this process to be made simpler? Would it not be possible for an 'add to main presentation' option to be included to subpatcher elements and if not, what is the reason?

why-must-we-use-bpatcher

this is always true for subpatches, not only in presentation mode.

The point of the bpatcher IS to make it simpler!

One usability feature would be to extend the "encapsulate" process so that the selection is saved to a file (encapsulate as abstraction rather than as sub patcher) and then automatically reload that abstraction into a new bpatcher.

Would it be possible in a future update for this process to be made simpler

----
Would it be possible in a future update for this process to be made simpler


If you want all of your patchers to be like bpatcher, then just use only bpatcher! Problem solved!

I'm obviously still missing something here. Perhaps it's because I'm relatively new to max (and probably still have some bad-habits picked up during my Reaktor phase…), but what I'm saying is; why can't sub patchers be treated as part of the main patch?

Say I build a synthesiser patch of some kind for one project, and then a delay line patch for a different project, and then want to use those two patchers within a new project. I could load them into bpatchers within a new patch. I could then put that patch into presentation mode, and have control over the positioning of my bpatched GUI's, but not over the individual elements?

Does this make any sense, or am I talking absolute rubbish here? Perhaps I need to mess around with bpatcher more, or change my workflow...

I'm obviously still missing something here. Perhaps it's because I'm relatively new to max (and probably still have some bad-habits picked up during my Reaktor phase…), but what I'm saying is; why can't sub patchers be treated as part of the main patch?
A practical example:
Say I build a synthesiser patch of some kind for one project, and then a delay line patch for a different project, and then want to use those two patchers within a new project. I could load them into bpatchers within a new patch. I could then put that patch into presentation mode, and have control over the positioning of my bpatched GUI's, but not over the individual elements? 

Does this make any sense, or am I talking absolute rubbish here? Perhaps I need to mess around with bpatcher more, or change my workflow...


hi sten, bpatcher is actually quite quick and painless in accomplishing what you're talking about. whenever i make a bpatcher object, i include the @name attribute, then directly type in the name of my patcher. don't even need go to inspector or browse any files, the patcher just appears in the bpatcher. after that, perhaps i want to make changes to my original bpatcher file, i can right click the bpatcher and click Object->Open Original ____.maxpat Perhaps something is funny in my bpatcher file, but im not sure what, I can turn on Proving (up at the top menu Debug->Probing), right click the bpatcher and hit Object -> New View of ___.maxpat I can then inspect my signal lines and see where I'm not getting a signal. Hope this makes things easier!

Thanks for all the responses, they do all make sense, but maybe I haven't explained myself properly.

I want my GUI in presentation mode to use elements that are contained within separate sub patchers, and I want full control over the positioning over each of these individual elements, regardless of whether they are included in the main patch, a sub patch, or an abstraction.

I want to be able to place a gain slider from my 'mixer' subpatch either side of a waveform~ from my synth sub patcher. I want to put bits from each of my subpatch into different areas of my presentation GUI. Essentially, I want subpatchers to be properly absorbed into whatever main patcher they are loaded into, allowing all elements to be loaded into presentation mode properly, rather than just using a bpatcher window. I could just de-encapsulate everything, but then my patching window starts to get really messy, really fast.

Sorry if I am being particularly stupid here and not understanding what has already been said on the subject!

Thanks for all the responses, they do all make sense, but maybe I haven't explained myself properly.
I want my GUI in presentation mode to use elements that are contained within separate sub patchers, and I want full control over the positioning over each of these individual elements, regardless of whether they are included in the main patch, a sub patch, or an abstraction.
I want to be able to place a gain slider from my 'mixer' subpatch either side of a waveform~ from my synth sub patcher. I want to put bits from each of my subpatch into different areas of my presentation GUI. Essentially, I want subpatchers to be properly absorbed into whatever main patcher they are loaded into, allowing all elements to be loaded into presentation mode properly, rather than just using a bpatcher window. I could just de-encapsulate everything, but then my patching window starts to get really messy, really fast.

Sorry if I am being particularly stupid here and not understanding what has already been said on the subject!


ah i see, like pulling elements out of the bpatcher's window into the main patch's presentation, so that those pieces could be moved around, regardless of which subpatch they are contained in? Max doesn't have that functionality, though I'm sure it'd be useful in GUI design. You could decapsulate everything, but still keep it very organized through delineating spaces for functions within your bigger patch, and then making everything come together in presentation mode.

i would like to add that i really like the PureData's "show graph on parent" for abstractions. I have difficulties understanding what you're about Sten, but it seems like what you seem to be missing. The problem with bpatcher is that you NEED to have the subpatcher already made and saved somewhere, whereas i would like to be able beginnign wiht an empty bpatcher and filling it, seeing elements appear little by little, and not needing to have the inside patch existing 

. The closest to achieving this i can do is having a dull max empty patcher called "dull.maxpat", and use that as a name argument at a bpatcher's creation, then check "embed patcher in parent". But it's still a bit more bothersome than having the possiblity to not have that dull.maxpat existing at all. Ideally, there should be like a "behave as subpatcher" checkbox in bpatcher, which would get rid of the necessity of having a patcher name at all. Even better if any subpatcher could have a "transform to bpatcher" option.

Hey,
i would like to add that i really like the PureData's "show graph on parent" for abstractions. I have difficulties understanding what you're about Sten, but it seems like what you seem to be missing. The problem with bpatcher is that you NEED to have the subpatcher already made and saved somewhere, whereas i would like to be able beginnign wiht an empty bpatcher and filling it, seeing elements appear little by little, and not needing to have the inside patch existing beforehands. The closest to achieving this i can do is having a dull max empty patcher called "dull.maxpat", and use that as a name argument at a bpatcher's creation, then check "embed patcher in parent". But it's still a bit more bothersome than having the possiblity to not have that dull.maxpat existing at all. Ideally, there should be like a "behave as subpatcher" checkbox in bpatcher, which would get rid of the necessity of having a patcher name at all. Even better if any subpatcher could have a "transform to bpatcher" option.


(there ain't even a message to open the contained patch inside a bpatcher :/ )

that beeing said iirc, bpatchers seem to create some memory leak problems, and might need a bigger rework

@STEN --- seems to me you're trying to make Max programming be identical to Reaktor programming since what you're describing is exactly how Reaktor works. However, I think you'll find that the Max model using an abstraction that can be instantiated many times is more powerful (and manageable) than Reaktor Macros

@VICHUG --- I don't quite understand the problem you're describing. Why would you not create a new patcher, fill it with (some of) the elements you need, then save that patcher and instantiate it in a bpatcher (possibly in presentation mode). You can then continue to modify the original saved patcher, and each time you save it, the bpatcher view will be updated. No need to embed patcher in parent.

If you're creating something like a channel strip (for example) where you need 8 or 16 (or more) and you'd like to add more functionality, it's much easier to do that once in an abstraction rather than having to edit 8 or 16 individual embedded bpatchers.

Sabo, you got it, that's exactly what I'd like to see, and I just wanted to be certain that I haven't somehow missed how it's done. I will look into the possibility of de-encapsulating everything and using send and receives where necessary to keep the patch neater.

@dhjdhjdhj : because creating a new patcher, saving it, etc, takes time. I would gladly have multiple bpatchers for minimal ui elements, which i don't intend to use anywhere else in another patch, if i have to find a name each time i have then to think to create a folder in my Max search path to keep everything not mixed in one place... then call the main patcher "main" in order to not open any subpatcher... and if i want to share it, a mere copy-compressed is not enough anymore, i need to not forget any dependency. it can get really tedious, very fast.

For your example : let's imagin you have to change one line of text in each of your channel strip (say, a label) ; you would anyway need to change each thing. (well ok a mere label is maybe not a good example but you get the idea ? We can maybe agree that some times it's indeed better to have only one abstraction multiple times, some other times it is simply not)

@dhjdhjdhj : because creating a new patcher, saving it, etc, takes time. I would gladly have multiple bpatchers for minimal ui elements, which i don't intend to use anywhere else in another patch, if i have to find a name each time i have then to think to create a folder in my Max search path to keep everything not mixed in one place... then call the main patcher "main" in order to not open any subpatcher... and if i want to share it, a mere copy-compressed is not enough anymore, i need to not forget any dependency. it can get really tedious, very fast.
For your example : let's imagin you have to change one line of text in each of your channel strip (say, a label) ; you would anyway need to change each thing. (well ok a mere label is maybe not a good example but you get the idea ? We can maybe agree that some times it's indeed better to have only one abstraction multiple times, some other times it is simply not)


I don't need to imagin [sic] this --- my channel strips support this in two different ways.

1) Static (but different label) for each channel --- implemented as a parameter to each bpatcher.

2) Dynamic --- just send in a message using a name appended to the channel number (say) of each strip.

"let’s imagin you have to change one line of text in each of your channel strip (say, a label)"

It's funny --- as I write this, I'm in the middle of writing a lecture on defensive programming and debugging techniques for a comp sci class I have to give tomorrow. The very first slide says

--- A little extra time now will save you a lot of time later.

How much extra possible time could it take?

"because creating a new patcher, saving it, etc, takes time."

I don't need to imagin [sic] this --- my channel strips support this in two different ways.
1) Static (but different label) for each channel --- implemented as a parameter to each bpatcher.
2) Dynamic --- just send in a message using a name appended to the channel number (say) of each strip.

---------------------------------------
It's funny --- as I write this, I'm in the middle of writing a lecture on defensive programming and debugging techniques for a comp sci class I have to give tomorrow. The very first slide says

* Don't be lazy!
  --- A little extra time now will save you a lot of time later.

Originally, there were no bpatchers. You could have subpatchers and abstractions, but they were black boxes. Except you could double-click on the black-box and see what was inside. In a separate window.

At some stage (I've forgotten whether this as a 2.5 addition, or if they came out with 3.0), bpatchers were invented to you could do a couple of funky GUI things with abstractions.

I'm not at all sure what you want to do that you can't already do with a bpatcher. Oh, you want it to be 

? But if you want something in your subpatch to have a control in the top-level patch, why not just put the control in the TLP and send the data into your subpatch? No lack of simple mechanisms for that: [v], [s]/[r], [pattr]…

OTOH, if you want a control in a subpatch to be visible in the TLP in presentation mode, you've got to position the thing (and Max has to have some kind of reasonable default position, which doesn't have particularly obvious coordinates), you've got ambiguous syntax with the delete key (does that delete the object, or just remove it from the TLP?), you've got that unnerving moment when you switch out of presentation and the danged object disappears (normally, everything in presentation is still somewhere in the patch when you switch out… you may have to look for it, but you can be sure it's 

Yes, there are solutions for all of these things, but they are going to make Max more complicated, not less so.

You might want to be careful what you wish for.

Which doesn't make the idea impossible. I just think it's a lot less of a "simplification" then you imagine.

I'm not at all sure what you want to do that you can't already do with a bpatcher. Oh, you want it to be easier? But if you want something in your subpatch to have a control in the top-level patch, why not just put the control in the TLP and send the data into your subpatch? No lack of simple mechanisms for that: [v], [s]/[r], [pattr]…

OTOH, if you want a control in a subpatch to be visible in the TLP in presentation mode, you've got to position the thing (and Max has to have some kind of reasonable default position, which doesn't have particularly obvious coordinates), you've got ambiguous syntax with the delete key (does that delete the object, or just remove it from the TLP?), you've got that unnerving moment when you switch out of presentation and the danged object disappears (normally, everything in presentation is still somewhere in the patch when you switch out… you may have to look for it, but you can be sure it's there.)

Which doesn't make the idea impossible. I just think it's a lot less of a "simplification" then you imagine.


I personally prefer having GUI elements communicate via send and receive with the processes they control. If you do that with your subpatchers and abstractions always you end up with what you want I think because the GUI is somewhat independent.

It also makes reusing the code for processing a lot easier and I believe it's kind of a generlly good idea to keep things modular.

I personally prefer having GUI elements communicate via send and receive with the processes they control. If you do that with your subpatchers and abstractions always you end up with what you want I think because the GUI is somewhat independent.
It also makes reusing the code for processing a lot easier and I believe it's kind of a generlly good idea to keep things modular.


i could be wrong but i believe that the point you missed is that you do not need to switch to presentation mode in order to see a GUI.

you can just build your GUI at 0 0 position of the main patcher, and then move the other rubbish on the side or into subpatchers. and if you do it like that, then using bpatchers to build a GUI can be very handy. for example you could put a graphical controller including all the required math and in/out stuff into a bpatcher, then copy it and move it around.

i could be wrong but i believe that the point you missed is that you do not need to switch to presentation mode in order to see a GUI. 

@Peter, Dhj, Woyteg : i know about the presentation mode, i know that i 

 do what i want currently, it's just not very handy, and i tasted in PureData what you could do with abstractions "showing graph on parent" and, from my experience, it doesn't make things more complicated, at all. I get it that if you could do that, you probably wouldn't, what with keeping things modular having your abstractions etc. I, personnaly, would love to see such a feature inside Max. It's all i'm saying.

@Peter, Dhj, Woyteg : i know about the presentation mode, i know that i can do what i want currently, it's just not very handy, and i tasted in PureData what you could do with abstractions "showing graph on parent" and, from my experience, it doesn't make things more complicated, at all. I get it that if you could do that, you probably wouldn't, what with keeping things modular having your abstractions etc. I, personnaly, would love to see such a feature inside Max. It's all i'm saying.


Personally I don't see why bpatchers can't behave like regular subpatchers in the way they store their data, if the bpatcher system is somehow better then why don't subpatchers behave that way?

because they are not patchers - it is an object. :)

sorry, what i wanted to say is: [bpatcher] is an 

sorry, what i wanted to say is: [bpatcher] is an external. [foo.mxb] or [p] are not.


ok but why is it and why does it have to be an external?

Jdudeo, it's because it would require more work from c74 to streamline bpatchers as much are subpatchers are in the Max workflow. It wouldn't be necessarly that easy or useful, considering their graphical nature. Although Roman, i doubt they are that much of a different nature, because i see no bpatcher.mxo anywhere, neither patcher.mxo ; they might exist at a similar level of hardcoded Max extensions. That beeing said, at that point of the discussion, i guess it's sterile to debate any further here and a feature request in due form would be the way to go forward !

hah so... what i want is kind of already there.. if i check 'embed patcher in parent', then right click on bpatcher, i can open a new view of it and patch in it. I feel stupid, sorry for your time.

I sensed the discussion was heading that way where it was becoming pointless to debate amongst ourselves. I have been following this discussion from my office so didn't have the opportunity to confirm anything myself so thanks for the heads up about the "embed patcher in parent". I'm surprised such a feature wasn't mentioned at all by the veterans in here.

The basic mistake is expecting Max to behave like Pd.

The two programs have been following separate development paths for over twenty years. They have developed differently. Period. Frankly, I have zero sympathy with anyone whining about "why doesn't Max do this thing that Pd does; why doesn't Pd do that thing like Max?"

That shouldn't stop anyone from writing up a feature request. Max has taken some Pd ideas over the years (I'm not sure if the reverse is true, but that's open source for you)-.

But you don't have an inalienable right to expect the two environments to behave identically.

The two programs have been following separate development paths for over twenty years. They have developed differently. Period. Frankly, I have zero sympathy with anyone whining about "why doesn't Max do this thing that Pd does; why doesn't Pd do that thing like Max?" 

But you don't have an inalienable right to expect the two environments to behave identically.


Hey, come on - i wasn't whining ! didn't want to sound like it anyway - comparison between max and pd is always, i see, a subtle and sensitive topic, but i feel they should constantly steal good ideas from each other, and never be ashamed nor afraid to do so. Which actually they sort of do sometimes, which is fine. My initial "whining" is quite unfounded too, that doesn't help.

maybe it is just tradition that it is an external object? (or probably actually an "internal")

no, seriously, the answer to this question is: most custom patches will not contain any "GUI" or "user maintainable" code, that is only a very special case.

why would anyone you like to view the inner secrets of a hertz to milliseconds conversion patcher right in the root patcher? the whole idea of making subs IS that you only see one little object box - and NOT the content in root.

and for this special case, they gave us bpatcher as alternative. :)

you dont need to embed it in the background, you can "open original" a bpatcher at any time.

at least when it comes to that, bpatcher mimics exactly the behaviour of other forms of subbing ... including poly~, in case you didnt know :)

no, seriously, the answer to this question is: most custom patches will not contain any "GUI" or "user maintainable" code, that is only a very special case.
why would anyone you like to view the inner secrets of a hertz to milliseconds conversion patcher right in the root patcher? the whole idea of making subs IS that you only see one little object box - and NOT the content in root.

1. make a patcher local copy of an abstraction into the bpatcher which you can edit without affecting the original. This is now unlinked from the abstraction, so it will not reflect changes to the original.

2. Make a "subpatcher" that you can edit. If you choose its contents to display in presentation (via the patcher inspector) you can delete the bpatcher and then undo that to make it show up. (Or close and reopen the containing patch)

I agree with the earlier posts regarding how handy "encapsulate to bpatcher" would be, though it is a double-edged sword when controls are in the same patch as audio processes (I.e no MVC). In BEAP, for example, it provides quick way of controlling audio processes, but it also makes the use of poly~ much harder, since now all of your controls are stuck inside of voices.

Embed can do one of two things:
1. make a patcher local copy of an abstraction into the bpatcher which you can edit without affecting the original.  This is now unlinked from the abstraction, so it will not reflect changes to the original.
2. Make a "subpatcher" that you can edit.  If you choose its contents to display in presentation (via the patcher inspector) you can delete the bpatcher and then undo that to make it show up.  (Or close and reopen the containing patch)

I agree with the earlier posts regarding how handy "encapsulate to bpatcher" would be, though it is a double-edged sword when controls are in the same patch as audio processes (I.e no MVC).  In BEAP, for example, it provides quick way of controlling audio processes, but it also makes the use of poly~ much harder, since now all of your controls are stuck inside of voices.


Roman, your last response to JDUDEO was exactly the answer I was looking for. I hadn't realised that element of it and suddenly it all makes sense. Thanks!

Why must we use bpatcher?