12 Dec
2002
12 Dec
'02
11:11 a.m.
On Thursday 12 December 2002 12:18 pm, David Olofson wrote:
These both require an "I am a scale converter" hint in the API really, but
that's no big deal.
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.
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.
* some sequencers may directly support different scales, or completely
scale-less composition.
* 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.
* synths, effects, etc should only ever worry about pitch, not scale.
* 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.
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.
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.
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.
* processes that absolutely need to deal with notes can then be implemented
within the sequencer, using this library.
On Thursday 12 December 2002 12.43, Nathaniel Virgo
wrote:
Yikes, that would be horrible, the user would have to make sure that the
right number was always used, depending on the scale converter. 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. I quite like the idea of a scale-less arpeggiator.
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. This sort of
thing is in extreme danger of making the
whole thing far too confusing for the users.
If done wrong; definitely...! Problem is that there seems to be risks
of confusion no matter what you do, or how you do it. There is no
totally obvious and perfect solution.
We'll just have to decide on something that makes sense in as many
situations as possible, and try to make it "robust" by ensuring that
sufficient information to do the Right Thing is always available.
[...]
There is one good argument for making pitch
converters special,
though: A good sequencer client needs to be able to insert them
implicitly. As a user I wouldn't want to have to worry about all
this until I want to use a non-standard scale.
Right. There are a number of ways to deal with this, and I believe
most of them would not require explicit API support. Two examples:
* 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.