Implementing a tabbed UI.
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?
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 //
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.
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
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
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 .
Well, I’ll give it a try then, if there is no way of "hiding" a bpatcher object dynamically.
name the bpatcher as a variable, say bpatcher1
script hide bpatcher1 -> thispatcher
script show bpatcher1, script bringtofront bpatcher1 -> thispatcher
v a d e //
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.
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!
Hey Pyramid, I think you should [if you haven't] learn the coll object inside and out.
bringtofront sendtoback works for bpacther, but
scripting is the worst method one can use for
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.
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.
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.
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://
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 //
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.
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.