Subject: Re: Fwd: Re: [linux-audio-dev] XAP: Pitch control
From: David Olofson (david_AT_olofson.net)
Date: Thu Dec 12 2002 - 22:47:50 EET
On Thursday 12 December 2002 16.10, Nathaniel Virgo wrote:
> On Thursday 12 December 2002 12:18 pm, David Olofson wrote:
> > On Thursday 12 December 2002 12.43, Nathaniel Virgo wrote:
> > > In
> > > fact, linear_pitch is probably better for this kind of
> > > arpeggiator because you can create octaves, which you can't do
> > > in general in note_pitch.
> >
> > Well, considering that an octave is another arbitrary unit (a
> > scale doesn't *have* to have octaves!), you might as well have
> > the "octave" as a parameter, just like the other offsets.
>
> Yikes, that would be horrible, the user would have to make sure
> that the right number was always used, depending on the scale
> converter.
Yeah - but that's what you get if you're using a note based thing
with non-12t scales... One could have some standard way for scale
converters to export basic information about the scale, but just like
there's no simple, generic description of all scales, there's
probably no simple "correct" set of values to export either.
Notes/octave would be nice and handy - but what if it's not an
integer number, of "octaves" vary in size over the scale...?
> Maybe it makes sense sometimes though - it's a decision
> for the plugin writer really. The point is that some
> pitch-processors make more sense in linear-pitch than in
> note-pitch.
Yes indeed - and you can have both types. Just put them on the right
side of the scale converter. (The different control type hints will
ensure that.)
> I quite like the idea of a scale-less arpeggiator.
So do I - but I'm quite sure it would have to understand even more
about scales than an advanced scale converter, unless it's working
only with ET. And even then, you might find it to be in conlict with
the rest of the song every now and then...
> > * Have a basic scale converter built into the host.
> > It will essentially act as a Plugin, but would be
> > an integral part of the Host, and thus, the Host
> > has total control over it. This converter could
> > then be used automatically whenever the user makes
> > a note_pitch -> linear_pitch connecton. Since
> > manually inserting an external scale converter
> > plugin means you no longer have note -> linear
> > connections, the host stays out, and the scale
> > converter plugin works as expected.
> >
> > * Tell the host about all available scale converter
> > plugins, and most importantly, tell it which one
> > to use by default when note -> linear connections
> > are made. Now, it will probably be best to make
> > the conerter plugins visible in the UI, since there
> > is no guarantee that the scale converter selected
> > as default is actually useful without some tweaking.
>
> These both require an "I am a scale converter" hint in the API
> really, but that's no big deal.
Well, you *could* take the fact that all scale converters have
note_pitch inputs and linear_pitch outputs as a hint... Not
everything with that configuration *has* to be a scale converter, bit
in the first case it's irrelevant (since the host has a built-in
default scale converter), and in the latter case, the user or host
must pick *one* default converter. In both cases, manually inserting
an "explicit" scale converter is no different from inserting just any
kind of plugin.
> I can imagine a smart sequencer putting note_pitch processors in a
> seperate part of the GUI than everything else, thus keeping pitch
> converters implicit until you want to change them. This is another
> reason for wanting to keep note_pitch processors completely
> seperate.
I can't quite see why a GUI would want to hide the actual flow of
control in this way - but sure, it would be handy if you could
easilly tell whether a plugin is really *supposed* to be a scale
converter.
> The thing is, the more I think about this, the more I come to
> suspect that it's unnecessarily complicated and not the Right Way
> to handle this. Let's compare it to this much simpler scheme
>
> * all pitches are in 1.0/octave.
> * most sequencers will work in 12tET, and output pitches
> accordingly.
Well, it would *work*, but now we're back at hardcoding 12tET into
the API...
> * some sequencers may directly support different
> scales, or completely scale-less composition.
Yes, that would make sense, but then you *have* to perform any note
oriented processing inside the sequencer. I suspect this will soon
result in yet another plugin API.
> * event processors can assume whatever scale they want, but
> wherever possible they should assume relative pitch. This means
> that pitch-bend will work as expected.
What's your definition of "work as expected" here?
> * synths, effects, etc should only ever worry about pitch, not
> scale.
Agreed.
> * people who want to use fancy scales with a sequencer
> designed for 12tET can use pitch->pitch plugins as scale
> converters. Most will be 12tET->[another scale] so they will
> assume input of that form. Users in this case will have to
> understand where in the chain to put the converter, but these will
> typically be advanced users anyway. This is a hack, but using
> fancy scales with a 12tET host always will be.
And if hosts are forced to be 12tET by the API (or eliminate the
possibility of using note oriented event processors), this is not a
choice, but something that is dictated by the API.
> The only advantage of our scheme compared to this one is that the
> use of non-standard scales with 12tET hosts is kind of directly
> supported a bit, with certain limitations. It's very nearly
> equivalent to this, only more complicated.
You're forgetting that a distinction between note pitch and linear
pitch makes hosts aware of the difference, and thus, allows them to
keep track of which pitch data is in what format. That is, it's
possibly to guide users of scale converters quite a bit, while other
users don't even have to know about the excistence of scale
converters.
> The only real disadvantage to this scheme is that some
> note-processing algorithms probably don't work in relative pitch.
> For example, if for some reason you wanted to map all 12 tones of a
> normal scale onto just the white keys, while keeping the pitch bend
> range at 2 semitones, you wouldn't be able to do it in this system.
> The note_pitch way of doing things doesn't solve this either, come
> to that, it just makes the problem less obvious.
Right; you would need the MIDI converter to output pitch bend as a
separate control, so you can apply it inside the scale converter.
(After wouldn't work, since with non-ET scales, pitch bend range and
linearity depends on which note you're bending.)
> I propose the folowing soluion:
>
> * a library could be implemented that can load, save and edit
> scales, and handle the conversion (internally to the sequencer)
> between note numbers and linear pitches. This is probably a much
> better way to ensure that arbitrary scales can be supported.
Could work, but it's an extra API to be designed.
> * processes that absolutely need to deal with notes can then be
> implemented within the sequencer, using this library.
I'm worried that that will result in someone designing a separate API
for "MIDI plugins". This happened to VST - although not because of
lack of support for notes, but because hosts generally assume that a
VST plugin *must* have audio ins and/or outs.
Either way, I've already mentioned that you *can* run the whole
system as 1.0/octave if you like. Just have the host allow implicit
casts, or insert a NOP plugin. (Essentially the same thing; the NOP
plugin does not have to exist physically in the net.)
I'd also like to point out that if you use a sequencer that actually
outputs *linear_pitch* (whether it's hardcoded for 12tET, is
scaleless or whatever), this whole argument of whether to have
note_pitch or not becomes largely irrelevant, since note_pitch just
becomes another control type hint; one that you may or may not care
to use at all.
What I'm thinking about is basically going back to the "all controls
are just controls" way of thinking, and more or less disregard
control type hints - including note vs linear - as *hints*. Because
that's what they are in the end of the day, and we'll need lots of
them anyway, to be able to automatically map outputs to inputs in any
sensible way at all.
If you're a modular diehard, just tell your host to STFU about
"control type incompatibilities", and get to work. The hints may be
of some interest to you as documentation, but that's all.
//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 ---
This archive was generated by hypermail 2b28 : Thu Dec 12 2002 - 22:49:54 EET