2 Jun
2012
2 Jun
'12
2:22 a.m.
On Fri, 2012-06-01 at 22:56 +0000, Fons Adriaensen wrote:
On Fri, Jun 01, 2012 at 06:42:01PM -0400, David
Robillard wrote:
Yes.
On Fri, 2012-06-01 at 22:22 +0000, Fons
Adriaensen wrote:
(Maybe it's just too late for me to grok this...)
So it's the plugin asking the host what it can expect ? On Fri, Jun 01, 2012 at 06:09:06PM -0400, David
Robillard wrote:
This is a host-provided callback which the plugin can use at
instantiation time to figure out the block length characteristics,
whatever they may be. LV2_Buf_Size_Status
get_block_length(LV2_Buf_Size_Buf_Feature_Handle handle,
uint32_t* min,
uint32_t* max,
uint32_t* multiple_of,
uint32_t* power_of);
This callback just describes reality to the
plugin at instantiation
time.
That 'to the plugin' confuses me - isn't this supposed to be
the plugin telling the host what it (the plugin) needs ? Isn't the LV2 way to do this via features (i.e.
the plugin
checking which features the host provides) ?
Yes, this callback is in a feature struct. Essentially "feature" just
means "thing provided by the host"[1].
Restrictions would also be features, but nevermind that. Regardless of
restrictions, plugins need to know the actual situation (for example,
right now I need to know max, and have no restrictions). It decomposes
nicely.
Not mentioning any of that was no mistake[2]; I am attempting to farm
precisely one piece of information: whether or not the above callback
can adequately express any reasonable block length situation; i.e.
whether or not any plugin could know "yes, I can run" or "no, my
requirements to run are not met".
There is no point confusing the thread with restrictions since that part
follows directly from the above.
Also, I said something stupid about constant size earlier. Of course,
constant can be expressed with min == max.
-dr
[1] Poor choice in terminology here, it turns out
[2] I know this stupid list and how to extract useful information from
it and ignore the rest ;)