Implement sendNote for VST, and also add a SendNote example

[jpcima]

This implements note input from the editor, following a discussion in an older PR with @pdesaulniers.

It will enqueue the MIDI data into a FIFO buffer, which is protected by a mutex, and accessed by DSP with try-lock.
The buffer will be cleared when the plugin activates.

It uses extra/Mutex and forces the VST client to require pthread on non-Windows.

A test program is provided with UI and synthesizer.

cc @rghvdberg

[falkTX]

why isn't this part of the class variables but allocated on the constructor?
do we pointer swap at some point? if not, there is no reason to allocate things twice

[jpcima]

on purpose, to avoid a large block in the middle of object layout.
I'm pretty sure it's a recommended practice regarding caching, especially that this buffer is not going to be touched very regularly.

[falkTX]

Generally nice, thanks.
We need something that can be reused for the JACK format though.

I have a ringbuffer class made for carla that I can place here under permissive license.
It is a bit more complete than this one. But it does not care about ordering of midi events. so perhaps overkill.

Also, an idea that was mentioned on IRC was to allow UI to send any MIDI event, not just notes.
We can keep the sendNote as a helper function that calls into this sendMIDI.
DSSI and LV2 support this natively, so there should be no issues on doing so.

[jpcima]

Also, an idea that was mentioned on IRC was to allow UI to send any MIDI event, not just notes.

Agreed yes, I have thought about writing it in this perspective.

I have a ringbuffer class made for carla that I can place here under permissive license.
It is a bit more complete than this one. But it does not care about ordering of midi events. so perhaps overkill.

Possibly yes, here the lock isn't going even to be touched if nothing happens, I think it's quite light.

We need something that can be reused for the JACK format though.

Yeah I can do this one I guess. Using JACK's own ringbuffer?

[falkTX]

We need something that can be reused for the JACK format though.

Yeah I can do this one I guess. Using JACK's own ringbuffer?

Not a bad idea, but when a new format comes along (VST3 or AU) we will have to deal with this again, so I think it is better to have a common shared approach.

[jpcima]

I will do this, but I'm divided right now about where I preferably move the MIDI queue.
Should it go in DistrhoPluginInternal?

[falkTX]

Good question. Since this is only used for plugin formats that do instance-access then it is fine to go into plugin internal header yes. It is more related to the DSP side (receiving data) rather than UI.

[falkTX]

Thanks for the changes.
Please note the usual coding style in DPF though, where the * for pointer is on the left instead of on the right.
Also note that the build is failing atm with these latest additions.

[jpcima]

What do you think of the GCC variable size array extension, aka. silent allocas?
Should these go away?

In the JACK client, this dynamic stack array gives a little trouble.

MidiEvent midiEvents[eventCount];

[falkTX]

What do you think of the GCC variable size array extension, aka. silent allocas?
Should these go away?

We should limit the use of them, but okay for cases where it is known the size to be small

[jpcima]

Regarding JACK, I've bounded the MIDI buffer to the limit kMaxMidiEvents.
Sorry that this has dragged a bit, as I dealt with things on the side.

Do you think it would be wise to split the travis build into jobs, to improve the readability?

[falkTX]

Looking into this again.
While I appreciate the work done here, I want to do with a slightly different approach. It is mostly that a custom class for dealing with this seems off.
One crucial thing missing in DPF extras is a RingBuffer class, so I think I will put into DPF the one already in use for Carla, and use that to deal with ui->dsp midi events instead of the custom MIDI queue.
Also, this midi queue cannot deal with arbitrary sized MIDI messages, which can be a problem later (think MIDI2).
Making the ui->dsp use a dpf provided ringbuffer class will also help in stress-testing it.

[falkTX]

I imported the example plugin just now, will leave the PR open for reference regarding the other bits for JACK and VST2 sendNote support.

The example is slightly tweaked to behave more like a typical software piano UI.
Later on we can make it look like a real piano, also add keyboard input for easier testing.
For as-is works already for testing.

[falkTX]

Functionality now implemented on develop branch through the use of ringbuffer.
This will cause issues with #215 for sure, but I think for the best.