5 Feb
2003
5 Feb
'03
7:32 a.m.
On Wednesday 05 February 2003 09.31, Sami P Perttu wrote:
[...]
First of all, I think we have some terminology confusion here. We like
to think of "linear pitch" as something that's linear in musical
terms, ie 1.0/octave. Hz, rad/s and samples/period would be
logarithmic units, from this perspective.
Anyway, the reason for not using Hz or similar in the API is that such
units are harder to deal with, pretty much no matter what you want to
do. The only exception is when you actually want to have some
periodic action driven by it, ie sound. Thus, rather than using Hz in
the API and having event processors and whatnot convert back and
forth, we use linear pitch (1.0/octave) throughout, and leave it to
the final stage; the synth, to convert it into whatever drives it's
oscillators. Which, mind you, is not necessarily Hz or
samples/period! It may well be coefficients for a resonant filter you
need.
As to actually doing the conversion, I suppose we could throw some
inline implementations into the plugin SDK. (One with an interpolated
LUT and one plain FPU based - although I'm not sure the former is of
much use on modern hardware. FPUs have faster LUTs! ;-) It's rather
trivial stuff, but it might as well be there, given that it's pretty
universal and makes life a bit easier, especially for DSP beginners.
//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 ---
The more I'm thinking about this the more biased I
am toward just
one process() that replaces values. And an in-place-is-okay hint.
No gains or DRY and WET controls. The host can probably reserve
some host-global buffers for mixing, no? The cache impact wouldn't
be big in that case. Somebody should do some actual measurements to
find out.
Yep, although my experience with optimizing Audiality on PC133 DRAM
machines is that it's *very* easy to end up memory bound, even if
you're free to reuse buffers and whatnot any way you like. Memory is
just dog slow in relation to CPU bandwidth, and 333 and 400 MHz DDR
isn't *that* much faster, really...
A small but seemingly annoying can of worms is the
case when you
have WET and DRY, more than one audio output, and some of the
outputs use the same buffer. Now you have to impose that the plugin
write its outputs in the right order to enable the host to
calculate suitable DRY controls.
Yes, that's a good point. Didn't think of that. With just the WET
control, there's no problem with pointing multiple outputs to the
same buffer, but the DRY control would scale the buffer once per
output... *heh*
...pitch...
I'm still having problems understanding why logarithmic frequency
is better than linear. Doesn't it violate the principle of keeping
plugins as simple as possible? Most plugins need linear frequency.
How is the conversion done? Well, maybe there could be a control
iterator that provides for it. Please tell me about your plan.