MIDI Kinetics Forum

dbk wrote:@ st8_livecontrol:

aren´t you part of the dev team here? are there any plans to implement arrays with more filesize?

please let us know.

cheers,
Martin

im afraid i wasnt involved in the lemur development, however i am finally getting to grips with lemur. I'll pass on the feature request though

LMO wrote:Any feeling for how much the 127 byte limit may be increased? I have some rather large (well over 2k) messages to deal with.

I am hoping for standard arrays of at least 1k and really need MIDI_ARGS to be able to deal with up to 8k from which I can subarray . . .

Hoping
MM

I monitored the actual message traffic I would need to deal with, and it turns out that the largest message size is 202 bytes, much less than the 2K+ I thought I might see. There may be other modes with larger messages, but

I'm hoping that will be achievable if the current limit is increased.

I'm copying this post from the Fractal Audio Systems forum:
http://forum.fractalaudio.com/lounge/44 ... post602474:

Regarding sysex message size, I created a simple Lemur template to display the size (number of bytes) and contents of the incoming sysex message. The results are not good.
Sysex messages up to 31 bytes in length can be received successfully
For sysex messages between 32 and about 48 bytes, sometimes I see the full message and sometimes only the first 31 bytes
For messages larger than about 48 bytes, only the first 31 bytes are appearing

This does not seem consistent with earlier posts on this thread, so has anyone else confirmed the current message size that can be received?

What kind of time frame are we talking about for an update that includes the larger array size? I realize there won't be a definitive answer, but have past updates been weeks, months, or years apart?

I might have discovered the root cause of the sysex receive problem. It appears to be a timing issue.

Some background: My latest hardware project is a DIY midi interface for my iPad, using a Teensy 2.0 board and Arduino. I'm using a 7-pin DIN jack with MIDI in and MIDI out combined so I can use a single MIDI cable to my rack.


I've tried two ways of handling the incoming sysex messages (from an AxeFX):
1. Pass the sysex message bytes via USB to the iPad with minimal buffering, only as required to encode the sysex data into USB messages. Lemur receives the sysex message at whatever rate the external device is sending MIDI ... about 3 bytes per millisecond.
2. Store the sysex message in a fifo buffer, and once the complete sysex message is in the buffer, send it to the iPad as quickly as possible. Lemur receives the entire message in a millisecond or two.

There is a problem with method #1. Lemur appears to chop off the tail end of a sysex message if the message takes more than a certain amount of time (one Lemur frame?) to be received.

Method #2 seems to work perfectly with Lemur, but has a limitation that the sysex message cannot be larger than free RAM in the Teensy microcontroller. I don't think this will be a limitation in my application, but could be in others.

Could a similar problem be occurring with wifi communication with the Lemur daemon? Is Lemur truncating the incoming sysex messages that take longer than one Lemur frame to receive?

Is Lemur truncating the incoming sysex messages that take longer than one Lemur frame to receive?

i don´t know but receiving sysex almost always returns a different amount of values here.sometimes a get the full array, then only 5 values, or 7 or 10 and sometimes nothing at all. i´m in no way good at coding so i thought this could be a fault on my side but i got some snippets from mbnpc and the same happens.

Just re-reading Martin's thread here and was going to post a new sysex processing topic, but this one covers the problems I've had within the past few days on a Dave Smith Mopho.

I've been trying to decode a sysex edit buffer and I've run into the problem of
inconsistent sizes sysex F0 return array sizes of 53 to 62, should be 298 after every edit buffer request at least to Mopho)

So to continue developing the code, I've created test arrays to for sysex decoding script and
like everyone else, I can't create a test array > 256

@Liine will the array max size be increased to at least 512 or much more as Macciza hopes for?

The "On MID/F0 System Exclusive" script/function execution could then process the argument array with hopefully the max number of buffer bytes that iPad core MIDI allows.

This would be great because then we can perform serious Sysex processing!

Anyway, good stuff.. I don't have much to offer at the moment because the code is broken given the current 3.02 limits, but
will post my sysex decoding script for DSI Mopho in another thread once it works.

@Macciza thanks again I've also been putting to use some of your suggested subarray techniques to build the code.

Thanks guys great info.

Macciza wrote:

LMO wrote:Any feeling for how much the 127 byte limit may be increased? I have some rather large (well over 2k) messages to deal with.

I am hoping for standard arrays of at least 1k and really need MIDI_ARGS to be able to deal with up to 8k from which I can subarray . . .

Hoping
MM

Hi dsorlien, that is DiY awesomeness, i love it!

Could you please let us know the maximum number of bytes you were able to have Lemur receive using direct midi and your hardware buffer method?

dsorlien wrote:I might have discovered the root cause of the sysex receive problem. It appears to be a timing issue.

Some background: My latest hardware project is a DIY midi interface for my iPad, using a Teensy 2.0 board and Arduino. I'm using a 7-pin DIN jack with MIDI in and MIDI out combined so I can use a single MIDI cable to my rack.


I've tried two ways of handling the incoming sysex messages (from an AxeFX):
1. Pass the sysex message bytes via USB to the iPad with minimal buffering, only as required to encode the sysex data into USB messages. Lemur receives the sysex message at whatever rate the external device is sending MIDI ... about 3 bytes per millisecond.
2. Store the sysex message in a fifo buffer, and once the complete sysex message is in the buffer, send it to the iPad as quickly as possible. Lemur receives the entire message in a millisecond or two.

There is a problem with method #1. Lemur appears to chop off the tail end of a sysex message if the message takes more than a certain amount of time (one Lemur frame?) to be received.

Method #2 seems to work perfectly with Lemur, but has a limitation that the sysex message cannot be larger than free RAM in the Teensy microcontroller. I don't think this will be a limitation in my application, but could be in others.

Could a similar problem be occurring with wifi communication with the Lemur daemon? Is Lemur truncating the incoming sysex messages that take longer than one Lemur frame to receive?

Same here with Lemur accepting varying number of bytes with On MIDI System Exclusive.

If the synth send rate is 3 bytes every 1ms, then the 50-60 bytes here makes perfect sense based on the Lemur frame rate of 16ms. every 16ms, whatever code is running is not finished and the entire process of processing the template begins again in the Lemur brain.

I think what needs to happen is that with system exclusive listening, the Lemur needs to continue to gather midi input data across frame rate runs until a timeout occurs or it receives Sysex EOM=F7. Then ideally it would run the specified processing script.

I checked to see if the execute on midi F0 ran until all bytes were received by monitoring a counter and most of the processed variables and it only ran once per synth request sent out: 50-60bytes varying of 289.

Sending the synth midi out to a computer midi interface showed the entire message F0 to F7, no problem.. but I don't know how long it took the interface to receive that many bytes, 96ms is my guess if the rate the synth is actually sending is 3bytes per ms.

dbk wrote:

Is Lemur truncating the incoming sysex messages that take longer than one Lemur frame to receive?

i don´t know but receiving sysex almost always returns a different amount of values here.sometimes a get the full array, then only 5 values, or 7 or 10 and sometimes nothing at all. i´m in no way good at coding so i thought this could be a fault on my side but i got some snippets from mbnpc and the same happens.