[LV2] Buffersize, Options and Externtion-Data

Filipe Coelho falktx at gmail.com
Wed Sep 9 12:39:39 PDT 2015

On 09-09-2015 21:00, Robin Gareus wrote:
> Hi Filipe, LV2ers,
> (cutting some parts here, please see the original email for references)
> Executive summary: There are two separate issues here:
> 1) Semantics of "maxBuffersize"
>   Is bufsz:maxBlockLength an "all time max" while the plugin is
>   instantiated?
>   Proposed answer is "yes" and we need a new "bufsz:nominalBlockLength"
>   which can change dynamically.
I agree with this.

nominalBlockLength sounds reasonable.
Maybe it's not the perfect wording, but I think currentBlockLength 
wouldn't be either.

> 2) Options API clarification:
>   Is there a difference if the Option is passed during instantiate vs
>   Pption is passed as extension-data.
> Robin says "yes", during instantiation it's const data.
> Filipe says "no" both are identical.
> If Filipe is right, Robin wants to know why there are two APIs to do the
> same :)
Ok, so I present a challenge to you:
Make the plugin able to fail to initialize when the host uses some 
options it cannot support.

If the host is going to use the plugin's option interface, it needs to 
instantiate the plugin first.

There's also the situation that dynamic properties are, well, dynamic.
But the plugin can specify what it supports via meta-data (ie, min and 
max block lengths).
Hosts that allow the plugin to run out of supported bounds should be 
considered broken.

So, in an example,
If the host doesn't support minBlockLength and the plugin requires it,
the plugin needs a way to verify that the host indeed supports it (or not).
I know you (Robin) are of the idea that plugins should always check if 
the host is good even when requiredFeatures are set in TTL.

Without using options passed as a feature in instantiate, what else is 

Now onto the long version, coming up...

More information about the Devel mailing list