[LV2] Feature request: DSP write_function() ?

[David Robillard]

On Wed, 2020-12-23 at 19:21 +0100, Hermann Meyer wrote:
> 
> Am 23.12.20 um 18:02 schrieb Hanspeter Portner:
> > Please open an issue on gitlab/github, this is the wrong place for
> > that, imho.
> 
> 
> Don't get me wrong please, I'm not writing here about a special host
> have special issues. My concern is, that, all hosts have issues with
> patch:Set/Get. Only Qtractor is a exception here.
> 
> For me, and I speak here as a plugin developer, it makes no sense to
> open issues on any host I tried, discus the issue with any one
> individual, while any host developers been members of this list.
> 
> It would be nice when we could find a agreement for how to implement
> this feature in general, so that plugins and hosts could use it.
> 
> While it is no problem for a plugin to use it's own atom ports, and
> bypass the host UI, I believe it will be more useful when the host is
> able to provide a internal UI and therewith automation features. My
> interpretation of the patch:Set feature is exactly that.
> 
> It may absolutely be that I do things wrong in my interpretation of
> the
> interface, surly it will contain misinterpretation in the
> implementation, but still, without a agreement about how to implement
> it
> it will be useless (in a community view) anyway.

It sounds like you have the right idea, but to be sure I'll describe
the basic intent of this stuff here so we're all on the same page:

Plugins can implement parameters as properties.  The patch extension
describes an atom-compatible protocol which can be used to get
(patch:Get) and set (patch:Set) their values.  All of this is something
a plugin/UI can just do and no special host support is required (other
than transmitting messages between UI and plugin at all, of course).

This protocol happens to be transparent and standard, so the host can
also interact with them via the same protocol.  patch:readable and
patch:writable are there so the host knows which parameters are
available for this sort of use.

("Parameters", which are sort of a conceptual thing, can also be
controlled via control ports via lv2:designation.  There's sort of a
transport-agnostic thing going on here, but the terminology is perhaps
a bit too overloaded and/or confusing).

In an upcoming point release I intend to heavily revise the
documentation, so I want to make sure I understand what's unclear about
it.  My understanding is that it's just not clear exactly what
patch:readable and patch:writable imply for hosts?  I'm a bit lost as
to whether a bunch of hosts just haven't implemented it very well yet,
or if it's really unclear what should happen at all.

-- 
dr