11 Dec
2002
11 Dec
'02
11:13 p.m.
On Thursday 12 December 2002 03.10, David Gerard Matthews wrote:
Well, I was thinking about doing it with controls; not audio - which
would mean that basic physics and music theory apply. Say, you have
fundamental notes and a melody, and you want to add suitable chords;
that kind of stuff. (Which I normally do manually by ear, but
anyway... :-)
But that's what this *is*. It's just that instead of calling a host
function to convert your internal note_pitch values, you send them as
is, in the form of 1.0/note. That way, the host or the user can
insert a plugin (or specialized host object) that performs the
conversion. The user gets the benefits of not having scale support
hardcoded into the host, and the plugin developer doesn't have to
figure out what scale to ask for when converting.
David Olofson wrote:
Yes - unless you make it possible for hosts to tell note and linear
pitch ports apart.
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.
It can't be *entirely* transparent, since users might actually want
to use something else than 12tET, or even different scales in the
same net.
However, if you just say that note_pitch and linear_pitch are
incompatible, host can deal with it automatically, or just refuse
direct connections, since the controls are incompatible.
12tET-only hosts can simply insert something that does linear_pitch =
note_pitch * 12.0, and be done with it. More sophisticated hosts
would allow the user to select other scales.
*Any* host will be able to host a plugin that takes note_pitch and
generates linear_pitch (that is, a scale converter plugin), as that
will just result in connections between 100% compatible controls.
Host doesn't need to understand what the plugin is doing.
The only people who might need to
worry about this
would be coders,
Yes, host coders - and the few that hack pitch converters.
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.
Yes, but if you are supposed to apply some traditional music theory,
and get 1.0/octave, what do you do? Who tells you what scale to use,
to "reverse engineer" each pitch change? (Note that you may have
several senders on each Channel, each one controlling it's own set of
Voices. Assume same scale?)
And supposed you're a sequencer, thinking in notes. How do you know
what scale the user wants you to use for the note -> 1.0/octave
conversion?
[...]
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...
A few times, I think. :-)
//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 ---