11 Dec
2002
11 Dec
'02
10:10 p.m.
David Olofson wrote:
That's not rude - I don't think anyone is
*totally* sure about this...
Though, you might want to note (pun not intended) that I'm really
talking about "continous pitch" - not note numbers, as in "integer,
MIDI style". You could think of the relation as
linear_pitch = f(note_pitch)
where f() is a function of your choice. You could write it as
pitch = f(pitch)
but how long would it take before the first user wonders why you get
1 tone/octave if you connect a sequencer directly to a synth? :-)
Right, but would the *user* actually see any of this? I was under the
impression that any
details of pitch control would be handled by the plugins themselves, and
any mapping of
the user's preferred frequency-based frame of reference to note_pitch or
linear_pitch
would be handled transparently. The only people who might need to worry
about this
would be coders, and as I think someone pointed out, anyone who can
write DSP
code can do the conversion from whatever pitch system they wish to use
(if any)
to whatever pitch system XAP eventually ends up using internally.
That said, continous note_pitch is not more bound to
notes than
linear_pitch is to octaves. Both are *continous*, and 1.0/note,
1.0/octave or whatever are little more than units.
Fair enough.
2) my coding skills are still pretty rudimentary.
...but if your math and music theory is strong, you can work with
notes (rounding...), continous pitch or directly with linear pitch.
If you're lazy, notes are easy, and work with traditional theory.
If you want to do the Right Thing (IMHO), you could consider coding
uniersal harmonizers and other event and/or audio processors that
think entirely in linear pitch. :-) (This is what the VST guys told
me would be very, very hard, next to impossible, no one would ever
want to do that, etc etc. Ok, ok! Have notes, then...)
I'm pretty sure I don't understand enough about DSP coding to even think
about this. :) I'll leave
that one to Steve (who seems to have no shortage of projects at the
moment anyway.)
The need is there, because the API is supposed to support sequencers
and event processors that are based on traditional (or other note
oriented) music theory. Preferably, this should be possible without
confusing users too much, which is why a separation of pitch "before
scale converter" and "after scale conerter" is needed.
Right, but couldn't you just have a function that maps arbitrary pitch
systems to whatever
ends up being the internal unit? I'm pretty sure this was thrown around
already anyway...
You *could* do only 1.0/octave - but how logical is
that when you
have a scale converter ahead of you?
Not very, I suppose.
Should that scale converter
assume you're feeding it 12tET ((1/12)/octave), 1.0/note, or what?
The whole point with note_pitch is to answer that question once and
for all: "It's 1.0/note before, and 1.0/octave after, period."
Right....
(Off to ponder.)
//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 -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---