On Mon, 28 Nov 2005 04:57:56 +0100 Florian Schmidt <mista.tapas(a)gmx.net> wrote: Another sidenote: This plugin will probably not work in "freewheeling" modes, i.e. for an ardour mixdown (if ardour supported DSSI ;)). It relies on regular timing for its process calls because the real work is offloaded to another thread. To fix this, a host would have to have an ability to tell the plugin, that it doesn't run realtime anymore. in this case, the plugin working scheme would have to be changed to run in a single thread for the nonrealtime operation. This would be possible. But afaik DSSI doesn't have a provision for this. Another note: zero-additional-delay mode (as jack_convolve does) is also not (yet) possible with dssi_convolve as the host has no way to tell the plugin its buffer size. If it had this ability, there would be a way to add zero-additional-delay mode to dssi_convolve which would basically work the same as jack_convolve's (simply using a partitionsize equal to the host's buffersize) with the (only technically interesting) exception that it would still need an internal buffer to collect samples for the whole buffer as DSSI plugins' buffer sizes can be chopped into chunks by the host (as LADSPA allows), which is necessary for automation purposes (changing control data on non bufferboundaries. This is will have a slight performance drawback, but not in delay terms. Ah, there would be another guarantee needed besides the host telling the plugin its buffersize: the host will call the plugin with max. buffersized process chunks plus it will have to chop chunks at least at buffer boundaries, too (i.e. process chunks may cross over a buffersize boundary). I wonder how this could best be implemented in DSSI w/o breaking the API. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org