Any chance the max size of templates gets increased?

My two interfaces already take up 90% and i would like to expand. Any chance we see an increase in the max template size?

Excuse the probing, I don't mean to be insulting if this kind of advice is below you, but have you re-factored at all?

A lot of the time when building templates, I tend to build stand alone modules and duplicate them across the template. Inside those modules are scripts etc... That in an ideal world would actually be removed from the modules and placed at a higher level where all of them could access the code, but only have it written once. A lot of times templates can really be slimmed down by finding and abstracting redundancies.

I have got the same problem - some custom graphic stuff takes a lot of memory - esp. text elements arranged into icons. It can't be helped with script optimization.

Not sure about size increase plans currently but it may happen . . .
Re optimising: As always 'It depends' . . .
If you have a lot of scripting in every custom graphic, it can be factored out.
And there are other ways to optimise . . .
If they are non-changing graphics they only need to be defined once, not 100 times . . .
Same thing with any multiple representations of the same control . . .

I'm with Macciza and Traxus....after the initial excitement of achieving what I wanted functionally with my latest template attempt, Im looking at it now wondering how stupid can a person be to not use aliases for static texts that appear 24 times in one template - just tried and I had a 3% decrease


Also, most of the time, using a more "encapsulated" logic in scripts, looking at it in a bigger picture results in avoiding duplicate calls and functions. Already got a lot of ideas to improve my templates memory-wise.

I am sure something can be done with my template but i think it is a problem because i am doing a "per track"-sequencing template and it features 20 tracks with 16 steps and 20 faders each aswell as submenues/containers and stuff. Maybe i can post it and someone can take a quick look and see if there is something catastrophic going on (i wouldnt be surprised). It is kinda hard though to dive deep into this and refactor stuff. My first tries ended in deleting the whole thing because it didnt work anymore . The complicated stuff is done and i have 8% left for some simple synth templates that go along with the sequencer but the air is getting thin.

All that is true - we learn all the time but there are some things that can't be optimized in the current state - in my x1 template there are 200 unique icons (a couple of thousands of text objects). I can't optimize it... and they take about 40% of the template.

I understand that part of the appeal of your designs is the visual aspect but frankly? I would prefer to not have that 40% burdain and look "basic"....

I wouldnt "sacrifice" more than 5% for looks only - of course that is just a personal matter - opinion!

everybody has got their priorities:-).

Yes, please increase the Lemur object memory. It's 32Mb now, and really could use 64MB.

I've put about a year of work into my big Lemur template. It is a controller for the Fractal AxeFX guitar processors. The AxeFX is a rack multi-effect device with over 30 different effect types (e.g. amp, cab, delay, reverb, chorus, pitch shift). Each effect block has anywhere from 10 to 120 editable parameters. In total, there are about 1000 unique editable parameters in the AxeFX that my template can control.

I have re-factored many times, but now am running out of ideas to save memory.

Please double the memory limit. That would be huge for those of us pushing the limits of the Lemur IOS platform.

Lemur Loader.

If for example your template is to control multiple fx with say a max of 20 parameters each , you only need to create the objects once, just move the required data to a "working array" that the objects access as and when required, objects can be hidden , positioned, as required for the fx being controlled.
Or you could duplicate 20 objects , multiple times , in which case , an increase in the max size of a template is what you need.
Having said that the LPad wouldn't work using common scripts/ arrays, (probably due to the template relying on feedback from ableton rather than internal logic )everything had to be duplicated

The Problem with my template is that it works bidirectionally for every of the 20 tracks so i am not sure if i can get rid of the controls times 20 and just use 1 set of controls. I would have to memorize and constantly listen to the incoming paramters somewhere. I could place a couple of listener objects and then decode the Midi and distribute it back to the controls but uh this gets crazily tedious and abstract considering i am already doing somehting like this with 20 Reason Remote Codecs on the other side of the connection.

And also refactoring is a thing on its own. When you start doing templates for helping you to make music things look fine. Then templates get bigger, you put work into it and then you hit the wall and need to refactor and check if the time you need to put in is worth the time you save later. In my case, i think i am not doing this all over again as it took ages to do. I think i'd rather buy another ipad

wul wrote:If for example your template is to control multiple fx with say a max of 20 parameters each , you only need to create the objects once, just move the required data to a "working array" that the objects access as and when required, objects can be hidden , positioned, as required for the fx being controlled.
Or you could duplicate 20 objects , multiple times , in which case , an increase in the max size of a template is what you need.
Having said that the LPad wouldn't work using common scripts/ arrays, (probably due to the template relying on feedback from ableton rather than internal logic )everything had to be duplicated

Good ideas. FWIW, I am already making use of this technique in my large template. I use muxed controls, and dynamically reassign the effect and parameter IDs. I use a common dialog box for multiple-choice parameters, and dynamically reconfigure it each time it is used.

I still need more Lemur memory.

Why is there an argument against this? This should be a no-brainer. More Lemur memory will alllow bigger and better templates. It's a win-win for Liine, template developers, and template users.

dsorlien wrote:

wul wrote:If for example your template is to control multiple fx with say a max of 20 parameters each , you only need to create the objects once, just move the required data to a "working array" that the objects access as and when required, objects can be hidden , positioned, as required for the fx being controlled.
Or you could duplicate 20 objects , multiple times , in which case , an increase in the max size of a template is what you need.
Having said that the LPad wouldn't work using common scripts/ arrays, (probably due to the template relying on feedback from ableton rather than internal logic )everything had to be duplicated

Good ideas. FWIW, I am already making use of this technique in my large template. I use muxed controls, and dynamically reassign the effect and parameter IDs. I use a common dialog box for multiple-choice parameters, and dynamically reconfigure it each time it is used.

I still need more Lemur memory.

Why is there an argument against this? This should be a no-brainer. More Lemur memory will alllow bigger and better templates. It's a win-win for Liine, template developers, and template users.

It seems that the Lemur Editor gets pretty sluggish when the memory is nearly filled up. Maybe there lays the limitations. I am currently fighting with the last 5% but i definitly cant sqeeze everything in.

I was thinking/looking into this further and I have to agree, we could use another 50%-100% on the max size, whatever is feasible.

It dawned on me last night when I was trying to re factor some stuff that is duplicated across modules. I keep forgetting that we cannot store a reference to an object in a variable.

So I cant say:

decl b = getobject();

GlobalFunctions.someFunction(b);

And have the function take effect on just that particular object. I thought that I was being lazy as far as abstraction but as it turns out I was really pushing the envelope about as far as it could go. Unless the ability to store AND pass references to objects is added I see the current max template size as being a nasty threshold for a lot of us to deal with...

+1 I'm at the max too....A serious case of bad programming no doubt, but I'm also using aliasses where possible (and/or needed), putting universal scripts on higher level, and so on. I would very much like to see the memory doubled at least if possible, to be able to merge a few big projects on one Ipad.

Traxus wrote: It dawned on me last night when I was trying to re factor some stuff that is duplicated across modules. I keep forgetting that we cannot store a reference to an object in a variable.

So I cant say:

decl b = getobject();

GlobalFunctions.someFunction(b);

This one would be great...

dsorlien wrote:
Why is there an argument against this? This should be a no-brainer. More Lemur memory will alllow bigger and better templates. It's a win-win for Liine, template developers, and template users.

no arguments here but it should be obvious to even those with no brain, that a lower than 16ms frame rate/speed takes the priority. i'll upload a little module (to the module section of course)that monitors frame speed
just watch it increase with every object added.

I just figured that in my case refactoring is hard to do. Most of the controls in my template work bidirectionally so theremust be something that listens all the time, writes the stuff into an array and delivers when the corresponding controls are shown, and thus also sending the parameters again (not wanted but cant be circumvented ithink) i am at a loss here how to implement that.