On Tue, Feb 04, 2003 at 02:11:22 +0100, David Olofson wrote: > PTAF uses float, subdivided in four ranges; [0,.25], [.25,.5], > [.5,.75] and [.75,1], where the lower two ranges are for real time > use, and the higher two are for off-line use.
This doesn't make snese to me, off-line and wuality should be independent. Plugins should also be free to use the range how they like. > > > * Tail size. (Can be unknown!) > > > > in my notes, in a different way, but this may just be simpler > > Yeah... It's guessing and various hacks anyway for many plugins, so > you can't require much, and I don't think there's much point in going > below block granularity. It gets hairy, and I think few hosts and > plugins will make full use of it even when it's theoretically > possible. Just too much work, and it actually *costs* cycles when you > need them most: when all plugins are running full throttle. Useful though. And most plugins can estimate it pretty accuratly, it will be used for post-roll. Ardour could use this, for example. > Yeah, but is it really that useful? Ok, VST seems to survive with the > same restriction, but I'm not sure if it actually solves more > problems than it creates. Agreed, in practice you can connect things together if you allow arbitrary ranges. > Yeah, that would be reasonable, I think. In the few cases where > plugins can't be in-place safe (or the author is too lazy), we even > have a nice, cache friendly solution: The audio buffer pool. (A LIFO > stack of preallocated buffers. Optimized hosts will probably use one > anyway, instead of fixed buffers all over the net.) Hmmmm.... not convinced. > > We can standardize a wet/dry gain control pair. But this becomes > > something every plugin needs to provide. Uggh. > > It *could* be optional... The host SDK would deal with plugins that > don't bother to implement those controls. Not really. > > Well, there also needs to be a way for a plugin to wrap other > > formats, and change all it's metadata. I imagined that a plugin > > couls tell the host that it needs to be re-examined - > > XAP_EV_GESTALT - or something. > > Yeah. Ugh! > Yeah. run_adding() is indeed nothing but a performance hack. Question > is if we really need it these days. I'm not saying that we'll ever > have enough cycles to just waste them, but focus is shifting > continously. Things are getting higher level. I disagree. Its really quite expensive. > VST is a really rather old API, and that memory bandwidth in new PCs > have increased quite a bit even after LADSPA was finalized... Not > saying that run_adding() makes no difference to anyone *now*, but in > a few years, it'll probably just be a source of annoyance. Memory bandwidth has only increased a few times, CPU bandwidth has gone up a lot. [cant reply to the rest, got to drive to a meeting] - Steve
