[LV2] RFC: ui:requestParameter feature

[Hanspeter Portner]

Am 18.02.20 um 10:42 schrieb 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.

What about providing any number of accompanying metadata
(no matter whether the host cares or not) ?

Just a wild idea for it to be more future-proof.

e.g. variadic function just as example (could well be a list of
LV2_Atom_Property_Bodies or whatever).

LV2UI_Request_Parameter_Status (*request)(LV2UI_Feature_Handle handle,
  LV2_URID key, ...);

request(handle, myparam, NULL);

request(handle, myparam, mime:type, mime:audio/wav, NULL);

request(handle, myhiddenparam, rdfs:range, atom:String, mime:type,
  mime:text/plain, NULL);

>> 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.

Thanks, got it.