Present the controllers as LV2 parameters

[jpcima]

A work in progress to have CC as parameters.
It would permit to manipulate the SFZ controllers from 128 and up.

For the parameters 0-127, there are multiple options

1. synchronize it with the Midi CC; if parameter is changed by Midi, automate the parameter accordingly
2. do not generate the LV2 parameters 0-127, leave it all to Midi
3. generate all parameters 0-N, and do not map any CCs; let the host take care of mapping.

There can be some inconveniences

• in case of 1), these appear might feel as duplicated and bring confusion in some hosts
• in case of 3), the Midi CC will do nothing in initial configuration (no plugin-side Midi Learn in LV2, as opposed to VST3)

Thoughts?

(Note: sforzando, in VST2, goes with the option 1.)

[robbert-vdh]

Approach 1 is also how this would work in VST3 (with IMidiMapping), in case consistency is something you want to take into consideration.

[SpotlightKid]

I think option 3) would limit available functionality severely. Host support for MIDI mapping is lacking, esp. when it comes to remapping values ranges, curves or mapping the same CC to multiple targets

[paulfd]

It's nice but doesn't it clog a bit the "generic" UIs to have all this? I know VST does it but...

[paulfd]

Approach 1 is also how this would work in VST3 (with IMidiMapping), in case consistency is something you want to take into consideration.

Except in VST3 the host does the disambiguation, here the plugin would. I would still go with option 1 though.

[jpcima]

Following @falkTX 's suggestion on IRC, we might use the property midi:binding.
That lets us have the option 1) except the host manages the automation itself.

It's not an implemented feature in any current hosts; falkTX considers it for Carla 2.3 if we implement it.

sfizz:cc000
  a lv2:Parameter ;
  rdfs:label "Controller 000" ;
  rdfs:range atom:Float ;
  midi:binding "B00000"^^midi:MidiEvent .

[robbert-vdh]

@paulfd Normally those per-channel 'pseudoparameters' used for IMidiMapping are hidden, although REAPER doesn't seem to respect the hidden flags there (or the plugin doesn't sem them correctly). Those parameters are hidden in Bitwig for instance.

[jpcima]

@robbert-vdh We're not setting hidden flags on parameters, as these imply read-only.
Currently it's a kNoFlags and will get changed to kAutomatable in next work.
I noticed that Bitwig decides to hide parameters as soon as they're midi-mapped, regardless which flags are on it.

[robbert-vdh]

@jpcima That IMidiMapping is slightly confusing, because the parameters you're mapping really are supposed to be internal and not editable by the user. It's there to provide 'backwards compatibility' with MIDI concepts like CCs, pitch bends, and after touch, which all also belong to a specific MIDI channel. If you look at the parameters of Sforzando's VST3 version for instance, you'll notice that they they'll have these 16x127 parameters for MIDI CCs that are used in IMidiMapping, and on top of that they also have these MACRO_XXX parameters that will be renamed to match a CC or other parameter name depending on the patch. Those macro parameters are the same automatable parameters you mentioned in option 1), and Sforzando will control them during IAudioProcessor::process() based on parameter changes received for those 16x127 hidden CC parameters. This makes sense, because with direct MIDI mapping you would have multiple channels to think about (for MPE for instance) while with regular parameters there aren't any channels, and you also would not be able to remap these parameters to different CCs or value ranges if they were always mapped one to one to a certain MIDI CC. So in the end, what Sforzando is doing is exactly the same as your option 1).

[paulfd]

So if the host does not support midi:binding this behaves like option 3?

[jpcima]

That is the case indeed. This would be nicer if the midi:binding feature could be checked.

Also and unrelated, this work lacks support of properly saving and restoring CC parameter values, I have to check this next.

[paulfd]

Is this feature documented anywhere? If not and we're basically doing it live, I think having ways to check for host support is a bit required.

[jpcima]

If not and we're basically doing it live

It's true; on the other hand, this benefits LV2 and the community at large, and LV2 sometimes really needs some features like this.

VST3 is, and will remain probably a while, our recommended format of plugin.

[jpcima]

@falkTX, may there be a feature check for support of midi:binding?
If absent, we may fall back to automating the parameters on plugin side, and we support old hosts.

[falkTX]

@falkTX, may there be a feature check for support of midi:binding?
If absent, we may fall back to automating the parameters on plugin side, and we support old hosts.

I do not think midi:binding is valid as an lv2 feature. we should ask on the lv2 mailing list.
IMO this is better assumed as true (that is, supported by host) until we know of a proper method to get this info.

[jpcima]

I'm merging this LV2 work, which has now complete save/restore functionality for CC.
This is so I can implement the equivalent VST3 functionality.
As Carla is concerned, this makes a plugin ready to experiment the MIDI binding feature.