Any interest in sysex input capabilities?

[jessecrossen]

I've made a branch that enables capturing up to N bytes of data from sysex messages and forwarding it to the patch. Currently I've only implemented it for serial MIDI, but it looks like it wouldn't be hard to add for USB as well. The catch is that I had to extend the signature of MidiInHandler to add ..., uint8_t sysex_bytes[], uint8_t sysex_len), and although that's not a breaking change, I assume it has some overhead, at least in terms of complexity.

I did this to support my RockBand 3 guitar controller, but I'm interested in whether anyone else would want the feature. If so, I can polish it up and submit a PR, otherwise I'll just rock on with my modified firmware.

[Eskadrone]

Although I`m interested in sysex input, for midi tuning events or short 12 Note Roland/Yamaha tunig dumps, I will wait for this happen in the main distribution.

[johannes]

I had a look at your implementation, the downside of your approach is that it can't handle sysex messages larger than 16 bytes, and it's impossible to store midi messages in a queue at some point in the future.

The model that I envision implementing in the future is moving from midi_device_t dev, uint8_t port, uint8_t b0, uint8_t b1, uint8_t b2 to a 4 byte format where the 1st byte is Cable Number (4 bits) followed by a Code Index Number (4 bits), just like the usb midi spec. That allows streaming sysex messages. Every midi message in a queue is then exactly 32bits. But it removes separate filtering based on device/port. I think the current mechanism is not as practical as it could be, and could be replaced by mapping/merging all physical midi input devices/ports to virtual midi input cable numbers (1-16), and mapping/replicating 16 virtual midi output cable numbers to physical midi output devices/ports. This would be a board setup preference, probably stored in flash memory or on sdcard in a preference file. This preference could also contain midi-thru routing.
This model conflicts with your implementation, unfortunately "the perfect is the enemy of the good"...

[jessecrossen]

That sounds like a really great design, and very efficient because the messages could be packed into a uint32 buffer for queuing, no structs, pointers, or linked lists required. In your ideal implementation, would the MidiInHandler signature remain the same to avoid breakage of existing object code? I can see how you could just unpack the 32 bit message into existing parameters, but I don't see how you'd communicate the code index number, i.e. that a message is a sysex continuation for example. I guess another way to do it in a non-breaking way would be to translate supported events for legacy code, and also make a new message buffer available to k-rate code.

Let me know if there's anything I can do to help improve MIDI support. I would really love to add support for hubs, but I have no idea how complex that would be.

P.S. I will point out that my implementation has an arbitrary limit on message length. The 16 bytes is just a constant, and since there isn't currently a queue that buffer is cheap because it only needs to be allocated once. As you say, queuing would make that a huge hassle, which is probably why JACK still has no support for sysex.

[bigpig]

I am interested in sysex input, for handling template changes from the Novation LaunchControl controller.

@jessecrossen could you link to your branch? I'd be interested in taking a look on how you did it, and potentially using your implementation.

[jessecrossen]

Sure: https://github.com/jessecrossen/axoloti/tree/sysex-in

[johannes]

I've made steps implementing virtual midi cables, and using midi input/output buffers containing Cable Number/Code Index Number, in the migration_to_chibios16 branch on github. That infrastructure should allow long sysex input and output, but currently not even short sysex messages are handled. Note that this is experimental development, don't touch if you're not familiar with firmware coding, compiling, flashing etc. I have only briefly tested midi in and out on din, usb host and device.
I'd like to invite developers in community to test, comment, and perhaps implement (long) sysex support. Check the todo file, and code comments. @jessecrossen ?

In your ideal implementation, would the MidiInHandler signature remain the same to avoid breakage of existing object code?

Assuming patches only use the OMNI port filter, the port value could be used for CN/CIN. That will break patches that make use of complex midi routing, but I believe the virtual input/output port system will result in cleaner patches. Adding a parallel midi port routing model in addition to the current could cause more user confusion than transitioning to a revised new model.

[spinus]

From a user/designer perspective, I think a sysex implementation would be GREAT. Given the nature of the GPIO, I think many instrument designs (will) include a MIDI controller of some kind, and being able to tailor that interfacing process, work with visual feedback etc with a wide variety of interfaces would be AMAZING.

I built a semi-modular sampler instrument based off of the CMD DV-1 controller, which works flawlessly except for the LED/button feedback part, which I have all the sysex codes for, but cant swing because I have no way of bouncing from the Axo to the DV-1.

Any help with that would be greatly appreciated!

[thetechnobear]

sysex output is already possible, I replied to your PM explaining how...

generally anyone wanting to do this should look at my code for the Ableton Push
community lib/objects/tb/midi/ctrl/push

you will see call to MidiSendSysEx

you should also be aware that the size of the sysex message is limited to the size of the ring buffer, in practice this will means 192 bytes for the sysex BUT if you have any other midi messages 'in flight' these also will take up space at 4 bytes per midi message (FIXED size ... thats the way USB midi works!)

if you get warning about ring buffers overflow.... then you know your message is either too long, or your sending them too fast.
(you will notice in the Push code, I'm quite careful to minimise the amount of data sent, and also ensure that it is sent out at a limited frequency.... I don't just push the display constantly or triggered off 'user input')

This is all subject to change in a future release