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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev