seeing the Patching Mode of a bpatcher when clicking on its tab ; but seeing its Presentation Mode when in the root tab


    Aug 08 2021 | 6:04 pm
    Hey
    There is a subpatcher transformed to bpatcher ; it is set to "open in presentation" so that on the parent patcher we see the presentation mode. The "showontab" attribute is set to 1, so when in toplevel patch, we see also a tab on which one can click to access inside the bpatcher. But i would like to see that bpatcher's "patching mode", not "presentation mode", when clicking on the tab - while still having it display its "presentation mode" in the parent patcher. Can you dissociate both views ? I didn't find how. Thanks in advance.

    • Aug 09 2021 | 9:16 am
      active ?
      zzz
    • Aug 09 2021 | 9:54 am
      Thanks Mizu, at first i thought "ooh solution !" but then you click on anything inside the bpatcher on root level, and it becomes active and turns into edit mode (try clicking on the toggle, it immediately disappears...)
    • Aug 09 2021 | 2:03 pm
      ignoreclick to the bpatcher seems to work if needed. I played around, interested to expand complex UI's. But bpatcher seems not react like a subpatcher to setactivetab $1... How to give another name ? I needed to save as testbp.maxpat, and re-embed... Needed to force quit Max with 2 of these patches loaded-edited. Here is the current progress state.
      bzzz
    • Aug 09 2021 | 6:01 pm
      interesting ! I realize just now that your "active" solution works, it was switching presentation and patching mode because i was clicking the toggle that sends "presentation 0" from the root tab (silly me) Plus, if you use the shortcut for presentation view inside a tab, then it doesn't change the view in root tab (using the shortcut makes a difference from sending "presentation 1" message to thispatcher... sending a message to thispatcher will update all views, in tab and in main patch). When you save and close and reopen the patch, that tab will be again in edit mode, though. About setactivetab : i suppose you would need to go inside bpatcher, open patcher inspector, and set title to 'testbp' for "setactivetab testbp" to work, but for some reason i can't change that attribute (probably because it's a loaded abstraction, actually). It is however already weird that "setativetab 1" doesnt work, it is probably because bpatcher doesn't know so well how to behave when it is a patcher tab. edit : this works when not abstraction (i suppose) (and/or without an argument for the bpatcher)
    • Aug 09 2021 | 6:18 pm
      i had Max crash on me the first time i tried to edit the name of a patcher which was a tab and a bpatcher in root tab. Now it seems to behave correctly if you send a "title [the_tab_name_you_want]" message to thispatcher.
    • Aug 09 2021 | 7:22 pm
      yesss. Inspiring to revisit patches with too big UI. In a new bpatcher, i must send showontab 1 to a thispatcher inside to enable his tab presence. If i copy paste it, seems this info resists. But i don't find it in the infos of bpatcher... Tryed title: sent to a thispatcher inside the bpatcher changes the name in the tab, but "setactivetab testbp" or 1 doesn't work here... But nice perspectives ! - active : i dydn't use it before, and seems to work in floating windows. Maybe nice to make appear and disappear windows when needed. nice ! zzz
    • Aug 09 2021 | 8:05 pm
      Interesting, is the "presentation" message to [thispatcher] documented? I couldn't find it when I initially fiddled with your question...
    • Aug 10 2021 | 10:16 am
      i think i found it in a patch on the forum... My actual question is how cpu is used with big ui, his window not on screen ? What do i need on screen to be able to play, vs edit ? And under the fingers ? Haha :-)) bzzz
    • Aug 10 2021 | 12:14 pm
      most attributes set with patcher inspector can be used as messages to thispatcher. like for example patchlinecolor 1 0 0 1
    • Aug 10 2021 | 10:31 pm
      about the absence of "showontab" or some other attributes in the inspector fo bpatcher : there is a big difference betsween bpatcher's inspector when you are outside of it (like, selecting the bpatcher object from the root tab) and the bpatcher's "patcher inspector" which you access only from when you are inside an opened window with the content of said bpatcher ; there you should be able to have access to more attributes. Though i don't know why setactivetab wouldn't work after you gave a title to your bpatcher :/ maybe bpatcher is confused between a patcher's title, its actual filename (when a bpatcher is loaded from an external patcher file) ; and the creation arguments (as the first argument will be the name of a max patch file that the patcher will load).
    • Aug 10 2021 | 10:54 pm
      Yes, but i don't see "showontab" in bpatcher inspector, but it works sent to thispatcher. Certainely something i dydn't see. In progress... Going to see in the text version of a patch bzzz
    • Aug 10 2021 | 10:55 pm
      strrange!i can see it here, in the "view" section of the inspector
    • Aug 10 2021 | 11:47 pm
      thanks ! i found a thing. I see in bpatcher inspector "showontab" if it's opened as window, not if selected as object in the root window. Yes ! And i see:" showontab 1" to thispatcher enables "parent", what isn't saved with the root patch. If in inspector i choose "top-level", it's saved... Maybe not simple to encapsulate a window in a window. - Oups it's a bit late for me -. To follow tomorrow... nice !
    • Aug 11 2021 | 8:52 am
      #2 off the morning : make a new empty bpatcher in new patch. Embed it to can ctrl-click and "object->newview of the embedded patcher", under view -> showontab: Top-level, it appears as "bpatcher" in a tab. Or send "showontab 2" to a thispather, inside this embedded bpatcher , -> "top-level", enables save/recall of the patch. Seems logical. Now "title"... (I love the message "anything (variable) to thispatcher). Like in a rabbit hole :-) Fun !
    • Aug 20 2021 | 3:47 pm
      hey back on the topic of the [active]–[!= 1]-[presentation $1]-[thispatcher] workaround for initial problematic : it's not ideal because each time you're in the tab and open a subpatcher from that tab, [active] will send a lot of numbers out (not sur why so many actually, a quick succession of 0s and 1s, possibly related to the number of tabs in your patch) and it won't effectively change the presentation attribute of the tab, but it will change current window focus on said active tab so you can't really work in a subpatcher this way. :/