[LV2] Control ports vs lv2:Parameter

David Robillard d at drobilla.net
Tue Feb 4 11:08:26 PST 2025


On 2025-01-17 11:03, Stefano D'Angelo wrote:
> Il 30/06/24 08:40, Stefano D'Angelo ha scritto:
> 
>> Il giorno mar 25 giu 2024 alle ore 23:27 David Robillard
>> <d at drobilla.net> ha scritto:
>>> On Thu, 2024-06-06 at 12:05 +0200, Stefano D'Angelo wrote:
>>>> Hi all,
>>>>
>>>> Is there a way to provide "graceful degradation" for hosts that do
>>>> not
>>>> support lv2:Parameter but still use lv2:ControlPort? Should/could
>>>> both
>>>> mechanisms be used to refer to the same parameter?
>>> Both mechanisms can be used to refer to the same "conceptual" parameter
>>> in a sense, by giving ports an lv2:designation.  This doesn't amount to
>>> a graceful degradation mechanism for old hosts, though (it could be
>>> useful for version and/or state migration among other things, but it's
>>> not a mechanism).
>>>
>>> I guess you could invent one - a message to disable actually using the
>>> value of the control ports or something - but it seems like it would be
>>> quite a mess.
>>>
>>> I'd suggest just being the chicken or the egg instead, so to speak.
>> Ok, clear. I guess I'll have to support one mechanism per plugin,
>> perhaps having different versions of the same plugin if I want to
>> support both.
>>
>> Maybe in the future we could have something like
>> "is-an-advanced/better-version-of" predicate in the RDF - like dc:
>> replaces -, so that hosts might actually hide the "not advanced/worse"
>> plugin if the better one is supported?
> 
> Sorry to resurrect this discussion after such a long time.
> 
> I just noticed that the documentation of lv2:Parameter says that "a 
> parameter could be controlled via a ControlPort, messages, or both", so 
> I was wondering if it would be ok to have both a mandatory ControlPort 
> and a lv2:connectionOptional Atom port "writing to"/"reading from" the 
> same lv2:Parameter (the Atom port would be also normally operate on all 
> other input our output controls). If that's the case, the plugin could 
> also lv2:requiredFeature urid:map, and thus effectively provide graceful 
> degradation in a sense.
> 
> Before I give it a try, do you think  this is blasphemy or does it sound 
> reasonable and feasible?
> 
> (BTW, in case you wonder, I am interested in supporting Ardour, Reaper 
> and Pipewire, and AFAIK Pipewire doesn't support reading/writing 
> lv2:Parameters via Atom ports, see https://gitlab.freedesktop.org/ 
> pipewire/pipewire/-/issues/4042.)

Hi Stefano,

No worries, sorry for not being very on top of this on my end.  My last 
year (several years really) hasn't been conducive to driving solutions 
across the whole ecosystem, just keeping things maintained is about all 
I've had time for.  I'm getting around to better implementing (and 
figuring out how to better specify) the parameter stuff now though.

The thing the quoted sentence is getting at is really just the 
"transport independence" of parameters.  A "parameter" is a slightly 
abstract thing in other words: you can change it with messages, you can 
designate a control port with it, it's sometimes stored in state, and so 
on.  The terminology here arguably isn't great, but c'est la vie.  I 
didn't consider the idea of using both at once and I don't remember 
anyone else doing so either.  The intent here was a bit more meta: tying 
parameters in general to the mechanism of control ports has been a 
disaster, so untying them avoids that problem.  If people add yet 
another mechanism or want to add OSC support or whatever, it won't 
require the user-visible breakage that this transition does, because the 
host trivially knows what all the parameter values are.  Mechanism is a 
separate thing (as it should be, and always should have been, but live 
and learn).  Practically speaking it also integrates directly with 
state, of course, but that's beside the point here.

Anyway, I don't see any concrete technical problem with having both, 
except for the conflict: a mandatory control port always has a value. 
So what does the plugin do when it gets a message that sets that 
parameter to some other value?  There's solutions to that that will 
maybe work in practice (switch to ignoring controls if you ever receive 
a message or something) but it's pretty hackey.  Worth a shot I suppose, 
if you're dedicated to trying some graceful degradation situation.  It's 
not clear what a host should do in this situation though, this would 
probably need to be decided and written down somewhere if it makes sense.

In the grand scheme of things, control ports have been an absolute 
nightmare in so many ways, I wish people were more bold and just used 
the new stuff, or even invented a better way to do parameters if that's 
necessary and pushed that instead, but I haven't had the time to take on 
such a wide-sweeping project and nobody else has either, so here we are. 
  If pipewire is the blocker here, maybe that's something to look 
into... at the moment I'm completely ignorant to that, but thanks for 
the link, I'll check it out at some point.

-- 
dr


More information about the Devel mailing list