On Thu, Oct 03, 2024 at 05:58:57PM +0200, Robin Gareus wrote: > Ardour has not required in-place processing since v6 around 5 years ago.
Good to know. > Yet when possible, a given plugin standards support it, the extra copy step > can be avoided and the same buffer pointer is passed for input and output. What 'extra copy step' ? There isn't any. if you have A->B, the pointer to B's input can be the same as the one to A's output. No copy is necessary. It's only the requirement of being 'in-place-safe' that requires extra copies in some cases. > * It doesn't avoid copies nor optimise anything > > less memory is touched, so caches can be used more effectively. This also > leads to faster context switches. If you have a few hundred tracks with a > couple of plugins on each, things can add up quickly. With typical period sizes we are talking about very small buffers. And I'd expect a chain of plugins in the same strip to not require context switching. > As for the issue at hand. The IEM (VST3) plugins run just fine in Ardour > without in-place processing. For the current ambdec plugins it is LADSPA > that mandates in-place, isn't it? No, LADPSA never required this, only Ardour did. Which did complicate some of the simple Ambisonic related plugins. LADSPA just allows a plugin to declare that it is not 'in-place-safe'. Another 'less than useful' requirement is the one that a plugin process should be callable with an arbitrary number of samples, down to one. * It doesn't make sense for anything supposed to be 'sample accurate' because most plugins will do some parameter smoothing anyway to avoid zipper noise. * It make optimising the process code near impossible in almost all cases. Ciao, -- FA _______________________________________________ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit account or options, view archives and so on.
