[LV2] LV2 best practices

[David Robillard]

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.

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

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, but they would not be able to
change ports.  Ports are, for better or worse, static.

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

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

-dr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20120802/1d1be47b/attachment-0002.pgp>