On Monday 29 January 2007 09:08, Steve Harris wrote: > Ah, well the host is not supposed to change port values during run() > anyway, the idea in LADSPA (and LV2) is that the host should chop the > run() block where port values change. In practice not all hosts do > that, some just pick a suitably small block size, eg. 32 frames and > quantise the changes to that rate.
Hi, let me chime in because it kidna fits into the subject. I have defined two (very very simple LV2 extensions): "The extension’s URI is http://tapas.affenbande.org/lv2/ext/fixed-buffersize All that a plugin needs to check is whether a host feature with this URI exists and the data will be a uint32 containing the buffersize. The host is only allowed to call the plugin’s run function with a buffersize equal to the one specified by the host feature. There’s a second extension: http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize which is identical to above but with the additional requirement that the fixed buffersize has to be a power of two." I don't need to have the URI point to my site. If you want to integrate it into the official LV2 standard i'd be more than happy.. For anyone who might ask: "why do we need this"? Well the answer is that some algorithms (especially fft based) perform much better when the buffer size is known (because they must operate with a fixed buffersize internally). With anyone of these two extensions provided by the host, those plugins can avoid additional delay from buffering, etc.. We discussed on #lad whether a guarantee that the framecount of subsequent run () calls add up to a fixed buffersize is enough.. I wasn't sure about this. But i think now, that it's not a good idea. Here's a good counterargument: Imagine an fft based plugin that uses the host buffer size as internal fft size. Then with this guarantee it would have to collect data until an fft buffer is full. While waiting for this and processing subsequent these smaller buffers, it will have to produce output, but it doesn't have the fft result yet. Thus causing unavoidable delay (of one total buffersize).. Flo -- Palimm Palimm! http://tapas.affenbande.org