MIDI Kinetics Forum

So, I've got a hefty template, running at 67% byte usage, and dropping my FPS to 30 on the iPad 2, file size is 2MB.

Things seem to be holding up just fine but I start to worry about how much more I can add.

My first instinct was to cut down on the file size. I've got an obfuscation system written in PHP, and I set it up so that no variable, script, or object's name is longer than 5 characters, so:

MyScript() becomes f123()
MyOtherScript() becomes f124()
variablename = v123
objectName = o123
etc...

I ran this, and cut the filesize from 2 mb down to 1.75 mb. A hefty 12% drop! But, byte usage remained at 67%. Bummer.

So, I can only assume that

a) the readout of byte usage is POST compiler, which I'm also assuming simplifies all entity names into the rawest form possible
b) the readout is more tied to the variable listner and onFrame scripts, so it basically monitors the bandwidth (excuse my possible bastardization of terms) usage within lemur.

If that's the case, I'm probably S.O.L. for the most part.

My only question would it be, is it cheaper to have one variable listener function, that listens for any of say four variables to change rather than having 4 individual functions that each listen to those individual variables? It does not seem like that would be the case, either way lemur has to listen to all of those variables.

Also, does storing the contents of an onFrame and/or listener function inside a manual function that is simply called in these more resource intensive functions a cheaper way to go? My intuition again is no, but I'd like to be sure.

Traxus wrote:
My only question would it be, is it cheaper to have one variable listener function, that listens for any of say four variables to change rather than having 4 individual functions that each listen to those individual variables? It does not seem like that would be the case, either way lemur has to listen to all of those variables.

Also, does storing the contents of an onFrame and/or listener function inside a manual function that is simply called in these more resource intensive functions a cheaper way to go? My intuition again is no, but I'd like to be sure.

These and many more, even simpler, questions trouble me too....I think some guidelines on this matter from Liine would be much appreciated, especially for people like me who are not exactly programmers....

Hi
Yes, I think you will find the size indicator in the Editor is basically a indication of the compiled size useage of available Lemur memory when running . . .
Actual filesize will not necessarily change this much, it is a measure of the object allocation, and scripts . . .
When compiled your various scripts and object names etc would all be symbolised in some way ....

Not sure of any hard and fast rules re the optimising you are seeking, would need to test it in some fashion I guess . ..

MM

Macciza wrote: Not sure of any hard and fast rules re the optimising you are seeking, would need to test it in some fashion I guess . ..

Right, trying to think about how to go about this.

I'm about to build a set of 4 faders, that each control one EFX knob in software. Trying to decide if its cheaper to store the x values of each fader in a vector, and then have the midi out send all 4 values whenever the vector changes, or if this makes no difference in overall resource usage. I guess the way to go about it would be to make one of each module, and paste them 50 or so times into their own templates and see if the numbers show any variation but that will have to wait. Working on a production template sounds dramatically more fun right now.

This might not be accurate, but it is what I observed when trying to figure out the memory used by each object:

text = 3604 bytes
monitor = 7460 bytes
expression = 6096 bytes
knob = 12060 bytes
fader = 13484 bytes
container = 1116 bytes
custombutton = 6192 bytes
pads 1x1 = 19816 bytes
pads 4x4 = 20656 bytes
pads 8x8 = 23344 bytes