Forums > MaxMSP

object layering

April 11, 2009 | 10:43 pm

Is there any way of controlling the layering of objects in a patch other than simply include/ do not include in background?

I’m trying to make an interface where the top layer (clickable one) is switchable between 2 different function objects. When one is selected, the other needs to be visible in the background but not editable if that makes sense (the way the automation in Logic works).

I’m finding it really difficult to create a nice looking interface with these objects without the layers getting messed up.

Cheers if anyone knows how I can sort it out!


April 11, 2009 | 11:15 pm

theres a key combo to make selected objects the frontmost or send them to back.
on mac it is command-shift-; and command-shift-B.


April 12, 2009 | 1:10 am

You could use scripting through [thispatcher]. The message "script sendtoback toplcd" will send an object with scripting name: toplcd to the lowest z-level above the actual patcher background (arrange>include in background when the object is highlighted or "background 1"). To have one object visible over another you might want to look at changing the alpha channel of their bgcolor attribute too.

lh


April 12, 2009 | 10:01 pm

timlloyd wrote on Sat, 11 April 2009 17:43

I’m trying to make an interface where the top layer (clickable one) is switchable between 2 different function objects. When one is selected, the other needs to be visible in the background but not editable if that makes sense (the way the automation in Logic works).

As many as you want using [thispatcher] as mentioned. This works really well for bpatchers too—a way to have (say) 8 channel strips all in one spot, with a tab or dropdown to choose which one’s one top and therefore editable. Saves a ton of space and eliminates scrolling.

Generally it’s good to have a way to set some master settings for each all at once, like "reset to defaults" or something. With bpatchers you can also use [pattr] for saving individual settings on each, you just need the pattrs you want to store in the bpatch (don’t even need to give a unique name like #1_number, unless you want to) and a [pattrstorage @greedy 1] in the top patch. Then you’ll see each bpatcher show up in the pattrstorage as its own main "collection" of pattrs, with each set indented below it and their values. Really easy and powerful to work with.

– Pasted Max Patch, click to expand. –

April 12, 2009 | 10:25 pm

ahh thanks very much for the replies! I’ll need to look into [this patcher] more now for other circumstances. That patch works exactly how I was hoping. I resorted to using only 2 function objects as a last resort after getting frustrated with the background $1 message.

There seems to be a more efficient way of doing just about everything I puzzle out so far, very encouraging!

cheers


April 13, 2009 | 1:16 am
timlloyd wrote on Sun, 12 April 2009 17:25

There seems to be a more efficient way of doing just about everything I puzzle out so far, very encouraging!

… and I don’t think that ever ends…hehe

The new alpha levels for pretty much any object really makes this kind of layering great—able to see multiple things going on at once, able to edit one at a time, and not using up tons of screen. Note that you can also move things with thispatcher, although with max 5 objects can be directly moved and resized with the patching_rect $1 $2 $3 $4 message. So with some tweaking you could have "compressed" and "expanded" modes for editing: like in compressed mode all layers are on top of each other, and in expanded they’re all in a column.

The only issue with resizing is that bpatchers don’t auto-scale the objects in them, that would have to be done manually and it would take some work. would be really cool if it did, but that’s asking way too much (the objects just don’t work that way). Anyway, one could always make a control patch using OpenGL, which does scale however you want.


Viewing 6 posts - 1 through 6 (of 6 total)