MIDI Kinetics Forum

Ok...First of all, my former Mackie Button had a serious coding flaw which made it impossible to duplicate (or copy paste) in a template. This would result in "breaking" the scripts inside and make the button dysfunctional

This is a switch/pad module that sends 127 then 0 (like a pad) although visually it looks like a switch - it has a visually on and off toggle state. it also "reacts" to incoming midi messages as a "switch" and not as a pad.

Following the discussion here, I thought of making it an "enclosed" object (with locked container) that reacts to expression x by other Lemur objects as one would expect .

The problem is.......it becomes quite heavy. It takes only 2 of the "enclosed" objects to reach 1% of reported memory in the editor. For reference, it takes 4 of the initial Mackie Button to reach that level and it takes around 9 factory object pads to reach 1%.

Here are both the modules......
To use this one map the expressions out and y.....be careful no tto accidentally "tick" the "y" expression - we dont need it to send midi messages, it is obly mapped to receive messages. You cant adress it with other Lemur objects directly (by setting its x expression) and its not of the "enclosed" nature talked about.

this one is the heavy, enclosed one. You can control it with other Lemur objects by setting the x expression (notice it still is a pad)....You can map it by changing the "cc" and "ch" expressions and you can even change its color directly from the top level - no need to unlock the container and do stuff. Other objects of Lemur can also get output from it by using either the "SwitchOut" or the "PadOut" expressions.
But as I said, its heavier than the first one. Ultimately I believe its not worth it to have an elegant object if that objects occupies nearly double the memory of Lemur than a similar other one.....


Wating for your thoughts on this subject!

Tricky one - I don't believe there's any single right answer.

I think the memory limitations are largely a red herring, or an artificial constraint given the resources available on the hardware.

The greater worry is having the whole shebang tied to the framerate, which is affected by the object count. This might not even be as consequential as it seems on the face of it but we've no official numbers to go on that I'm aware of.

Yup hear ya! exactly the reason Im so reluctant to put work into learning to efficiently code clocks, sequencers and the likes. Im afraid I will be "betrayed" by the frame rate. I think the approach of Mat (having an external application doing all the time-related processing) is the best one so far. But then again, you wont know if you haven't tried.

Just from an end-user POV I wouldn't be too disposed to rely on Lemur-based time-critical anything . . . while at the same time acknowledging the heroic efforts of the folk coding sequencers et al.