Current limitations ram and midi

Discuss Lemur and share techniques.
mbncp
Regular
Posts:87
Joined:08 Dec 2011 07:25
Current limitations ram and midi

Post by mbncp » 16 May 2013 16:31

Havn't been coding lemur much lately, but I have a project running in my head for a while, but would like to know if it's possible.

I want to create some midi/event loop recorder/player, some external midi and some internal events (xy pads,..).

The idea is to control up to 8 ipads from a mini or a iphone 4s, using each at least one or all of the following: midi app, synth, fx, audio recorder(loopy,..)

The max loop length would be 128 bars so this could generate a lot of events as I would send the clock as well.

So...
A)
Is lemur/ios capable of sending all these events ? Here I will use the laptop to distribute the differnt "tracks" to the right port/channel to avoid too much traffic on each ipad.
B)
The biggest problem is the array size, is it still limited to 256 elements ? I don't remember, can we use pointers to access arrays, otherwise the coding will be awfull.

thanks for any help

Softcore
Regular
Posts:1639
Joined:04 Nov 2012 08:34

Re: Current limitations ram and midi

Post by Softcore » 16 May 2013 18:06

I can tell you for sure, the 256 limit still exists.

mbncp
Regular
Posts:87
Joined:08 Dec 2011 07:25

Re: Current limitations ram and midi

Post by mbncp » 16 May 2013 23:22

Softcore wrote:I can tell you for sure, the 256 limit still exists.
Thanks,
A real shame, lemur could be such a great tool without these silly limitations.

It seems that creating an array of pointers to array isn't possible.

Workaround would be to create a bunch of hiden objects like multisliders and use getfirst/next to store these events but this may drastically increase ram usage.

Btw, didn't find this in the doc, but is it possible to create objects dinamically ?

Softcore
Regular
Posts:1639
Joined:04 Nov 2012 08:34

Re: Current limitations ram and midi

Post by Softcore » 17 May 2013 06:19

Uhmmm, sorry....thats a second "no" - as in you can't create dynamically an object...you can only have it shown or hidden but it has to be there, in the template, in the first place.

mbncp
Regular
Posts:87
Joined:08 Dec 2011 07:25

Re: Current limitations ram and midi

Post by mbncp » 17 May 2013 13:08

Thanks again for the bad news, I had in mind this was possible.

One more thing, it seems that if I make changes to some objects even within a script, and save it as a new project it will reload as is, working a bit as a preset handler. As I will have to configure ports,channels, cc's, ranges, well a bunch of different things, it could be handy to use it or are there things that I should be aware.
Another option is to create different init scripts but I find it a bit painfull to enter edit mode and start to type things each time.

Another trick I was thinking of is create presets on new pages.
Lets say that that page 1 is the main working page, page 2 being used for settings. Now if I duplicate (copy/paste) that page I should have a new preset and so on. Then the first page would get the setting from the last visited page. Using getfirst/getnext should do the trick, or am I dreaming again ?


Last option would be to plunge into ios coding, that's why I got a macbook air btw :roll:

Joe Soap
Regular
Posts:475
Joined:07 Jul 2012 15:04

Re: Current limitations ram and midi

Post by Joe Soap » 17 May 2013 18:02

Actually guys, it is possible to create objects dynamically - here's how:

http://forum.liine.net/viewtopic.php?f= ... ions#p3266

The problems lie in what you can then do with those dynamically created objects - without explicit naming (and arrays / vectors) . . . not so much. So you're faced with the task of building a more involved constructor - something I'd like to attempt myself but have abandoned plans to.

Too steep a learning-curve for this user just to address the shortcomings of a pretty fundamentally broken programming-model in Lemur (IMO). I'm astonished that Liine persisted with the original codebase since these shortcomings are well-known to them from the early JM days.

mbncp
Regular
Posts:87
Joined:08 Dec 2011 07:25

Re: Current limitations ram and midi

Post by mbncp » 17 May 2013 20:26

LOL, I even posted in that thread.

If the object can't do anything then it's not very usefull in most situation, but in my case I could create a bunch of multi something and use them to store my data. A bit ugly but at least I can then access these object like pointers.
AFAIK, getfirst/next(obj) returns a pointer to the object that I could store in one or a few arrays.

I'm not sure lemur will let me create 2000 multisliders, but it's worth a try. :twisted:


It was probably much easier to start with the old code and now, just increasing the array size may be complicated.
It's a bit frustrating when you use just lemur on a single ipad, having a few hundreds of MB and dealing with arrays of 256 bytes or ints.
But IMO, the ipad editor was a big priority, and probably a lot of work, they could have charged me at least 10 bucks for it.

Softcore
Regular
Posts:1639
Joined:04 Nov 2012 08:34

Re: Current limitations ram and midi

Post by Softcore » 17 May 2013 21:00

Wow I didnt know that!

But yeah kind of useless if you can't further control it.....and I assume you can't even delete it afterwards.....

mbncp
Regular
Posts:87
Joined:08 Dec 2011 07:25

Re: Current limitations ram and midi

Post by mbncp » 17 May 2013 21:52

There is a destroyobject(obj); function, and also getattributelist(object) that returns the name of all attributes.

Then you can set/get the values of these attributes. Now I'm not sure if you can get the x,y,.. values.
If so you could then create an On Frame callback somewhere and check if these values have changed, and trigger a midi/osc message or whatever.

Softcore
Regular
Posts:1639
Joined:04 Nov 2012 08:34

Re: Current limitations ram and midi

Post by Softcore » 17 May 2013 22:08

Interesting.....just tried it and I got the following "oxymoron" - "paradox"....

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

Good to know though!

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.

Post Reply