inbound MIDI system exclusive processing
Posted: 21 Feb 2012 14:40
[30 Dec 2012 edit update]: earlier this year Liine increased MIDI in to 256 bytes which is the current Vector (array) element limit as of Lemur version 4.0. Some synths that I own, the Waldorf Pulse, AdrenaLinn FX pedals are good with only 256 and I have those working with bidirectional syste exclusive messages in templates.
Greetings !
Ok so I've been trying many tests to get Lemur process as much inbound SysEx (F0) data as possible on iPad.
Tried using iRig with direct MIDI and via Lemur Daemon. Getting basically the same results.
Sysex data receive is almost always incomplete by the time "execution: On MIDI" F0 - System Exclusive / MIDI 0 / 0-127/1 to 1
script finishes or even starts according to my debug monitors and on computer MIDI monitoring (Mac OS X 10.7./USB MIDI via AMT-8)
I can understand that sometimes this has to do with time running out by going beyond the Lemur frame rate (16ms) due to the limits of MIDI transmission speed of a particular device (synth, FX unit..) for the amount of bytes.
[edit: this was caused by a bug that comes up when the AMT-8 USB interface is used with Lemur Daemon on Mac; I can get 127 bytes now every time over Wifi with a different MIDI interface]
As mentioned on the forum in other threads we are getting different sizes of return data into MIDI_ARGS almost always incomplete if greater than about 20bytes. Maximum return I've been able to get is not much more than 50bytes.
Guys are there any tips / programming workarounds that you have been using for this to work? What are the max bytes that you have been able to receive and from what device/connection method?
I really need to be able to get edit buffer preset data from devices to set the Lemur controls.
Liine wizards, a more advanced incoming MIDI listen/receive would be greatly appreciated. Maybe something that has a timeout value and a last expected byte (F7) or array.
[edit: MIDI listen sysex may already work for greater than one 16ms Lemur frame.. but no one at Liine has confirmed]
I think what we might need is a listener capable of paying attention beyond a single frame and only executing it's script when the timeout is reached (and thereby setting an error flag) or at the end of expected bytes(s).
cheers~
Jay
Greetings !
Ok so I've been trying many tests to get Lemur process as much inbound SysEx (F0) data as possible on iPad.
Tried using iRig with direct MIDI and via Lemur Daemon. Getting basically the same results.
Sysex data receive is almost always incomplete by the time "execution: On MIDI" F0 - System Exclusive / MIDI 0 / 0-127/1 to 1
script finishes or even starts according to my debug monitors and on computer MIDI monitoring (Mac OS X 10.7./USB MIDI via AMT-8)
I can understand that sometimes this has to do with time running out by going beyond the Lemur frame rate (16ms) due to the limits of MIDI transmission speed of a particular device (synth, FX unit..) for the amount of bytes.
[edit: this was caused by a bug that comes up when the AMT-8 USB interface is used with Lemur Daemon on Mac; I can get 127 bytes now every time over Wifi with a different MIDI interface]
As mentioned on the forum in other threads we are getting different sizes of return data into MIDI_ARGS almost always incomplete if greater than about 20bytes. Maximum return I've been able to get is not much more than 50bytes.
Guys are there any tips / programming workarounds that you have been using for this to work? What are the max bytes that you have been able to receive and from what device/connection method?
I really need to be able to get edit buffer preset data from devices to set the Lemur controls.
Liine wizards, a more advanced incoming MIDI listen/receive would be greatly appreciated. Maybe something that has a timeout value and a last expected byte (F7) or array.
[edit: MIDI listen sysex may already work for greater than one 16ms Lemur frame.. but no one at Liine has confirmed]
I think what we might need is a listener capable of paying attention beyond a single frame and only executing it's script when the timeout is reached (and thereby setting an error flag) or at the end of expected bytes(s).
cheers~
Jay