Presentation mode vs. Non-Presentation differences?

    May 27 2010 | 7:18 am
    Hello :)
    Can someone please tell me: is it possible to add objects in Presentation mode and NOT have them appear in other non-Presentation views (like regular editing modes, etc)?
    Also, I can't seem to change the font size of a comment in Presentation mode and not have it also change in the regular-viewing there any way to separate these views?
    For example, I want to have a comment box only in Presentation view and not in other views/modes. But since I can't find a way to do that yet, I've settled and just tried to change the font for each - but I can't lol. The fonts are connected between views.
    Thank you for any help, I'm really frustrated :(

    • May 27 2010 | 7:44 am
      This is not currently possible. Fonts are common to presentation & patching views. The easiest solution would be to have 2 different comments, one for each view
    • May 27 2010 | 7:53 am
      Think of the Presentation mode as solving a very specific problem - as a way to deal with the *positions* of objects (and the size of UI objects in a patch). There's not a way to do any of what you describe. And yes, the attributes of text used in comments are not, at present, changeable in Patching vs. Presentation mode - only the comment boxes' positions. In part, that's because the expectation is that if you use the Presentation mode, you're doing so to create user interfaces and to avoid the possibility of breaking your patch by relocating UI objects when creating the interface. Apart from having the text "chase" the thing it labels, most programmers I respect tend to move panels and labels out of the way in Patching mode (and not a few of them set nice slow fades so that the little squares grow large and the text glides majestically across the screen when switching modes.
      In earlier times, users used the "Hide on Lock" feature to obscure patch cords and objects in a locked Max patch. Perhaps this could be of some assistance.
      But I guess I'd ask *why* you want to use both modes in a patch in the first place....
    • May 27 2010 | 8:35 am
      The options "add to background" and "hide/show background" might be helpful in achieving this, at least partially. There are ways to create custom shortcuts to these menu items for improving the workflow.
    • May 27 2010 | 10:15 am
      While I think Presentation mode is a huge step forward for Max, and incredibly useful in many circumstances, I have to say I share Ben's frustration. It would be extremely useful to have a true Model-View-Controller implementation in Max, which would completely separate the interface layer from the patching layer. Building interfaces does sometimes require UI objects that really are irrelevant in the patching layer, and shrinking, segregating, or hiding them isn't really a solution - it's a workaround.
      I'm sure that implementing a MVC patch structure would be a difficult undertaking and there are probably many other priorities for Max's development, but perhaps Cycling could shed some light on why they didn't include this in Max 5 to begin with. MVC is a pretty standard design pattern by now...
    • May 27 2010 | 11:55 am
      The main point of MVC is that the "model" encapsulates the application state. So it's well suited for any kind of data management system. But Max as a "data flow" system is the exact opposite.
    • May 27 2010 | 4:50 pm
      Thank you all for your help!
      Greg: Basically, when I have my electroacoustic compositions performed live (and I'm in the audience, not participating), I try my best to make sure my performers are well taken care of. So, for instance, I want say, a huge 30pt size font in Presentation mode saying "CUE 1 On/Off Switch" near a toggle; but I was hoping that when I switched back out of Presentation mode to do something let's say, I was hoping that the big font wouldn't be stamped over the workspace of my patch - and that each view could contain the same 'object' or text/font, just different sizes. Stuff like that. But it's not a dealbreaker now. I was just curious if you could separate them, that's all :) So now I know at least I wasn't missing something that was allowing me to do this...I didn't know for sure one way or another if what I asked was possible.
      How does hide/show in background work? What's the basic use of that? Sounds like something I may like! ;) Also, is there Hide on Lock in Max5? Thanks again everyone,
    • May 27 2010 | 9:22 pm
      In non-presentation mode I usually resize my panels to the smallest size and hide them behind an inlet.
    • May 27 2010 | 9:23 pm
      This is a very inelegant suggestion but...have you considered just moving the big text comment way off to the right or the bottom in patching mode only?
    • May 28 2010 | 12:48 am
      icoson: Hmm...I'll try that, thanks! :)
      Hans: What do you mean "panels behind an inlet"?
      Also, can someone help me with the last few questions I had in my previous post (above)? I'd be most appreciative - thank you all!
      *How does hide/show in background work? What's the basic use of that? *Is there Hide on Lock in Max5?
    • May 28 2010 | 2:32 am
      Might be more trouble than it's worth, but you could also set the font attributes according to which view you're in. Maybe use 'script send ' messages to try to minimize the mess that changing attributes of each comment box would create. Also could set the view from within the patcher ('presentation 0/1' -> thispatcher) and sync that to the attribute changes... trouble with that is that it could get confusing having two places to set presentation mode (toolbar and patcher toggle). Here's an example:
    • May 28 2010 | 3:38 am
      Good work !
    • May 28 2010 | 3:53 am
      Like icoson, I just keep a presentation junkyard - Sometimes I give it its own little panel and title, which makes me feel like I'm tidying my room. :p
    • May 28 2010 | 5:43 am
      Ben - select an object in your patcher, then look through the Object, Arrange, and View menus. The functions you're asking about are all there. Experiment with them and their use will become clear.
      In terms of the larger discussion - yes, we've all come up with clever ways of dealing with the inevitable clutter that comes from adding UI elements in presentation mode. But the question is: why do we have to do this? Why doesn't Max handle this more elegantly by having a truly independent presentation layer?
      Maybe I'm missing something, but I don't see why Max's emphasis on "data flow" rather than "state management" (arguable in itself - have you used pattrstorage lately? coll? sqlite?) makes this impossible.
    • May 28 2010 | 5:56 am
      Thanks for the help, Jesse...I'm experimenting with those options now - Max5 is insanely powerful :) I'm hooked!
    • May 28 2010 | 10:11 am
      Jesse - looking at it from another angle: MVC assumes that the model data are manipulated by operations of the controller component. But in data flow languages it's just the opposite, ie. operations are triggered by data. There is no independent control like in conventional programming.
    • May 28 2010 | 10:40 am
      Another trick: the textedit object can easily be turned in a comment and can have different size in the different views.
    • May 29 2010 | 2:52 am
      Many of the options on the View, Arrange, and Object menus can be done programatically with messages to [thispatcher] or to Max. So you can move and resize objects at will, put them into different layers, etc. With a locked background, this opens up a lot of UI possibilities.
    • May 30 2010 | 6:28 am
      broc - I suppose we can continue to parse this, but I'm not sure it's the point. Max is not inherently one thing or another, that's its strength. I don't agree that Max is exclusively a "data flow" system, nor do I agree that Max programming precludes designing patches that are centered on manipulation of controller components. It's all in the approach one takes.
      By the number of Max programmers contributing to this thread it seems obvious that many of us are coming up with workarounds for the same problem - what to do with UI objects in the patching layer that should exist only in the presentation layer. This seems less an issue of arguing over what Max is or isn't as it is a discussion about how to improve Max as a programming environment.
    • May 30 2010 | 5:10 pm
      Jesse - only because you mentioned MVC, I just wanted to point out that conventional design patterns are not necessarily suitable for unconventional systems.
      As for independent objects in presentation layer, I think it would compromise the clean concept of Max, where the presentation layer is a proper subset of the patcher. Of course, the mapping could/should be improved in some details.
    • May 30 2010 | 5:56 pm
      I hope I didn't start anything with my thread, I was just curious...I thought maybe I missed a few settings somewhere.
      Max5 is pretty darn clean, and perhaps down the line they'll implement a way in which the presentation layer could be independent than others, we'll'd be nice, but imo, not at the expense of any negative workflow adjustments.
      For now, though - I'm happy knowing more than I did last week :) Thanks again everyone! Ben
    • Jun 01 2010 | 9:10 pm
      @bencharles You can hide objects behind an inlet or another GUI object, like this:
      I usually choose the leftmost inlet for clarity. (I always make my GUI patchers inlets accepting messages to change their state. This allow them to be used as bpatchers in a MVC fashion).
    • Jun 03 2010 | 4:09 pm
      Thanks for that Hans!!!! :)
      I'm not sure what to make of the patch. I see it, but what do you mean "behind an inlet"?
      How do I recreate that?
    • Jun 04 2010 | 2:16 pm
      Well, I mean that you can hide objects behind other objects ;) It doesn't have to be an inlet, you can use a gswitch, dial etc.
      The Arrange > Send to Back command is useful for this.
    • Jun 06 2010 | 4:12 am
      Thanks! :)