4 Feb
2003
4 Feb
'03
4:01 a.m.
On Tue, Feb 04, 2003 at 02:11:22 +0100, David Olofson wrote:
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.
Not really.
Ugh!
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, 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. 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. 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