Re: [LAD] Plugin buffer size restrictions

On Mon, 2012-05-28 at 17:08 -0400, David Robillard wrote: [...] Back to the buffer size issue... (which is actually tangent to what this discussion ended up being about but is sometimes useful anyway) I am experimenting with adding the following callback. As far as describing the block length goes, I can't imagine this not being able to represent any reasonable situation, but just in case, I present: /** Get the limits on block length. The values here are restrictions on the sample_count parameter of LV2_Descriptor::run(). @param min Set to the minimum block length. @param max Set to the maximum block length, or 0 for unlimited. @param multiple_of Set to a number the block length will always be a multiple of, possibly 1 for arbitrary block lengths. @param power_of Set to a number the block length will always be a power of, or 0 if no such restriction applies. */ 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. As far as plugins specifying requirements goes, it seems complete to allow the plugin to specify, for each field: 1) A specific value 2) That some value must be given The goal here is simply to be able to convey any reasonable restriction on the block length. Whether or not people will/can actually implement a given restriction is irrelevant. That said, in practice, I suspect: * max will be usually available (e.g. the Jack buffer size) and is widely useful * convolution plugins may require power_of 2 and perhaps min * requirements for multiple_of, or power_of any value but 2, are probably useless If anyone can think of a block length restriction that can not be described by this scheme, do tell. Cheers, -dr