[LV2] Writing to control input ports w/o UI (DSP -> host; via atom output port) - RFC

[David Robillard]

On Sat, 2020-04-18 at 10:47 +0100, Rui Nuno Capela wrote:
> > Most importantly however, thanks for prototyping this, but PLEASE
> > DO 
> > NOT RELEASE IMPLEMENTATIONS THAT USE URIS IN LV2 NAMESPACES THAT DO
> > NOT EXIST IN LV2 MASTER!  Use URIs in some other namespace at first
> > for things like this, people can't invent whatever URIs in the LV2 
> > namespaces they want, that has caused real problems in the past.
> > 
> 
> Don't worry. Although already implemented and working as proposed, in
> qtractor and the vee-ones upstream, it's all still experimental code
> and
> not yet "officially" released (simply as that, the new proposed URIs
> are
> currently declared as above with `#ifndef`/`#define`s).

If it is disabled by default you can probably get away with this, but
plugins on typical user machines should not do such things.  There will
probably be built-in checking in lilv shortly to outright refuse to
load plugins that do this, since I see no other way to make it stop
happening.

> Besides, the new couple of URIs are here still proposed to the
> `LV2:Atom` namespace, for which I believe is the right one, as this
> is
> NOT a brand new  extension or vocabulary on its own: it's just about
> one
> and simple possibility that's been missed here since a long time ago
> :)

Sorry, but on this I entirely disagree.  The atom extension has a quite
well-defined scope: it defines just the basic data model, and a port
type and some port protocols for UIs.  It doesn't contain any random
features about controlling plugins and stuff like that.

-- 
dr