Hi, Can anyone help with good practices how to change a few bytes in a large reveived SysExblock, with the purpose of resending that altered block back to the synth?
I see that the SysExblock function would be handy to read through specific bytes of a block, but is not intended to change its content.
The purpose? It would allow changing parameters for which there are no CC, RPN, NRPN, or parameter change SysEx messages. So the only way left is tweaking larger SysEx messages. In this case I want to control the global settings of a Matrix 1000, because this gives access to a third LFO and allows changing the CC allocation of levers and pedals.
I would have this plan:
accept sysex block from device,
create new empty array,
populate array with sysex header for sending back to device (sometimes initial bytes differ for send vs receive),
skip past header in received block,
use a for loop or while loop, read from old block, write to new block,
change bytes as necessary,
calculate new checksum if necessary,
send new sysex block back to device
Sounds fair.
I have no experience yet in converting an array in a sysEx message. Probably not difficult, but anyways, it will be a first.
Suppose at a given moment I have all the necessary individual data bytes to write back (342 of them) in an array D with 342 members. My new header H is 4 bytes with fixed value. And I need to add the checksum function CS at the end… how would the the sysex send look like (particularly the construction of the data part)?
something like this (note that I assume your H bytes do not have the F0 start sysex byte, if they do, skip that one)
sendArray = {}
for i=1,4 do
sendArray[i] = H[i]
end
for i=1,342 do
sendArray[4+i] = D[i]
end
sendArray[347] = checksum --assumption is checksum is 1 byte.
midi.sendSysex(port, sendArray)
I’ll be on-line from time to time this weekend, so if you have questions, ask away.
Note - if it’s a 2 byte (14 or 16 bit) checksum, then you’ll have to do the standard mask and shift stuff and assign each byte:
checksum = <whatever you do to get the value>
sendArray[347] = (checksum & 0xFF00) >> 8
sendArray[348] = checksum & 0x00FF
Hi,
I was making good progress, but I fear I’ve encountered a current limitation of the E1.
The message I need to send is 351 bytes and looks like this:
But when I create the SendArray (cfr the logic you provided me) and send it, the E1 sends the following shortened version:
It is stated in the documentation: the E1 sendSysEx is limited to 256 bytes, but also it adds F0 and F7 at start and end.
Therefor I’m able to make the first 256 Bytes end on ‘0F’ as needed, but I can’t prevent the E1 from spontaneously sending a second sysEx which terminates on F7.
So I’m not able to create sysEx messages myself longer than 256 bytes
The thing is, I do not need to make messages longer than 256, that limitation is perfectly fine, but
I’m missing the option to prevent F0 or F7 to be added to sysEx messages.
Since we don’t have control over the final buffer as it leaves the E1, I’m not sure there’s anything that can be done at this point. I was looking at the other MIDI messages to see if maybe there was something else that could be used, but so far, I do not see a workaround.
I’ll keep poking around, but I think you are stuck at the moment.
I don’t know what Martin’s thoughts are on this but I believe a fairly simple way to enable your use case would be to introduce a new function – called, say, midi.sendRawData – that sends up to 256 bytes of data exactly as given (without prepending F0 or appending F7). Technically, midi.sendSysex could use this method under the hood.
