[LV2] RFC: ui:requestParameter feature

[David Robillard]

On Mon, 2020-02-17 at 23:44 +0100, Hanspeter Portner wrote:
> On 16.02.20 21:57, David Robillard wrote:
> > Hi all,
> > 
> > Quite some time ago myself, falktx, and rgareus prototyped a
> > feature to
> > allow a plugin UI to request a parameter value from a host.  The
> > main
> > incentive here is to avoid needing to implement file selector
> > dialogs
> > in plugins, though you could conceptually use it for whatever else,
> > and
> > it has some other potential advantages like integrating with
> > embedded
> > host content/browsers and the like.
> > 
> > I just cleaned this up a bit and would like to make it a real thing
> > for
> > the next release, so if anyone wants to weigh in, or better yet
> > implement it:
> > 
> > https://gitlab.com/drobilla/jalv/-/commits/ui-request-parameter
> > https://gitlab.com/lv2/lv2/-/commit/540268fb05b6d42ecfaec118ab7dde0febcddde3
> > 
> > This is the simplest possible thing that gets the job done.  I'm
> > pondering whether it's a bit too simplistic, e.g. adding an
> > optional
> > subject and type parameter would remove the requirement that the
> > host
> > knows all about the parameter and allow the plugin to request a
> > value
> > for any property (set via a message) which could be quite useful
> > for
> > more advanced plugins.  Nothing else comes to mind.
> 
> This feature seems very useful, indeed.
> 
> The option to specify the type would be mandatory for hidden/dynamic
> parameters,
> though.

Well, assuming dynamic parameters aren't announced and understood
anyway.  We should, though, and this should be better parameterized. 
The general idea here is that the host inherently needs to know how to
change a parameter for it to be decently usable at all, so I don't
think grafting band-aids on here to work around that is a good idea. 
If that's not the case, it should be fixed elsewhere.

That said, a parameter can support multiple value types, so I'm leaning
towards adding a type anyway, because that makes sense in general.

I'm not sure about the subject thing.  "parameter" really needs to be
better defined one of these days... I was thinking about cases where a
plugin has several identical components, say a left and right DJ deck,
and wants to set the foo:samplePath on one or the other.

> E.g in moony I'll only be able to use this feature (and I desperately
> want to
> get rid of its crappy file dialog) if I can specify a type,
> because moony's dynamic ui parameters (which can be of arbitrary
> type:
> atom:String, atom:Chunk, atom:Float, ...) are internal to the plugin
> only and
> thus hidden from the host.
> 
> Another issue: Say the plugin ui requests an atom:String
> (representing code of
> some kind), would it make sense to be able to tell the host what kind
> of widget
> it should open ?

Absolutely not.  This is, very deliberately, not a GUI toolkit API, and
I'm not stepping on to that slippery slope even a little bit.

> * open a file dialog and send the chosen file's content ?
> * open (and keep open) an editor window and send the editor's content
> whenever
>   user saves content ?
> 
> Or is it up to the host to decide ?

It is, and I think this is important.  The UX for setting a parameter
is the host's decision, and it could be dramatically different between
hosts.  The host could, for example, have a built-in pool of .wav files
(or whatever) and a browser for them, without any file dialogs or even
file system support at all, and this will still work fine.  I think the
potential for integration makes the feature quite nice, even if the
plugin does have a file dialog (or whatever) available internally.

-- 
dr