SysEx message support about nih-plug HOT 8 CLOSED

Hi,

I don't know if you're the same person who asked this on the Discord the other week, but my question there to whomever asked for this and that is still unanswered: how would you suggest doing this in a realtime safe way? And without massively increasing the size of the events enum? I'd rather not complicate things too much or require gymnastics with basedrop for a feature that is never going to be used. Why do you need to send and receive SysEx MIDI in a DAW? If you're the same person who asked this previously, my recommendation still stands to interact with the device directly instead of trying to send the SysEx through a DAW.

from nih-plug.

Hi Robert,
I haven't been on Discord - apparently another person asking about the same topic. Hopefully, it will be found here by others curious about this topic.

The scenario I have in mind is to have a plugin controlling a workstation - Yamaha Montage. The arpeggiators can be switched only with SysEx messages, the plan is to have more parameters in the future and create plugin similar to MOXF Editor for Yamaha MOXF, M50 Editor for Korg M50 and there is also similar thing for Roland Integra - all available as VST plugins for DAW.

If there would be a timing problem, it could be noted in documentation - it would not matter in these cases as arpeggiator changes are applied at the beginning of the measure by the workstation itself, so it is sufficient if it happens within a measure.
For other voice parameters, there can be SysExes, too.

My idea of SysEx implementation in nih-plug is very basic - just being able to distinguish SysEx message and getting the raw data bytes in the message and sending the raw bytes would get the job done. The SysEx implementation is different for each device and it would not make sense IMO trying to be more specific in support for SysEx messages.

from nih-plug.

My question and suggestion still stands: how do you propose doing SysEx in a realtime safe way, and why are you not connecting to the device directly? Why is the DAW involved in sending MIDI SysEx messages to the device? To be able to do it in a realtime-safe way the main thing I can think of would be to add yet another type parameter to Plugin for an enum describing SysEx messages that implements some trait that converts these messages to a fixed size array.

from nih-plug.

When the workstation server as a sampler, it makes sense to be able to control its functions through a plugin.

For example, on project load in DAW, the plugin can send the voice configuration to workstation so that it is not necessary storing it in workstation's memory.

Implementation-wise, I looked at the code. You know it better, correct me if I am wrong on something.

Looking at the current implementation, it is bound to processing NoteEvents. Not sure about memory size allocated for enum variants by Rust - I suppose it is allocated for the biggest variant. If the former statement is true, adding SysEx support to NoteEvent is not a good idea.

How about adding a separate queues for input and output SysEx events into Wrapper? Then in wrapper.handle_in_event() would the incoming sysex queue be filled. The ProcessContext would get two methods for the sysex queue - e.g. next_sysex_event() and send_sysex_event().

That would make SysEx events processed aside of NoteEvents and could be even hidden behind a feature flag.

Thinking of SysEx messages, they might get long. Not in case of Yamaha Montage, but I believe e.g. Korg TR Rack can dump its entire voice configuration in one message (need to verify this information).

Not sure about the right solution here. I suppose the fixed size array requirement and not Vec is due to performance reasons, right?
Would it be possible to have the maximum length of the array configurable during plugin build (maybe through generic data type)?

from nih-plug.

The way I envisioned it would be to have yet another associated type on the Plugin struct that represents the different SysEx messages you'll handle and that implements a trait to convert these to and from a fixed size byte array. Then NoteEvent can contain those objects and everything could be realtime safe. But again, this is extremely low on my list of priorities. This feature is only relevant to an extremely small number of plugins, even even there I strongly question if it's needed at all.

from nih-plug.

I've implemented this on the master branch. There's not really an example yet, but it's fairly self explanatory. Create a struct or enum describing the SysEx messages you want to receive or output, implement the SysExMessage trait for it to allow conversion to and from raw MIDI buffers (as mentioned on the trait, you do need to include the 0x70 prefix and 0xf7 suffix bytes), and set that type as your SysExMessage type in your Plugin instance. Then you can send and receive those messages through NoteEvent::MidiSysEx.

from nih-plug.

https://github.com/robbert-vdh/nih-plug/blob/master/plugins/examples/sysex/src/lib.rs contains an example of how to use this.

from nih-plug.

Great work!

Thank you, Robert.

from nih-plug.