5 Feb
2003
5 Feb
'03
9:25 a.m.
On Wednesday 05 February 2003 14.00, Sami P Perttu wrote:
Not if you're using an optimized approximation. That generally boils
down to a plain polynomial or similar function, translating whatever
you have directly into whatever you want.
Yeah, we can have all sorts of stuff like that. It's not really part
of the API, so it won't be as hard to "get stuff in" - although it's
obviously still a good idea to keep things nice and clean, and avoid
obvious redundancies. After all, an SDK isn't of much help if it
takes longer to find and/or understand what you need than it would
take to implement it on your own.
//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 ---
On Wed, 5 Feb 2003, David Olofson wrote:
Not quite. It's only a matter of *where* to perform the conversion. It
can never be avoided entirely. (Unless we assume that users will want
to paint events in piano rolls with Hz on the vertical scale, that
is. ;-)
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
Okay, that is some kind of answer. The needs of the event
processors outweigh the needs of the audio processors. oscillators.
Which, mind you, is not necessarily Hz or
samples/period! It may well be coefficients for a resonant filter
you need.
I guess you'd still convert them to linear frequency on the way. As to actually
doing the conversion, I suppose we could throw
some inline implementations into the plugin SDK.
Yes, a control iterator would be nice: something that takes a pitch
ramp event as input and then produces Hz values each sample as
output.