Suggestions for encapsulating a module?

[oldgearguy]

Question for people that have created modules -- what do you do with drop down menu objects?

Here's my situation:

I needed an LFO that generates MIDI CC values from 0 - 127 for a particular target CC. Creating a module seemed like a natural idea since I could then have 1,2,3 or more LFOs simply by pulling in another copy of the module.

So I create a container called LFO, put all the local variables in there, put in menu objects for LFO waveshape and target CC, sliders for rate, range, and pulsewidth, and switches for start/stop, sync, and one-shot. So far so good.

I noticed that in the container a drop-down menu object will not overflow outside the container. This means that I have to make the container big enough to display the full drop-down menu. OK, I can live with that...I guess. The problem comes in when you start placing multiple copies of these containers on-screen. Now you have weird overlapping and covering up and you have to continually mess with send to back/send to front and/or manually editing the .jzml to order the objects. I still end up with the situation where drop-down menus are not visible because of the screen location.

So, I need a non-container way to encapsulate the contents of a module so I can use generic names like rate, shape, PW for my variables and scripts and objects and still have multiple copies of them all without resorting to manually saying rate1, rate2, rate3, etc.

Is this possible?

Yes - I can probably restructure my object to not use drop-down menus, but they are a compact, natural way to present the information, and of course vectors instead of discrete variables are an option, but again, coming from a programming background, encapsulating the functionality in a generic package seems like the better solution.

thoughts?

[Softcore]

I take it you have already made the containers transparent, right?
Might help with the "overlapping"

[oldgearguy]

I take it you have already made the containers transparent, right?
Might help with the "overlapping"

yes I did. It does help with the overlapping, but the drop-down menu is still constrained by the container boundary.

[Softcore]

Yes of course, makes sense!

[Traxus]

I've tend to be let down by the rigidness of Lemurs menu tools (both tabbed containers and drop down menus).

I've resorted to using multi-labled pads as select buttons, with heavily abstracted show/hide loops.

Then, if your wrapper/container is too small for the entirety of the options, you can use a fader as a scroll bar via set rectangle (I like to add a grid on the fader, such that one step reveals one new item but that is a bit of added math between the total height of the pads object and the number of rows/menu items).

The downside that I am realizing is the 16 row limit on Pad objects (you might have to stack one or more to reach your desired count); but the benefit is the ability to scroll...

[Softcore]

Ahhh traxus reminded this litle one, which is burried in the forums history!

https://forum.liine.net/viewtopic.php?f ... oll#p12630