4 Feb
2003
4 Feb
'03
noon
On Tuesday 04 February 2003 08.54, Steve Harris wrote:
Yeah. It's just a matter of who does the conversions.
If we're thinking in modular synth style terms, you'll need some form
of gain + offset control, at the very least, to connect ins and outs
that aren't really supposed to be connected. I don't think that's an
issue.
As long as you connect ins and outs of the same type, they'll
generally have compatible ranges. If not (say, your filter can't
handle more than Nyqvist/4, but the PITCH output that controls it has
no absolute limits), you most probably want *clamping* rather than
scaling, so just making everything [0, 1] won't be of any help.
Well, it *is* an implementation thing... Hosts can just figure it all
out beforehand, so all buffers will be in place before the net enters
RT context - and then there would be no need for an RT safe audio
buffer pool, of course.
Seems like a pool of audio buffers would be a nice and simple way to
provide RT safe "dynamic" memory allocation to plugins, though, and
that's the idea. You could (ab)use events for that, but they're
really rather small. :-) (32 bytes, most probably.)
Not really.
Basically the same thing as plugins implementing only one of run() and
run_adding() - you *can* emulate one with the other, although it's
not free, of course...
Ugh!
Ok, how about this:
* Hosts must provide basic information such as audio
sample rate, maximum buffer size, audio thread
characteristics (RT/offline) etc, when asking a
plugin lib's "plugin factory" for meta-data.
* If this information is changed, all meta-data
is invalid. Hosts must ask for new meta-data before
trying to instantiate plugins again.
*How* expensive? I'm aware of the serious impact when it causes cache
misses, but how much does an out[i] += in[i] * gain; stage cost? (I
could just benchmark it, but I have only PC133 memory machines here.)
Yeah, and this has been going on for a good while... However, DSP code
seems to follow the same trend; more cycles/sample, for higher
quality and/or cooler effects. That, OTOH, does not apply to
inherently simple/fast effects, such as basic state variable filters
and gain/pan controls. These will always waste CPU cycles stalling on
memory access, and will do more of it as memory bandwidth keeps
lagging behind.
One could say that as long as we're dealing with a few large heavy
effects and polyphonic synths and samplers in a net, this isn't much
of an issue. In a virtual mixer with lots of little EQ plugins and
whatnot, it might be a real performance issue. Even worse with
anything like a modular synth.
On Tue, Feb 04, 2003 at 02:11:22 +0100, David Olofson
wrote:
Yeah. Some plugins might non-deterministic (ie highly input dependent,
and/or processing huge internal buffers without scheduling the work
evenly over process() calls) if you use the highest quality modes,
though - but then they'd just flip the "RT capable" hint, or maybe
just set a warning hint.
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.
How do you mean? I think 0.0 for "worst" and 1.0 for "best" would do.
Is that too specific? ;-)
> > > * Tail size. (Can be unknown!)
[...]
Useful though. And most plugins can estimate it pretty
accuratly,
it will be used for post-roll. Ardour could use this, for example.
Yeah, I'm not arguing against the feature; just against making it more
complex and sophisticated than most plugins and host have any use
for. A way of saying whether you generated output (any, or per output
buffer) during the process() call might be another.
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]
Ok.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---