MIDI Kinetics Forum

Hi, this is my first (serious ) post here.
I'm working on a simple instrument to control my Nord Modular G2 engine. It has no interface at all, except an on/off switch, so you really need your laptop to use it. But now i was thinking, maybe my iPad and Lemur could do everything i need. Most of the things i need to do is simple, but one thing that would be essential in my opinion is to be able to see and select the patch names on my Lemur. The first thing i had in mind was to send a midi sysex patch dump request (on load) and use the response to auto-populate a menu object. Is this possible to do with scripting? I mean, sending the request is i guess, but the auto population i'm not sure about.
And is there a way around the 32 items limit in the menu object? Maybe there's a better solution? Or do i need to learn how to make my own object?
Would be grateful for any help!

emp wrote:Hi, this is my first (serious ) post here.
I'm working on a simple instrument to control my Nord Modular G2 engine. It has no interface at all, except an on/off switch, so you really need your laptop to use it. But now i was thinking, maybe my iPad and Lemur could do everything i need. Most of the things i need to do is simple, but one thing that would be essential in my opinion is to be able to see and select the patch names on my Lemur. The first thing i had in mind was to send a midi sysex patch dump request (on load) and use the response to auto-populate a menu object. Is this possible to do with scripting? I mean, sending the request is i guess, but the auto population i'm not sure about.
And is there a way around the 32 items limit in the menu object? Maybe there's a better solution? Or do i need to learn how to make my own object?
Would be grateful for any help!

It's certainly possible, given the following limitations -- sysex messages (sent and received) can be no larger than 256 bytes. Usually, sysex send messages are fine. Usually, the device is sending back more than 256 bytes. That is not fine. If you can pull back 256 byte chunks and store them, you can use a menu to display 32 items. There have been attempts to expand that, but IMHO, unless your goal is to become a Lemur expert, it's better/quicker to have a display window (Text/Monitor object) and give the user a slider or up/down buttons to scroll through the choices.

oldgearguy wrote: It's certainly possible, given the following limitations -- sysex messages (sent and received) can be no larger than 256 bytes. Usually, sysex send messages are fine. Usually, the device is sending back more than 256 bytes. That is not fine. If you can pull back 256 byte chunks and store them, you can use a menu to display 32 items. There have been attempts to expand that, but IMHO, unless your goal is to become a Lemur expert, it's better/quicker to have a display window (Text/Monitor object) and give the user a slider or up/down buttons to scroll through the choices.

Ok. Thanks. I will try that. BTW: why are these limits (32 items, 256 bytes, etc) hardcoded in Lemur? Wouldn't it be great if such limits could be user editable?

emp wrote:

oldgearguy wrote: It's certainly possible, given the following limitations -- sysex messages (sent and received) can be no larger than 256 bytes. Usually, sysex send messages are fine. Usually, the device is sending back more than 256 bytes. That is not fine. If you can pull back 256 byte chunks and store them, you can use a menu to display 32 items. There have been attempts to expand that, but IMHO, unless your goal is to become a Lemur expert, it's better/quicker to have a display window (Text/Monitor object) and give the user a slider or up/down buttons to scroll through the choices.

Ok. Thanks. I will try that. BTW: why are these limits (32 items, 256 bytes, etc) hardcoded in Lemur? Wouldn't it be great if such limits could be user editable?

I don't have the whole history, but my guess is that when it was a dedicated hardware+software combo, those limits were chosen as part of the design. Once you pick some fundamental values and design a system around them, it's virtually impossible to change without pretty much reworking the entire operating system. Since the OS has to handle data storage, manipulation, and I/O, it's not a limit that can (or should) be user-defined. If you know you will only have 256 'things', then you only need 16 bits (2 bytes) to track it. Expanding that out to larger numbers means redoing pointers, internal variables, optimizations, etc.

You'll run into the 256 magic number a lot in Lemur.

oldgearguy wrote: I don't have the whole history, but my guess is that when it was a dedicated hardware+software combo, those limits were chosen as part of the design. Once you pick some fundamental values and design a system around them, it's virtually impossible to change without pretty much reworking the entire operating system. Since the OS has to handle data storage, manipulation, and I/O, it's not a limit that can (or should) be user-defined. If you know you will only have 256 'things', then you only need 16 bits (2 bytes) to track it. Expanding that out to larger numbers means redoing pointers, internal variables, optimizations, etc.

You'll run into the 256 magic number a lot in Lemur.

I see. Now i just discovered that the NM G2 does indeed send out the sysex dumps in chunks. Good.. but it looks like the chunks are 512 bytes. Doh!

emp wrote: Now i just discovered that the NM G2 does indeed send out the sysex dumps in chunks. Good.. but it looks like the chunks are 512 bytes. Doh!

Hmm.. do i understand this correctly in that the Lemur need an "end of exclusive" in every 256 bytes chunk? Or would it actually split an incoming 512 byte message in to by itself?

emp wrote:

emp wrote: Now i just discovered that the NM G2 does indeed send out the sysex dumps in chunks. Good.. but it looks like the chunks are 512 bytes. Doh!

Hmm.. do i understand this correctly in that the Lemur need an "end of exclusive" in every 256 bytes chunk? Or would it actually split an incoming 512 byte message in to by itself?

F0...F7 <= 256 Receiving more than 256 bytes before EOX has resulted in very unpredictable results. You are basically overwriting/overflowing something at that point. In theory if the MIDI_ARGS buffer pointer was simply circling back to 0, you could read the data fast enough (or have the sender pause every 256 bytes long enough) to get the data copied out cleanly, but then you run into timing issues with Lemur frames and not having things executing exactly when and like you think they should and I don't know what the MIDI handling code does when it sees a start of SYSEX byte and doesn't see an EOX before the buffer fills, and by the way, Lemur throws away the F0, so your count has to adjust for that and and and and

much headaches.

Bottom line is the Lemur platform is very good for some things, OK for some other things, and not very good for a handful of MIDI/music tasks. Handling large blocks of sysex is in the 'not very good' bucket.