Current limitations ram and midi

[mbncp]

Once FaderX was destroyed, the script that was set to destroy it became red because there was no FaderX anymore to destroy lol!

I hate when these scripts get red. I guess that in this case, the idea would be to create an array of object names or just store the getobject value in an array, then access these object indirectly to avoid scipting errors.

BTW, we are not able to set any midi-OSC mappings via scripting so we are limited to scripted outputs for the created object I guess.

Not sure I get this right, but of course you would have to create the mapping yourself in a user function like
midibyte = scale(x, imin,imax, omin,omax)
For simple things I find it better to use the settings directly on the object in the editor, but for more complex coding I found it way easier to deal with that stuff myself. I use to set all my settings in some global init function where I could write some info, which is much easier than having to go thru a bunch of objects to see what's going on.

[Softcore]

I hate when these scripts get red. I guess that in this case, the idea would be to create an array of object names or just store the getobject value in an array, then access these object indirectly to avoid scipting errors.

Not sure I get this right, but of course you would have to create the mapping yourself in a user function like
midibyte = scale(x, imin,imax, omin,omax)
For simple things I find it better to use the settings directly on the object in the editor, but for more complex coding I found it way easier to deal with that stuff myself. I use to set all my settings in some global init function where I could write some info, which is much easier than having to go thru a bunch of objects to see what's going on.

Yup, the object array and indirect access to objects was the first thing that came to mind.

As for the mappings, yeah we ar ein the same boat, although the problem is, when you dont have the "factory" midi-OSC mappings, you dont have bi-directional communication.

[mbncp]

you dont have bi-directional communication

Not exactly, but then again you need to deal with it yourself, which gives you also far more possibilities, you decide when and what to update, doing fancy remapping, ...

IMO, there are two ways to work with Lemur, either you do everything using the editor with maybe a few scripts here and there or you do (almost) everything with scripts, using "global" functions that can be re-used in every project.

The first approach is easier but can be limited and painful to make just a few changes.

With the second one and if it's well done it's quick to make a single change on 50 objects, most of the code can be re-used in every project and there is (almost) no limit to what you can do.
In that case, the only function you need on any object is an On Expression that calls a global function with GetObject() and the value as parameter. And even this can be avoid by using a global on frame callback.

When I say global functions it's probably not the best as AFAIK it's not possible to copy them from one project to the other.
Best is to use some dummy objects and fill them with user functions. So you could have an object that deals with array functions, one with midi stuff, object specific, ... then a simple copy/paste and you have all you need in your new project.

Oops sorry, I'm speaking to myself, again

It's just that I have a couple of ipads now and have some "ambitious" project in mind using lemur and really want to start on the right feet, with reusable code, simple to maintain and quick to configure. When I try user project and I have to change port,channel, cc assignment on every control I get depressed lol

[Softcore]

Of course, I meant, right out of the "box"....

Yeah hear ya but the whole thing accumulates to be lots and lots of work hours - when you want everything in scripts, while it's a matter of simple mapping when you are using the "factory" mappings. Not to mention various shortcomings like stuttering controls which require more "thought-out" scripts for output AND input (feedback). (here's some thoughts on this)

My personal way of working is to avoid, therefore, things that can be done with the "factory" settings - fields and rely on scripts only for certain occasions where there cant be any other way...

For example, a well-thought out template which uses many objects in many containers and one or two "parent" objects. The end user can easily change the MIDI - OSC target if the developer provisioned to have all the contained elements set to "parent" target - a change of the "parent" object target will also force the rest of the objects to follow. Have I personally done it in my user-library contributions? No, I havent in most of them, because I learn as I go!

[mbncp]

Agree not for every situation, I was just thinking loud.

I did some more testing with createobject and this looks good.

My idea is to create small modules that I'll send on a server (probably to lemur on my iphone) and being able to recall them from any of my ipads. So I could have up to 6 of these modules on a single page controlling midi apps, synth, fx,.. great for performing. The tricky part will probably be the auto resizing.

I don't think I will use feedback on this project, but I'll remember the z trick for sure.

I noticed that turnado does that, so when I wanted to loop recording in an daw this would screw up everything.
That's why I though it would be much easier to control it from lemur and record from within Lemur.
If I touch the control record the events, but once released, play what has been recorded previously, a bit like Figure or some korg apps do it.