In 1.0.12, sysex send via DIN MIDI and the USB host port was implemented (though not documented).
Meanwhile I had a look at the firmware code and the next release (1.1.0), sysex can be sent via DIN MIDI, USB Host, and USB Device “natively” (i.e., with a dedicated object).
I will update the beta package shortly.
Haven’t made sysex type objects yet, though. Looking at what sorts of options these should have since all devices have bit of their own format going on.
I was thinking of four different objects, each with an increasing amount of “variability”.
Static sysex message: send 3 to 255 bytes, defined in a text field
Sysex with 1 variable byte (7-bit): send 3 to 255 bytes, defined in a text field, but one designated byte is being replaced by a knob/incoming value.
Sysex with 2 variable bytes (14-bit): send 3 to 255 bytes, defined in a text field, but two adjacent bytes (making a 14-bit value) are being replaced by a knob/incoming value.
Sysex “Roland” format: not sure if this needs to be variable, but the main point seems to be the checksum byte at the end of the message: Eddie's Home - MIDI - SysEx Tutorial
Perhaps an object with two 14-bit variables would be useful, too? It seems like some devices use this format to select “parameter” and “value”, each 14-bit?
Any thoughts? Is anyone familiar enough with sysex implementation and do the objects above make sense?
I have had success sending sysex to midi hardware over din and usb on Axoloti,haven’t yet tried it on Kso, I think the original object was by Chaocreator, but I have used these for a Roland Alpha Juno, an oberheim Matrix 1000 and a Roland GP8,
I’m currently thinking of a modular approach for sysex objects:
static sysex string object, 3 to 255 bytes long. Checksum byte can be optionally turned on (for roland). Enter your sysex string in a text field.
variable 1 byte object that receives a frac value (blue wire) and modifies 1 selectable byte (= 7-bit value) in the above static sysex object
variable 2 bytes object that receives a frac value and modifies 2 adjacent bytes (= 14-bit value) in the static sysex object
This way users could assemble whatever strings they may require, for example some sysex messages contain one 14-bit variable to select a parameter, and another 14-bit variable to set the parameter value.
One disadvantage might be that you have to be careful about object position, so that variables are changed before they’re sent out.
Unless I am misunderstanding something? Haven’t even looked into the checksum business yet, maybe it should be made a separate object too.
Never had to worry about checksum on the two roland pieces that I have, they’re both quite simple and early implementations, later more complicated stuff I’ve never tried.
Those objects I uploaded above require you to convert the standard sysex hex string into binary in the code.
May not be possible but implementing it in the object without that conversion may be less confusing for someone approaching this with a sysex string from the back of a manual.
The author somehow wrote in decimal here. It would be common practice to write the values in hex: uint8_t sysexArray[10] = { 0xF0, 0x41, 0x36 ... (= 240, 65, 54 …)
That must be it! The standard C formatting indicator “0x” is required or the compiler will not know that the number should be interpreted as hexadecimal.
So e.g decimal 10 is 0xA, or with an arbitrary number of leading zeros, like 0x0A, 0x000A0x0000000A, …
By the way, “0b” is the indicator for binary, so you could write, say, decimal 10 as 0b1010 or 0b00001010, …
Long story short, for MIDI and sysex stuff, writing a byte as 0x00 to 0xFF is convenient
