Basically, you don’t directly handle midi mapping in your plugin. You create a parameter visible to the host that the host can automate, and then the user can use the host’s automation features to control your plugin’s parameters.
So, for example, if you create a juce::Slider and connect it to a juce::RangedAudioParameter, then in Ableton you will be able to use the normal system of Midi map → click on a parameter → move a midi controller. Then when you move your midi controller, the host will be controlling your plugin’s RanngedAudioParameter, which will make your juce::Slider move.
Our older software captures MIDI CC messages, and allows mapping those messages to specific parameters. But these days, the approach mentioned above (using the DAW’s automation features to handle MIDI control of parameters) is probably the way to go.
Okay, thank you.
However in my plugin, I have variuos combinations of properties which are dependend on the plugin state. Therefore I am adding and deleting properties/juce::values to a simple ValueTree. I need a way to also midi controlle them.
Alternatively, I could prepare all possible combinations as parameters in a AudioProcessorValueTreeState as you propose, but it would be 20.000 combinations… Or is there actually a way, to add and delete parameters in the AudioProcessorValueTreeState? That would be extremly awesome!
For what it’s worth, if you’re going to make a standalone version of your plugin, you might want to offer midi mapping within it. In this case you’ll have to set up a way of handling this yourself. The same is true if you want to use MIDI to modify things which aren’t easily represented by parameters.
I’d suggest making some sort of abstraction which connects a Value to a MIDI CC. We did this with an RAII mechanism which looks quite a bit like the JUCE attachment classes, but pairs with an object owned by the processor which takes the midi input, looks for CC messages, and modifies the value.
Looks good at first glance. One of the things we did however was to make connections to a Value instead of a Parameter, primarily because there were a few things in our upcoming product which needed to work with a controller, but weren’t really meaningful in automation (or for which saved/loaded automation data didn’t make sense). This worked for us because a good chunk of our backend uses Value, although obviously this doesn’t make sense for something that can’t be controlled by one.
Nonetheless, that should work for making a standalone of a plugin with parameters MIDI mappable, as long as there’s some user facing way to change which controller maps to which parameter ( )
My PluginGuiMagic has that functionality built in. A little box that shows the last nudged CC and that you can drag onto any knob to control its parameter.
Thanks for the idea to control non parameter values as well, I will add that to my list…
Right you are. I was thinking of non-plugin standalones, where you would use the MidiInputCallback class for MIDI. In that case, MIDI comes in on “a high-priority system thread”… I just couldn’t remember if each MIDI device is given its own thread, or if input for all devices comes in on a single thread.
They never are accessed on the audio thread. Our processor does calculations which rely on those values on the message thread whose results are stored in an atomic pointer which points to an array which is used by the audio thread.