Pyramind

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 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.

implementing-a-tabbed-ui

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.

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.

I have a js in this collection which turns a normal bptacher into a 

make sure you take autowatch off. I'm an ass.

plug(ish)
http://estatesound.com/matsui.html

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.

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 

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
:)


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 

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 show bpatcher1, script bringtofront bpatcher1 -> thispatcher

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.

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.


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 ..

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 

what i hate most when using offsets for tabs and pages 

is that you are limited to 10 argumnets and 64 inlets

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.

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.

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.

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.

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: 

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 

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

> and it is also hard to arrange during programming ..

> 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

> 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.

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.

>
> 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


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.

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.


Implementing a tabbed UI.