Suggestions for encapsulating a module?

Post and discuss Lemur Modules.
Post Reply
oldgearguy
Regular
Posts:315
Joined:02 Nov 2013 11:19
Suggestions for encapsulating a module?

Post by oldgearguy » 27 Jan 2015 12:18

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
Regular
Posts:1639
Joined:04 Nov 2012 08:34

Re: Suggestions for encapsulating a module?

Post by Softcore » 27 Jan 2015 12:31

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

oldgearguy
Regular
Posts:315
Joined:02 Nov 2013 11:19

Re: Suggestions for encapsulating a module?

Post by oldgearguy » 27 Jan 2015 14:26

Softcore wrote: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
Regular
Posts:1639
Joined:04 Nov 2012 08:34

Re: Suggestions for encapsulating a module?

Post by Softcore » 27 Jan 2015 14:28

Yes of course, makes sense!

Traxus
Regular
Posts:216
Joined:30 Nov 2012 06:19
Location:Detroit
Contact:

Re: Suggestions for encapsulating a module?

Post by Traxus » 28 Jan 2015 01:08

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
Regular
Posts:1639
Joined:04 Nov 2012 08:34

Re: Suggestions for encapsulating a module?

Post by Softcore » 28 Jan 2015 08:15

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

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

Post Reply