Re: [LAD] Plugin buffer size restrictions

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:
> > On Fri, 2012-06-01 at 22:22 +0000, Fons Adriaensen wrote:
> > > On Fri, Jun 01, 2012 at 06:09:06PM -0400, David Robillard wrote:
> > >
> > > > 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 ?
> >
> > 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.
>
> (Maybe it's just too late for me to grok this...)
>
> So it's the plugin asking the host what it can expect ?

Yes.

> 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 ;)

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Jun 2 04:15:02 2012