[LV2] LV2 control-ports and midi binding -- was Re: [LAU] [ANN] setBfree v0.8

Robin Gareus robin at gareus.org
Mon Jun 22 09:55:18 PDT 2015

Hi Filipe et al,

Maybe we should continue this lv2-dev (CCed) or LAD. You raise some
interesting points.

On 06/21/2015 11:16 PM, Filipe Coelho wrote:

> You're trying to do things in the plugin side that should have been the
> host's job in the first place.
> Loading a midi program should be a hosts job, not the plugin.

In an ideal world, yes, but it is unrealistic to demand from all host to
manage complex one-off plugin specific relations.

For simple synths fine; but understanding which parts and aspects of a
synth specific state can be part of a [midi-]program, perform atomic
reloads and manage transitions is not the hosts job.
I think it's a geeky pipe dream, but a nice one, I admit.

Only the plugin "knows" what happens if the state changes and hence only
the plugin should change it if asked to do so by the host.

The same also applies to simple things such as "Bypass" as we've
discussed at LAC.

IMHO a plugin host is literally just a host and not an omniscient
dictator in control of all parameters. We may have to agree to disagree
on that.

> If you export all your control ports and presets as proper lv2 data, the
> host can map incoming midi-bank/program events to the appropriate plugin
> state.

Exporting all control ports is not an option for the case at hand.

Check how many floats pointers one reasonably use on a modern machine
without significant overhead compared realtime processing (say 128 audio
samples). As opposed to audio-processing, you can't unroll loops nor use
SIMD, MIMD instructions there:

Set value in host; dereference pointer in the plugin; check if it the
value has changed and is within bounds.

Then compare that to the fixed cost of parsing a 3 byte MIDI message or
a 32 byte LV2 Atom which conveys the same information.

> (LV2 introduced preset banks a few weeks ago)

indeed. There's been great progress on the LV2 front.

> Of course if you try to handle midi-bank/program or midi-cc in the DSP
> side you won't be able to behave like a regular LV2 plugin.

Regular as in "all float control ports"? no.

Regular as in "using LV atom messages"? yes.

> You either expose *all* the data as LV2 or none at all.
> Currently you're at none at all. :(

right, except via http://lv2plug.in/ns/ext/midi/

>> As you already mentioned a plugin cannot modify its own control inputs
>> and a host cannot reasonably manage [plugin specific] programs (partial
>> subsets of the whole config). So the way forward is to use meaningful
>> messages.
> NO.
> I do NOT want plugins changing their own input parameters, ever.

Nor do I.

> If an input parameter, being a control port or whatever appears in the
> future, is exposed to the host - the host must be the one to control it.
> Deviating from this is a serious mistake.

Yes, that would also be against the LV2 spec.

There likely won't be any control ports for setBfree and it will be only
LV2 Atom message passing between host and plugin.

Said Atom messages are currently MIDI (which a host could understand)
and the plan is to eventually migrate fully to LV2ey messages (pending a
host can generate MIDI from it to send to an external control surface).

There are currently few hundred thousand internal parameters which can
be dynamically modified (using a single command) and a few hundred
thousand more which require re-initialization.

The relation between those parameters is easy enough to do with some
basic maths and loops, but teaching a host to learn "Go from
current-state to Program #15" is close to impossible. There is a
specific transition.

One possible solution is to create a "simple version" that exposes a
subset of meta-controls which can reasonably be managed by any host.
A missing link with that option is to provide feedback to the control

As was succinctly mentioned earlier in this thread: The first thing most
B3 players do is open and re-wire the instrument :)
setBfree has the goal to preserve that spirit of the original
instrument. The number of exposed controls has increased over time and
that trend will continue.

> You want midi banks + programs?
> Export the data as lv2 presets, and categorize the presets into banks.
> Then let the host do the MIDI mapping for you.
> You want midi cc automation?
> Export the default values you want for each control port, save new
> values on each preset if needed.
> Then let the host do the MIDI mapping for you.
>> If you have an alternative solution for this case, I'm all ears.
> Letting the host do the heavy work is a start.
> I don't know exactly what setBfree needs in order to work as a "real"
> plugin,
> but seems like a nice case to understand what is missing in LV2.
> (can you make a list?)

I did make a list back in 2012 when creating the setBfree LV2 plugin.
Most of this went into http://lv2plug.in/ns/ext/midi/ v1.6 and 1.8 later
that year into http://lv2plug.in/ns/ext/patch/ since.

What's missing is host-support, esp. for the latter.

The vast majority of settings in setBfree are instrument properties and
LV2:Patch is ideal for the case at hand. All internal controls already
have identifiers suitable to become a patch:subject (which can also be
used as OSC path).

Note that the setBfree LV2 plugin is still a side-project that came to
be because I like LV2 and think it's the plugin standard that sucks
least. Migrating all of setBfree to LV2 properly is the long-term plan
and moving slowly. The priority here is *not* to provide a fully fledged
LV2ey LV2-plugin to musicians *today*, but to get it right in the long run.

The main thing that's really missing are man-months.

The LV2 specs are sufficient already. Ardour4 recently gained initial
support for LV2:Patch, but it's really only David and me working on this
and we're both not available full time.

Will C. (who manages setbfree.org and got permission to open-source
beatrix in the first place) teaches High-school kids to hack and build
organs using RPi, they won't be using a LV2 host to do so.
He's also interested in people playing it live and most people who do
prefer the standalone jack app.

I am really glad that the MOD went with ingen which also has most of
infrastructure already in place.

> One thing I think it's important to mention is that we cannot be scared
> by the amount of controls it's going to have.
> I've seen a few devs commenting on how bad 2000 control ports in a
> plugin are, but I can't say I agree.

Does your CPU share that opinion as well? :)

> We need to push things forward in LV2.
> Why does it matter if a plugin has too many parameters and the host
> can't display them all?

Display is the smaller problem. The case for custom GUIs is a proper
layout, sensible control granularity and behavior.

> It's a host problem, not the plugin's fault.
> The plugin can group ports, give priorities and other hints to help the
> host.
> The host can show parameters by groups + priority and even have a search
> function.

nice. Prospective search would indeed be great at least to look up
parameters for mapping and automation.

Are you going to implement this in Carla?

> If we keep using < 100 parameters the hosts will never have an incentive
> to handle them better.

I doubt that it's a software limitation. Checking a few thousand float
control-ports for every 64 samples of audio strikes me as a bad idea.

In setBfree by default, only 63 controls are mapped, but it's a flexible
user-configurable map (not 1:1 port <> param).

The complete set of available parameters is around a million. (As far as
I know, only ZynAddSubFx is /worse/. IIRC it has somewhere around 36M

Exposing them all directly would be insane and a nightmare for users to
boot. Hence the idea is to use properties which can be queried and set
on demand.

LV2:Patch also allows a plugin to transition the state and acknowledge
that some particular request has been processed successfully.

How practical this will turn out in the real world remains to be seen
but I think that's currently the best option.


More information about the Devel mailing list