On 21-06-2015 22:31, Robin Gareus wrote:
On 06/21/2015 08:07 PM, Filipe Coelho wrote:
[..]
Because you do this inside the plugin and LV2 says you can't change your
plugin input ports,
it means you can't export those parameters as control ports.
This is indeed the main reason why they can't and won't be exported as
control ports.
A really bad reason then.
If a midi-cc event on the plugin side triggers some control port update,
the host cannot know about it.
Why not?
The official midi midnam spec is precisely for that case. There are
various hosts (commercial and otherwise) that support it already.
This means the plugin is doing the parameter updates via midi-cc as well
as the host.
Sounds like trouble.
I know this situation from VST plugins, and it's quite painful to deal with.
VST allows the plugin DSP side to change its own parameters. So a few
plugins use this to implement midi-cc/learn themselves.
There can be a case where the same parameter is mapped to a midi-cc in
the plugin side (perhaps as part of a preset),
and also in the host.
I don't want to get too much off topic here, hopefully you can
understand that this creates a really bad state...
Making the plugins handle midi-cc internally seems like a regression
from the old VST days.
LV2 should to be better than this.
Carla already includes the midi-cc configuration as part of a saved preset,
That's Carla specific isn't it?
I showed an example of how it can be done in lv2 presets as well.
It's not carla specific.
When I implement lv2 preset save in carla I'll make sure to include the
(host-side) midi-cc bindings.
Then whatever host loads it, and if it implements midi-cc, will be able
to use the same bindings.
Anyway, is there a real reason for setBfree to not have its parameters
exposed as control ports?
There are way to many of them for it to reasonably work. Particularly in
Carla which sends port_events for all ports in every cycle regardless if
the value has changed. This does not scale.
This is false, unless you mean port outputs.
port_event is an UI side function, so I guess you're referring to the UI
here.
Carla will call port_event when the UI is first shown and when some
control port changes.
For control outputs I send them every idle(), but that can be adjusted
so it only sends when changed.
It also does not allow for midi-feedback. Loading a program (which is
part of a preset) in setBfree sends updates back to the control surface.
eg. load MIDI-program #1 -> drawbars on the organ move to reflect this
change. Likewise for changes using the GUI.
I think this is the core issue.
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.
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.
(LV2 introduced preset banks a few weeks ago)
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.
You either expose *all* the data as LV2 or none at all.
Currently you're at none at all. :(
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.
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.
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?)
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.
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?
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.
If we keep using < 100 parameters the hosts will never have an incentive
to handle them better.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
