lemur - sysex receive

hello,

sorry for asking that much but i'm super stoked about the lemur and it's capabilites.
the controller for the MD comes along really well, however, i need again the help of you guys.

meanwhile i can send sysex just fine and switch pattern, load kits and so forth, very cool.

the problem now is the sysex receive, i learned that i need a script "on midi" which then listens to the incoming sysex message but i have no clue on how to decode the incoming messages.

i did not find a template, where i could had have a look at how this is done.

seems to be tricky thing

please help me out again.


thanks a lot,
martin

Yes, create a new script, call it OnSysex or whatever and select F0 System exclusive from the drop list, MIDI 0, and the rest is ignored

You can just add this to your script:

Monitor.value = MIDI_ARGS; // given you have a monitor object

if your sysex msg isn't too big you'll notice that you are receiving an array filled of values (0-127) where the status 0xF0 (240) is missing (bad decision imo) but the end of sysex 0xF7 (247) is present.

To send back that message I think you have to do it this way:
midiout(0, {0xF0, MIDI_ARGS}); // to include the sysex status byte

And you can then access any byte like on any array : if(MIDI_ARGS[0] == .....
for(n =0; n < sizeof(MIDI_ARGS); n++) { .... }

mbncp wrote:Yes, create a new script, call it OnSysex or whatever and select F0 System exclusive from the drop list, MIDI 0, and the rest is ignored

You can just add this to your script:

Monitor.value = MIDI_ARGS; // given you have a monitor object

if your sysex msg isn't too big you'll notice that you are receiving an array filled of values (0-127) where the status 0xF0 (240) is missing (bad decision imo) but the end of sysex 0xF7 (247) is present.

To send back that message I think you have to do it this way:
midiout(0, {0xF0, MIDI_ARGS}); // to include the sysex status byte

And you can then access any byte like on any array : if(MIDI_ARGS[0] == .....
for(n =0; n < sizeof(MIDI_ARGS); n++) { .... }

The stuff that you are explaining so well are missing from the manual!!
You have to be a fortune teller to figure them out.

Hi
Although there may not be specific examples of everything the info is there although some prior programming experience certainly helps . . .
The script you create executes on receipt of sysex messages on a particular channel and hands you an array called MIDI_ARGS containing the data.
What you do with it is up to you - and the same thing can be achieved in many different ways as well
You will also need to delve into the sysex documentation of whatever you wish to talk to as well
There is usually a difference between the message sent as a request to a device and the response given by it so it is not just a case of sending back the same message.

Some good programming tips to keep in mind are stuff like sizeof(a) which can help you check that you have the message you want by length,
and subarray(array,start,length) which is good for comparissions and separating out smaller parts of messages and
arraytostring(array[]) which can translate ascii numbers to charsto get patchnames and the like

If you don't having any coding experience I can see how it would all look very foreign, you are learning a new language
Go through as much code as you can and try to work out how it does some of what it does . . .

Cheers
MM

@mbnpc: thanks a lot, your explanation helped me a big deal.

i'm able to receive sysex and could finish an essential part of the editor now.

@macizza: arraytostring might exactly be what i'm looking for right now

merry christmas,
martin

Macciza wrote:Hi
Although there may not be specific examples of everything the info is there although some prior programming experience certainly helps . . .

I agree very much with you that a programming experience is needed to feel more comfortable with the whole package.
This forum should have been a place where we could exchange info on programming techniques and this is done in a great extent where people like you and mbnmc(don't remember the name exactly) are being so kind to offer their experience.
However I shouldn't have to be forced to look for the definition of the MIDI_ARGS in this forum.
This should have been described inside the manual. The MIDI_ARGS and not only this, is part of Lemur language which is not documented at all inside the manual. Even if you have programming experience you aren't able to figure this out at first. Only through trial and error.
I am not new to programming(although its been a long time since I seriously programmed something) I am not knew to midi and seriously I didn't have the faintest idea what the MIDI_ARGS represents.
Serious flaws in the manual which from a small exploration of the Mutant forum have been already expressed from other users in the past.
In my opinion this is what guys from Liine should pay attention at if they want to make Lemur for iPad really popular and give new life to it.

kraftf wrote:I agree very much with you that a programming experience is needed to feel more comfortable with the whole package.
This forum should have been a place where we could exchange info on programming techniques and this is done in a great extent where people like you and mbnmc(don't remember the name exactly) are being so kind to offer their experience.
However I shouldn't have to be forced to look for the definition of the MIDI_ARGS in this forum.
This should have been described inside the manual. The MIDI_ARGS and not only this, is part of Lemur language which is not documented at all inside the manual. Even if you have programming experience you aren't able to figure this out at first. Only through trial and error.
I am not new to programming(although its been a long time since I seriously programmed something) I am not knew to midi and seriously I didn't have the faintest idea what the MIDI_ARGS represents.
Serious flaws in the manual which from a small exploration of the Mutant forum have been already expressed from other users in the past.
In my opinion this is what guys from Liine should pay attention at if they want to make Lemur for iPad really popular and give new life to it.

Hi,

Thanks for your concern, suggestions for improvement are always welcome. Indeed, MIDI_ARGS was no more than mentioned in passing in the current version of the manual. I've already updated it to explain MIDI_ARGS and OSC_ARGS a little bit more. Will be uploading the revised manual soon.

Best regards,
Nick

Hi
Whilst I do agree that the manual needs some improvement, the best direction for these improvements depends on an individuals experience.
I believe there is more to be gained from learning general programming theory, designs, approach etc than just learning isolated examples.
I think i would like to see a very technical Reference manual documenting all features fully and accurately - an SDK style factual document.
Along with this could go a Programming Guide giving examples of syntax, design paradigms, simple/complex & local/global solutions.
Specific tutorials dealing with specific topics and various possible solution approaches discussed and/or worked through and evaluated.

I believe people will gain more through learning more general programming knowledge then by simply being given single, simple solutions.
This knowledge also leads one to be able to extrapolate 'design principles' form examples so that can be applied elsewhere more easily.

I hope that this sort of information resource will gradually become available as the community grows . . .

Cheers
MM

Macciza wrote:Hi
Whilst I do agree that the manual needs some improvement, the best direction for these improvements depends on an individuals experience.
I believe there is more to be gained from learning general programming theory, designs, approach etc than just learning isolated examples.
I think i would like to see a very technical Reference manual documenting all features fully and accurately - an SDK style factual document.
Along with this could go a Programming Guide giving examples of syntax, design paradigms, simple/complex & local/global solutions.
Specific tutorials dealing with specific topics and various possible solution approaches discussed and/or worked through and evaluated.

I believe people will gain more through learning more general programming knowledge then by simply being given single, simple solutions.
This knowledge also leads one to be able to extrapolate 'design principles' form examples so that can be applied elsewhere more easily.

I hope that this sort of information resource will gradually become available as the community grows . . .

Cheers
MM

I very much agree with you.
However all the above that you are suggesting is directed to a specific range of people that have the background and are able to develop their skills regarding this language or they will be able in the future after gaining some experience. Certainly it will not be for everybody in the first place.
But regarding people that have limited programming skills, they should be able to accomplish simple stuff more quickly. I think simple projects/examples are missing and people have to go through more comlex setups/examples resulting in a very steep learning curve.
For example there is no example of how to route a midi input to a midi output.This is something that I've made and as a newbie it took me way more time to accomplish this than it should.
In time that I will be improving my programming skills I will be able to build transformer objects for handling midi data. But the midi routing setup should have been already there, without me trying to setup it without knowing what MIDI_ARGS mean.

@nick_liine
Thanks a lot for taking into account my suggestions. Be sure that my intentions are pure and I have to say that I've become a big fun of this product and although it has let me down quite a few times I know eventually it will be more than rewarding. Actually it already is!!

mbncp wrote:Yes, create a new script, call it OnSysex or whatever and select F0 System exclusive from the drop list, MIDI 0, and the rest is ignored

You can just add this to your script:

Monitor.value = MIDI_ARGS; // given you have a monitor object

if your sysex msg isn't too big you'll notice that you are receiving an array filled of values (0-127) where the status 0xF0 (240) is missing (bad decision imo) but the end of sysex 0xF7 (247) is present.

This is fantastic information.
Is there any function in Lemur that converts this array of received sysex data from decimal to hex in real time?

bammer wrote: Is there any function in Lemur that converts this array of received sysex data from decimal to hex in real time?

Not directly but you can make your own:

Click on project(in the tree view), add a script, call it arraytohex(array) leave it to manual and paste the following code:

decl a, b, c , i;
c = sizeof(array)*3-1;
a = fill(1,32,c);
for(i = 0; i < c; i++)
{
	b = array[i] >> 4;
	a[i*3] = b > 9 ? b+55 : b+48;
	b = array[i] & 0xF;
	a[i*3+1] = b > 9 ? b+55 : b+48;
}
return arraytostring(a);

then just call it this way:

Monitor.value = arraytohex(MIDI_ARGS);

That is AWESOME. It converts the values perfectly. Thank you so much.
I'm slowly beginning to get my mind around Lemur.

Hi all - this only seems to work if the sysex device ID (2nd byte) is not 0. How do you monitor and process sysex data if the device id is 0?

for example the string is

240 0 0 102 5 0 16 3 1 3 14 12 247

Normally 240 is ignored, but if the second digit is 0 - nothing seems to be received.

If i manually send a message substituting the 0 with anything else - it is received. However the device is sending 0...

thanks!

Hi Shane
Yes this does seem to be a problem, possibly a test against zero message is catching the zero char .

Cheers
MM ..
I have passed it on and hopefully a fix will be in the next update . . .
Will see if I can think of a solution - easily done with a Max patch not sure about Lemur native . . .

Hi - Thanks for looking into it! Yup - I am using max now as a workaround - hopefully in the future it will won't be needed!

Any news when the problem with device id = 0 will be fixed?
One of the main reasons I recently purchased Lemur is its ability to handle sysex data... but apparently it doesn't work for what I want to do
So hopefully there'll be a fix soon!

240 0 0 102 is a message for Mackie Control. It was being intercepted, this is now fixed and will be included in the next release.

nick_liine wrote:240 0 0 102 is a message for Mackie Control. It was being intercepted, this is now fixed and will be included in the next release.

GREAT! Thanks for the quick reply
Can you already tell when the next release will be out?