[LV2] Buffersize, Options and Externtion-Data
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
> 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
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