Implementing a tabbed UI.


    Oct 22 2006 | 12:18 pm
    Hello,
    I have a patcher inside a bpatcher object. I need 5 of these together in my main patch, but they take too much space on screen. So I want to make a tabbed version of it. I want to select "1 2 3 4 5" from the top, and the corresponding UI will show up in the same space.
    There should be numerous ways to do this I guess, any suggestions on one?
    I tried to use thispatcher object within bpatcher and sent the message "front" to it but it does not seem to work with bpatchers. Another option would be to arrange 5 of them in a bpatcher and using the offset message. But I have a feeling that scrolling with offset will screw the playback, as there are many objects in it. If you have any other solutions in mind I'll be glad to hear.
    The ideal would be I think, is to be able to hide and show bpatchers. Is there any way to hide an object(bpatcher) with a message?
    Thanks!

    • Oct 22 2006 | 12:55 pm
    • Oct 22 2006 | 5:17 pm
      I dont use MSP for live audio, so im not sure if my method involves
      introducing glitches, but for video ive never noticed a glitch
      I use thispatcher, and named bpatchers, and simply script hide
      bpatcher 1, script show bpatcher 2, etc etc.
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Oct 22 2006 | 5:34 pm
      plug(ish)
      I have a js in this collection which turns a normal bptacher into a
      tabbed pane. its called Bpatchtabs
      make sure you take autowatch off. I'm an ass.
      -matt
    • Oct 22 2006 | 6:12 pm
      very useful stuff Matt!
      one thing: I dropped the folders in the unzipped folder into their
      respective Max places but the extras panel didn't find folders to
      grab needed objects, help files, inspectors, etc...
      so I removed the various files needed to root level of the Max
      folders and it works fine now...but it would be nice to keep things
      tidy and able to be easily updated by keeping all the help files and
      things in their folders and have them resolve properly?
      unless there is something I might have missed in setting up the
      matsui lib...
      also, you might want to call the 'overview' patch 'matsui_overview'
      which would be more meaningful in a menu cluttered with other
      extras...just a suggestion
      :)
    • Oct 22 2006 | 6:23 pm
      I have to be honest here. when I got this stuff done(ish) I really
      burned out on it big time. its buggy, and its got autowatch on all
      the jscripts. I'm shamed because they are indeed very useful.
      I've never heard about this happening though. soon, I'll take a look
      at it and post a version 1.1 .
      -matt
    • Oct 23 2006 | 2:54 pm
      Well, I'll give it a try then, if there is no way of "hiding" a bpatcher object dynamically.
      Thanks!
    • Oct 23 2006 | 3:42 pm
      ?
      name the bpatcher as a variable, say bpatcher1
      script hide bpatcher1 -> thispatcher
      script show bpatcher1, script bringtofront bpatcher1 -> thispatcher
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Oct 23 2006 | 7:54 pm
      This is easy. Clear the UI then parse the data applicable to whichever instance you're invoking based on whatever parsing mechanism you've setup.
    • Oct 23 2006 | 8:23 pm
      Thanks for the help!
      script hide and show functions are going to do the trick for me. So thanks vade!
      Matsui really rocks I think, but I like managing things myself for now, as it is how I learn stuff. I'm still in my honeymoon with max(It's rather a long one).
      DrSbaitso, parsing datas for different instances is fine, but it would be a hard task in my current design, as all instances continuoisly parse and get new data for themselves, writing to files, loading from files... Current design just won't allow it. But thanks anyway!
    • Oct 23 2006 | 10:44 pm
      Hey Pyramid, I think you should [if you haven't] learn the coll object inside and out.
    • Oct 23 2006 | 11:23 pm
      bringtofront sendtoback works for bpacther, but
      scripting is the worst method one can use for
      alive app.
      and it is also hard to arrange during programming ..
      imaging 12 objects over another ... 8|
      your best bet is to use offset 0 150 - thispatcher
      to scroll through the bpacther. if your bpatcher is
      getting too big this way, thinkof making your GUI
      elements smaller or buy a bigger screen.
      what i hate most when using offsets for tabs and pages
      is that you are limited to 10 argumnets and 64 inlets
      for ALL the tabs.
      another alternative method to create dynamic UIs is
      to use the same set of knobs for different jobs - or
      progam UI elements in a (dynamic) [lcd] object.
      -110
    • Oct 24 2006 | 12:01 am
      DrSbaitso, all those instances actually use coll extensively, and i'm pretty confident with managing/storing/calling back data. But trust me, pumping values for every instance again and again would require to change the way that thing works. But thanks for the advice anyway!
      I'm pretty sure by now that hiding/showing stuff by scripting is not the best way to handle this job, but i think it will work for this project. I'll hook those things up and report.
      And next time, I'll design these sort of things with regards to "sbaitso" way. Single GUI, stored datas.
      Thanks for the help.
    • Oct 24 2006 | 12:16 am
      Yeah and you can use like "value" to set which instance is active and parse back into the relevant coll as necessary. Build like a refresh function that occurs after then new tab has been selected which parses through a common subpatch and parses back to the GUI......I've built a lot of GUI's using coll and I used to do it via scripting offsets and having multiple bpatchers with different arguments to distinguish their relative coll.
      It's much better to just have one interface and find some way of making it function for a dynamic number of stored data.
    • Oct 24 2006 | 12:17 am
      I have no performance issues with scripting in my app. I have 7
      bpatchers with 16 Pwindows for clip selection, all on top of one
      another, using a tabbed interface. Switching tabs hasnt been an issue.
      You can see an older version of the interface here: http://
      abstrakt.vade.info/wp-content/blogimages/teaser/Screenshot1.png
      Just my 2 cents. Ive had scripting go wrong/drop out/stall in other
      contexts, like instantiating new objects and script connect etc, but
      no hiding/bringing to front.
      and the code isnt that bad :P
      v a d e //
      www.vade.info
      abstrakt.vade.info
      On Oct 23, 2006, at 7:23 PM, Roman Thilenius wrote:
      >
      > bringtofront sendtoback works for bpacther, but
      > scripting is the worst method one can use for
      > alive app.
      > and it is also hard to arrange during programming ..
      > imaging 12 objects over another ... 8|
      >
      > your best bet is to use offset 0 150 - thispatcher
      > to scroll through the bpacther. if your bpatcher is
      > getting too big this way, thinkof making your GUI
      > elements smaller or buy a bigger screen.
      >
      > what i hate most when using offsets for tabs and pages
      > is that you are limited to 10 argumnets and 64 inlets
      > for ALL the tabs.
      >
      > another alternative method to create dynamic UIs is
      > to use the same set of knobs for different jobs - or
      > progam UI elements in a (dynamic) [lcd] object.
      >
      > -110
    • Oct 24 2006 | 12:22 am
      Quote: vade wrote on Mon, 23 October 2006 17:17
      ----------------------------------------------------
      > I have no performance issues with scripting in my app. I have 7
      > bpatchers with 16 Pwindows for clip selection, all on top of one
      > another, using a tabbed interface. Switching tabs hasnt been an issue.
      I think it's an issue only when having multiple tabs requires duping the same code as many times as there are tabs when it's all handled in the same space as there could be only one interface. That to me is poor programming in Max and can create severe loadtime misery.