[LV2] LV2 best practices

[Robin Gareus]

Thanks Gabriel, Dave,

On 08/02/2012 08:59 PM, David Robillard wrote:
> On Wed, 2012-08-01 at 20:07 -0500, Gabriel M. Beddingfield wrote:
>> On 08/01/2012 04:22 PM, Robin Gareus wrote:
>>>
>>> 1) "advanced mode" - imagine plugin that has a couple of settings that
>> [snip]
>>>
>>> I thinking about one of the following:
>>> a) two plugins (one with all controls, one with only common controls)
>>
>> This sounds like the cleanest solution.
>>
>> In fact, you can /declare/ two plugins in your manifest, but when you 
>> instantiate it... you instantiate the same object.
>>
> 
> Big nuisance to switch between them.  Variants suck, in general.

ack, although in my case that's likely a non-issue.

>>> c) use http://lv2plug.in/ns/ext/port-props/#displayPriority
>>
>> I doubt any hosts actually utilise this property.
> 
> True, but this is what it is for.  A metadata solution is clearly
> superior.
> 
> Since lots of controls showing up isn't the end of the world, I would
> just do this anyway, and push hosts to support it.


I'll go for a+c. Hopefully hosts supporting #displayPriority will show
up sooner or later and (a) will become obsolete.

> If it's really, really the end of the world if some controls show up in
> all hosts as they are now, then I guess separate plugins is the only
> solution.
> 
>>> 2) "static configuration". Assume a plugin has static configuration that
>>> can only be set on initialization and can not be changed later (e.g. the
>>> temperament of a synth). I can not see a good way how to deal with that.
> 
> We do really need instantiation arguments, 

+1;

> but they would not be able to
> change ports.  Ports are, for better or worse, static.

+1; // no problem

>>> Some thoughts:
>>> It might be possible to re-init the whole plugin using a port marked as
>>>    http://lv2plug.in/ns/ext/port-props/#expensive
>>> but if re-initialization requires memory allocation it must not be done
>>> from a RT-callback. A dedicated (non-rt) helper thread could be spawned
>>> to take care of re-init and the plugin remain silent until re-init is
>>> complete. Dirty hack or what? :)
> 
> All of these "control ports that break the rules" properties are
> unsupported, and probably will remain that way forever since they are
> terrible.  I do not suggest using them and do not plan on implementing
> them in anything.  I only put them in that extension in an effort to
> consolidate all the port properties out there.

Don't say that too loud, otherwise no-one will ever implement
#displayPriority and similarly valuable properties  :-P

>> Worker thread FTW.  With the Composite sampler, I use a worker thread to 
>> load samples and do misc. non-RT work.  Works pretty good -- you can 
>> load a new drum kit during playback without missing a beat.
> 
> ++
> 
> If you need to do expensive and/or non-realtime things, use the worker.
> That's what it's for.

Ah thanks. A config-file loaded by a worker-thread in the background is
the way to go, then.

Cheers!
robin