11 Dec
2002
11 Dec
'02
1:24 p.m.
(Same thing again...)
---------- Forwarded Message ----------
Subject: Re: [linux-audio-dev] XAP: Pitch control
Date: Wed, 11 Dec 2002 18:15:59 +0100
From: David Olofson <david(a)olofson.net>
To: Nathaniel Virgo <nathaniel.virgo(a)ntlworld.com>
On Wednesday 11 December 2002 18.09, Nathaniel Virgo wrote:
On Wednesday 11 December 2002 4:29 pm, David Olofson
wrote:
I like the idea of enforced "explicit casting", but I think it's
rather restrictive not to allow synths to take note_pitch. That would
make it impossible to have synths with integrated event processors
(including scale converters; although *that* might actually be a good
idea)
Either way, there will *not* be a distinction between synths and
other plugins in the API. Steinberg did that mistake, and has been
forced to correct it. Let's not repeat it.
On Wednesday 11 December 2002 13.59, David Gerard
Matthews wrote:
I don't think that should be permitted. I think that this case
should be handled by a trivial scale converter that does nothing.
No synth should be allowed to take a note_pitch input, and nothing
except a scale converter should be allowed to assume any particular
meaning for a note_pitch input. Steve Harris wrote:
So do I, definitely.
There has never been an argument about <something>/octave, and
there no longer is an argument about 1.0/octave.
The "argument" is about whether or not we should have a scale
related pitch control type *as well*. It's really more of a hint
than an actual data type, as you could just assume "1tET" and use
both as 1.0/octave. On Wed, Dec 11, 2002 at 12:40:18 +0000, Nathaniel
Virgo wrote:
>I can't really say I can think of a better way though.
> Personally I'd leave scales out of the API and let the host
> deal with it, sticking to 1.0/octave throughout, but I can
> see the advantages of this as well.
We could put it to a vote ;)
- Steve
I vote 1.0/octave. If you have an algorithm that needs
to know something about the actual pitch rather than position on a
scale then it should operate on linear_pitch instead.
Yes indeed - that's what note_pitch vs linear_pitch is all about.
I think that
in this scheme note_pitch and linear_pitch are two completely
different things and shouldn't be interchangeable.
You're right. Allowing implicit casting in the 1tET case is a pure
performance hack.
That way you
can enforce the correct order of operations:
Sequencer
| note_pitch signal
V
scaled pitch bend (eg +/- 2 tones) /
arpeggiator / shift along scale /
other scale-related effects
| note_pitch signal
V
scale converter (could be trivial)
| linear_pitch signal
V
portamento / vibrato /
relative-pitch arpeggiator /
interval-preserving transpose /
other frequency-related effects
| linear_pitch signal
V
synth
That way anyone who doesn't want to worry about notes and scales
can just always work in linear_pitch and know they'll never see
anything else.
Yes. But anyone who doesn't truly understand all this should not go
into the advanced options menu and check the "Allow implicit casting
of note_pitch into linear_pitch" box.
So, I basically agree with you. I was only suggesting a host side
performance hack for 1.0/octave diehards. It has nothing to do with
the API.
//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 ---
11 Dec
11 Dec
2:50 p.m.
On Wednesday 11 December 2002 5:19 pm, David Olofson wrote:
(Oops. Replied to the direct reply, rather than via
the list. Please,
don't CC me - I'm on the list! :-)
Sorry, I just tend to hit "reply to all" because some lists seem to be set up
so that "reply" doesn't go to the list.
I like the idea of enforced "explicit
casting", but I think it's
rather restrictive not to allow synths to take note_pitch. That would
make it impossible to have synths with integrated event processors
(including scale converters; although *that* might actually be a good
idea)
That would be bad. If a synth takes note_pitch it's bound to interpret it as
12tET, which would be annoying to someone trying to use a different scale. A
synth could still have a built in event processor, but it should only process
linear_pitch events. Scale converters should definately not be built into
synths.
Either way, there will *not* be a distinction between
synths and
other plugins in the API. Steinberg did that mistake, and has been
forced to correct it. Let's not repeat it.
I wasn't thinking so much of an API distinction as a very well-documented
convention. Also I was thinking more of the distinction being between
scale-related event processors and everything else, rather than synths and
everything else which I agree would be bad.
You could enforce it with rules like "if it's got a note_pitch input port
it's not allowed to have any other kind of port, except in the case of a
plugin with one note_pitch input and one linear_pitch output, which is a
scale converter" - but there might be the odd case where these rules don't
make sense.
If you have an
algorithm that needs
to know something about the actual pitch rather than position on a
scale then it should operate on linear_pitch instead.
Yes indeed - that's what note_pitch vs linear_pitch is all about.
I think that
in this scheme note_pitch and linear_pitch are two completely
different things and shouldn't be interchangeable.
You're right. Allowing implicit casting in the 1tET case is a pure
performance hack.
That way you
can enforce the correct order of operations:
Sequencer
| note_pitch signal
V
scaled pitch bend (eg +/- 2 tones) /
arpeggiator / shift along scale /
other scale-related effects
| note_pitch signal
V
scale converter (could be trivial)
| linear_pitch signal
V
portamento / vibrato /
relative-pitch arpeggiator /
interval-preserving transpose /
other frequency-related effects
| linear_pitch signal
V
synth
That way anyone who doesn't want to worry about notes and scales
can just always work in linear_pitch and know they'll never see
anything else.
Yes. But anyone who doesn't truly understand all this should not go
into the advanced options menu and check the "Allow implicit casting
of note_pitch into linear_pitch" box.
So, I basically agree with you. I was only suggesting a host side
performance hack for 1.0/octave diehards. It has nothing to do with
the API.
//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 ---
4:36 p.m.
On Wednesday 11 December 2002 19.49, Nathaniel Virgo wrote:
Ok, then I agree.
On Wednesday 11 December 2002 5:19 pm, David Olofson
wrote:
That would be a sloppy implementation, which pretends to understand
scales, but is hardcoded to 12tET.
Either way, point taken; it's probably a good idea to at least
*strongly* discourage people from ever touching note_pitch in synths
and the like.
(Oops. Replied to the direct reply, rather than
via the list.
Please, don't CC me - I'm on the list! :-)
Sorry, I just tend to hit "reply to all" because some lists seem to
be set up so that "reply" doesn't go to the list.
I like the idea of enforced "explicit
casting", but I think it's
rather restrictive not to allow synths to take note_pitch. That
would make it impossible to have synths with integrated event
processors (including scale converters; although *that* might
actually be a good idea)
That would be bad. If a synth takes note_pitch it's bound to
interpret it as 12tET, which would be annoying to someone trying to
use a different scale. A synth could still have a built in event
processor, but it should only process linear_pitch events.
Yes - but you could not implement a useful arpeggiator that way, for
example. It would do the wrong thing as soon as you're not using
12tET anymore - and *now*, users wouldn't have clue as to why this
happens, because the synth *lies* and says that it cares only about
linear_pitch...
Scale
converters should definately not be built into synths.
I think I agree, but I bet *someone* will eventually figure out a
valid reason to do it... ;-)
Either way,
there will *not* be a distinction between synths and
other plugins in the API. Steinberg did that mistake, and has
been forced to correct it. Let's not repeat it.
I wasn't thinking so much of an API distinction as a very
well-documented convention. Also I was thinking more of the
distinction being between scale-related event processors and
everything else, rather than synths and everything else which I
agree would be bad. You could enforce it with rules like "if it's
got a note_pitch
input port it's not allowed to have any other kind of port, except
in the case of a plugin with one note_pitch input and one
linear_pitch output, which is a scale converter" - but there might
be the odd case where these rules don't make sense.
Yeah. We could "strongly suggest" things, but officially saying "you
cannot do this" about things that are physically possible is
dangerous. Host coders might actually take your word for it!
And then everyone goes "Hmm... That's actually useful, after all."
Bang! VST host incompatibilities reinvented... *heh*
//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 ---
12 Dec
12 Dec
7:45 a.m.
On Wednesday 11 December 2002 8:31 pm, David Olofson wrote:
At this particular moment I can't see any circumstance where an arpeggiator
wouldn't be better off and more useful as a seperate plugin from the synth,
which is why I think that note_pitch processors should generally be seperate.
Incidentally, I think you could make a sensible arpeggiator that worked in
linear_pitch - it could just create notes by multiplying the frequency by
integer ratios like 3/2 (which is approximated by a perfect 5th in 12tET).
It might not sound good on all scales but it would make sense.
Alternatively, if it's the kind of arpeggiator that makes sequences out of
chords then it could use either representation of pitch. 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. This sort of
thing is in extreme danger of making the whole thing far too confusing for
the users.
Well, you're probably right.
Ok, then I agree.
Point taken - you'd have to jump through hoops to actually enforce those
rules in the API.
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.
A synth could
still have a built in event
processor, but it should only process linear_pitch events.
Yes - but you could not implement a useful arpeggiator that way, for
example. It would do the wrong thing as soon as you're not using
12tET anymore - and *now*, users wouldn't have clue as to why this
happens, because the synth *lies* and says that it cares only about
linear_pitch... Scale
converters should definately not be built into synths.
I think I agree, but I bet *someone* will eventually figure out a
valid reason to do it... ;-) Either way, there will *not* be a distinction between
synths and
other plugins in the API. Steinberg did that mistake, and has
been forced to correct it. Let's not repeat it.
I wasn't thinking so much of an API distinction as a very
well-documented convention. Also I was thinking more of the
distinction being between scale-related event processors and
everything else, rather than synths and everything else which I
agree would be bad. You could enforce it with rules like "if
it's got a note_pitch
input port it's not allowed to have any other kind of port, except
in the case of a plugin with one note_pitch input and one
linear_pitch output, which is a scale converter" - but there might
be the odd case where these rules don't make sense.
Yeah. We could "strongly suggest" things, but officially saying "you
cannot do this" about things that are physically possible is
dangerous. Host coders might actually take your word for it!
And then everyone goes "Hmm... That's actually useful, after all."
Bang! VST host incompatibilities reinvented... *heh*
8:23 a.m.
On Thursday 12 December 2002 12.43, Nathaniel Virgo wrote:
On Wednesday 11 December 2002 8:31 pm, David Olofson
wrote:
At this particular moment I can't see any circumstance where an
arpeggiator wouldn't be better off and more useful as a seperate
plugin from the synth, which is why I think that note_pitch
processors should generally be seperate.
Yes. I think we have already concluded that synths should never use
note_pitch unless there's a *very* good reason for it - and so far,
we have yet to see one suggested. No proof there *aren't* such cases,
OTOH...
A synth
could still have a built in event
processor, but it should only process linear_pitch events.
Yes - but you could not implement a useful arpeggiator that way,
for example. It would do the wrong thing as soon as you're not
using 12tET anymore - and *now*, users wouldn't have clue as to
why this happens, because the synth *lies* and says that it cares
only about linear_pitch... Incidentally, I think you could make a sensible
arpeggiator that
worked in linear_pitch - it could just create notes by multiplying
the frequency by integer ratios like 3/2 (which is approximated by
a perfect 5th in 12tET). It might not sound good on all scales but
it would make sense.
Alternatively, if it's the kind of arpeggiator that makes sequences
out of chords then it could use either representation of pitch.
Yes, that's always trivial.
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.
//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 ---
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. 
12:18 p.m.
On Thu, Dec 12, 2002 at 03:10:07PM +0000, Nathaniel Virgo wrote:
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'm coming to this conclusion too, I think that note numbering is just a
red herring: you still dont have enough scale metadata to do any
processing on it, unless its ET, and then its trivial whatever your pitch
representation.
- Steve
5 p.m.
On Thursday 12 December 2002 17.13, Steve Harris wrote:
On Thu, Dec 12, 2002 at 03:10:07PM +0000, Nathaniel
Virgo wrote:
I disagree. The implicit information that note_pitch brings is that
each note is placed *approximately* at the theoretical pitch of the
corresponding note in a scale. This lets your event processors think
in terms of simplified theory (such as 12t - tuning is irrelevant),
while you can *still* tweak the tuning of each note to your taste
afterwards, by using a suitable scale converter.
//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 ---
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'm coming to this conclusion too, I think that note numbering is
just a red herring: you still dont have enough scale metadata to do
any processing on it, unless its ET, and then its trivial whatever
your pitch representation.
4:52 p.m.
On Thursday 12 December 2002 16.10, Nathaniel Virgo wrote:
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.
On Thursday 12 December 2002 12:18 pm, David Olofson
wrote:
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...?
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. 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. 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. 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 ---
8:31 a.m.
On Wed, Dec 11, 2002 at 09:31:52 +0100, David Olofson wrote:
I dont think thats true, all ET scales can be arpegiated trivially from
the octave number, and arpegiate for non ET scales is a hard problem
anyway, providing note numbers doesn't help.
A synth could
still have a built in event
processor, but it should only process linear_pitch events.
Yes - but you could not implement a useful arpeggiator that way, for
example. It would do the wrong thing as soon as you're not using
12tET anymore - and *now*, users wouldn't have clue as to why this
happens, because the synth *lies* and says that it cares only about
linear_pitch... Yeah. We could "strongly suggest" things,
but officially saying "you
cannot do this" about things that are physically possible is
dangerous. Host coders might actually take your word for it!
And then everyone goes "Hmm... That's actually useful, after all."
Bang! VST host incompatibilities reinvented... *heh*
Yes. I prefer to just now support things that are occasionaly slightly
helpful to developers, but can lead to problems later.
- Steve
8:51 a.m.
On Thursday 12 December 2002 13.26, Steve Harris wrote:
On Wed, Dec 11, 2002 at 09:31:52 +0100, David Olofson
wrote:
I dont think thats true, all ET scales can be arpegiated trivially
from the octave number,
Yes, but where do you get the octave number...?
A synth
could still have a built in event
processor, but it should only process linear_pitch events.
Yes - but you could not implement a useful arpeggiator that way,
for example. It would do the wrong thing as soon as you're not
using 12tET anymore - and *now*, users wouldn't have clue as to
why this happens, because the synth *lies* and says that it cares
only about linear_pitch... and arpegiate for non ET scales is a hard
problem anyway, providing note numbers doesn't help.
Yes it does, since you need to deal *only* with the note number. The
scale converter then generates the correct pitch for the notes in the
scale that you reference. That's the whole point with using
note_pitch and scale converters at all.
Obviously, this is *exactly* why you should not take note_input to a
synth, and why arpeggiators should be separate plugins. Put a
suitable scale converter *in between*, and "weird" scales are trivial
to handle.
//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 ---
10:31 a.m.
On Thu, Dec 12, 2002 at 01:46:29PM +0100, David Olofson wrote:
I dont think that arpegiation from a non ET scale will fall exactly on a
note anyway - though I'd have to think about that. I guess it depends what
key you're in... which can't be expressed in a note number anyway, so I
still think its redundant.
Now I think about it you wouldn't want to do arpegiation using note
numbers, what you're interested in the the pitch coefficient to get the
correct harmonic relation.
- Steve
and arpegiate
for non ET scales is a hard
problem anyway, providing note numbers doesn't help.
Yes it does, since you need to deal *only* with the note number. The
scale converter then generates the correct pitch for the notes in the
scale that you reference. That's the whole point with using
note_pitch and scale converters at all.
3:21 p.m.
On Thursday 12 December 2002 15.26, Steve Harris wrote:
On Thu, Dec 12, 2002 at 01:46:29PM +0100, David
Olofson wrote:
I dont think that arpegiation from a non ET scale will fall exactly
on a note anyway - though I'd have to think about that.
Why wouldn't it? It sure does if you *play* the arpeggio on a real
instrument...
and
arpegiate for non ET scales is a hard
problem anyway, providing note numbers doesn't help.
Yes it does, since you need to deal *only* with the note number.
The scale converter then generates the correct pitch for the
notes in the scale that you reference. That's the whole point
with using note_pitch and scale converters at all. I guess it
depends what key you're in... which can't be expressed in a note
number anyway, so I still think its redundant.
Well, then we're into this "tweaking notes for better harmonies"
thing again... That's indeed hairy stuff, and plugins that want to
actually *do* that (rather than just switching between whatever notes
they get in an input chord) will have to understand quite a bit more
than notes. You'll need to either operate entirely in linear pitch,
or hint the plugin a little about what scale you're using. The latter
is what a MIDI solution would do (unless it just assumes 12tET), but
obviously, it's rather silly to do it that way if you can just work
in the linear_pitch domain, after the scale converter, instead. After
all, *perfect* harmonies are not strictly bound to scales anyway.
Now I think about it you wouldn't want to do
arpegiation using note
numbers, what you're interested in the the pitch coefficient to get
the correct harmonic relation.
In some cases, yes - but remember that the arpeggiator is not the
*only* plugin in the system. If you play other synths as well, you'll
probably want the arpeggiator to respect the scales used for those,
rather than trying to find "perfect" harmonies all on it's own. With
notes + scales, you make this trivial, even with non-ET scales, since
all you have to do is use the same scale everywhere.
//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 ---
4:37 p.m.
On Thursday 12 December 2002 7:16 pm, David Olofson wrote:
On Thursday 12 December 2002 15.26, Steve Harris
wrote:
I think that these kind of hints would have to be available for other reasons
as well, and I think they would have to be impossibly complex - see below.
I guess it
depends what key you're in... which can't be expressed in a note
number anyway, so I still think its redundant.
Well, then we're into this "tweaking notes for better harmonies"
thing again... That's indeed hairy stuff, and plugins that want to
actually *do* that (rather than just switching between whatever notes
they get in an input chord) will have to understand quite a bit more
than notes. You'll need to either operate entirely in linear pitch,
or hint the plugin a little about what scale you're using. The latter
is what a MIDI solution would do (unless it just assumes 12tET), but
obviously, it's rather silly to do it that way if you can just work
in the linear_pitch domain, after the scale converter, instead. After
all, *perfect* harmonies are not strictly bound to scales anyway.
Unfortunately I can think of a case where it's far from trivial: an advanced
twelve-tone arpeggiator that wants to play a major or minor chord depending
on what note is being played, so that it can stay in the right key. This
requires the plugin to know not just the ordering of the notes on the scale,
but also some arbitrarily complex data about their harmonic and cultural
relationships to each other.
Presumably this has an analog in some other types of scale, and so supporting
it in general will be next to impossible without having each arpeggiator
designed for a specific scale.
In fact, data about a scale needs to be known even for the really simple case
of generating a chord from a note.
Basically what I'm saying is that the note_pitch idea goes some way towards
making scales work, but not all the way, and I think it's going to keep
making things more and more complicated when they could be really simple if
we just said "if it can be done in linear pitch then fine, otherwise let the
sequencer handle it."
Now I think about it you wouldn't want to do
arpegiation using note
numbers, what you're interested in the the pitch coefficient to get
the correct harmonic relation.
In some cases, yes - but remember that the arpeggiator is not the
*only* plugin in the system. If you play other synths as well, you'll
probably want the arpeggiator to respect the scales used for those,
rather than trying to find "perfect" harmonies all on it's own. With
notes + scales, you make this trivial, even with non-ET scales, since
all you have to do is use the same scale everywhere.
5:38 p.m.
On Thursday 12 December 2002 21.25, Nathaniel Virgo wrote:
[...]
Sure; if traditional theory does not apply due to the scale being too
different, you either need to tell the plugin more about the scale,
or do it all inside the plugin, outputting linear_pitch.
In some cases,
yes - but remember that the arpeggiator is not the
*only* plugin in the system. If you play other synths as well,
you'll probably want the arpeggiator to respect the scales used
for those, rather than trying to find "perfect" harmonies all on
it's own. With notes + scales, you make this trivial, even with
non-ET scales, since all you have to do is use the same scale
everywhere.
Unfortunately I can think of a case where it's far from trivial: an
advanced twelve-tone arpeggiator that wants to play a major or
minor chord depending on what note is being played, so that it can
stay in the right key. This requires the plugin to know not just
the ordering of the notes on the scale, but also some arbitrarily
complex data about their harmonic and cultural relationships to
each other. Presumably this has an analog in some other types of
scale, and so
supporting it in general will be next to impossible without having
each arpeggiator designed for a specific scale.
Indeed. If the scale is too far from 12tET, traditional theory will
not apply - and deriving your own "theory" from the actual
frequencies is still bound to fail, since the definition of "harmony"
differs between cultures.
In fact, data about a scale needs to be known even for
the really
simple case of generating a chord from a note.
Yes, if it's too far from 12tET.
Basically what I'm saying is that the note_pitch
idea goes some way
towards making scales work, but not all the way,
The issues you have described are based on the assumption that there
is such a thing as "global music theory". Well, there is *not*, as
far as I'm concerned.
Different cultures have different scales, and different theory to go
with them. You don't use a 12t oriented harmonizer with 16t scales;
it just won't work, and you should not expect it to. Even if the
harmonizer *did* understand 16t (or whatever), it would not be able
to do the Right Thing, because the Right Thing differs between
cultures!
In short; note_pitch *does* make it easier to implement scale based
theory, and allows some tweaking of the scale without the theory
breaking down, but it does *not* automatically make any theory
applicable to any scale.
There is no way around this - and it's also not an API issue, but
rather a matter of users understanding that certain plugins will only
work properly with scales similar to the ones the plugins were
designed for.
and I think it's
going to keep making things more and more complicated when they
could be really simple if we just said "if it can be done in linear
pitch then fine, otherwise let the sequencer handle it."
No. It's as simple as "Don't mix scale oriented plugins with scales
they don't understand." No API support required, whatsoever.
//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 ---
13 Dec
13 Dec
9:54 a.m.
On Thursday 12 December 2002 9:33 pm, David Olofson wrote:
I suppose. I'm still worried about user interface complexity though:
[from a different mail]
On Thursday 12 December 2002 21.25, Nathaniel Virgo
wrote:
No, no, I was trying to point out that there isn't. I do agree with what
you're saying here, which is why I joined in on this thread in the first
place.
Basically what I'm saying is that the
note_pitch idea goes some way
towards making scales work, but not all the way,
The issues you have described are based on the assumption that there
is such a thing as "global music theory". Well, there is *not*, as
far as I'm concerned. and I think
it's
going to keep making things more and more complicated when they
could be really simple if we just said "if it can be done in linear
pitch then fine, otherwise let the sequencer handle it."
No. It's as simple as "Don't mix scale oriented plugins with scales
they don't understand." No API support required, whatsoever. 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.
I don't really understand how this hiding is going to take place. Especially
if there's going to be non-standard scale converters about that that need to
take MIDI pitch bend as well as note_pitch, I can forsee users being
perplexed by confusing networks of plugins when all they really want to do is
apply some portamento or vibrato. This situation would be doubly bad if
implicit casting was allowed.
It's not the complexity of the API that I'm worried about, it's the
complexity of the graphs that will be needed to accomplish sometimes quite
trivial tasks.
Everything else you said is a good point, so basically I more-or-less agree
with you again now -- but I'd still like to see the outline of an algorithm
whereby, with or without the use of a complex system of hints, a host can
make all this reasonably transparent to the user.
12 Dec
12 Dec
5:58 p.m.
On Thu, Dec 12, 2002 at 08:16:07PM +0100, David Olofson wrote:
Why wouldn't it? It sure does if you *play* the arpeggio on a real
instrument...
Yes, but a lot of interesting scales can't be played on fretted instruments.
- Steve
Yes it does, since you need to deal *only* with the
note number.
The scale converter then generates the correct pitch for the
notes in the scale that you reference. That's the whole point
with using note_pitch and scale converters at all.
I dont think that arpegiation from a non ET scale will fall exactly
on a note anyway - though I'd have to think about that.
7:29 p.m.
On Thursday 12 December 2002 22.53, Steve Harris wrote:
On Thu, Dec 12, 2002 at 08:16:07PM +0100, David
Olofson wrote:
Why wouldn't it? It sure does if you *play* the arpeggio on a
real instrument...
Yes, but a lot of interesting scales can't be played on fretted
instruments.
Then, how could a scale based arpeggiator deal with it, or why should
it even be expected to? Scales and note_pitch sounds like the wrong
tool for that job.
//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 ---
Yes it does, since you need to deal *only* with the
note
number. The scale converter then generates the correct pitch
for the notes in the scale that you reference. That's the
whole point with using note_pitch and scale converters at
all.
I dont think that arpegiation from a non ET scale will fall
exactly on a note anyway - though I'd have to think about that.
11 Dec
11 Dec
4:55 p.m.
On Wed, Dec 11, 2002 at 06:49:17 +0000, Nathaniel Virgo wrote:
Agreed.
- Steve
Sorry, I just tend to hit "reply to all"
because some lists seem to be set up
so that "reply" doesn't go to the list.
See if your mail client has a reply-to-list deature, mutt does
(<shift>+L).
I like the
idea of enforced "explicit casting", but I think it's
rather restrictive not to allow synths to take note_pitch. That would
make it impossible to have synths with integrated event processors
(including scale converters; although *that* might actually be a good
idea)
That would be bad. If a synth takes note_pitch it's bound to interpret it as
12tET, which would be annoying to someone trying to use a different scale. A
synth could still have a built in event processor, but it should only process
linear_pitch events. Scale converters should definately not be built into
synths.
5:26 p.m.
On Wednesday 11 December 2002 21.50, Steve Harris wrote:
Agreed.
Well, I suggested scale converters in the first place, so I shouldn't
be complaining. ;-)
//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 ---
On Wed, Dec 11, 2002 at 06:49:17 +0000, Nathaniel
Virgo wrote:
Only found "Post to mailing list"... :-/
Sorry, I just tend to hit "reply to
all" because some lists seem
to be set up so that "reply" doesn't go to the list.
See if your mail client has a reply-to-list deature, mutt does
(<shift>+L). I like the idea of enforced "explicit
casting", but I think
it's rather restrictive not to allow synths to take note_pitch.
That would make it impossible to have synths with integrated
event processors (including scale converters; although *that*
might actually be a good idea)
That would be bad. If a synth takes note_pitch it's bound to
interpret it as 12tET, which would be annoying to someone trying
to use a different scale. A synth could still have a built in
event processor, but it should only process linear_pitch events.
Scale converters should definately not be built into synths.
7973
days inactive
7975
days old
linux-audio-dev@lists.linuxaudio.org
19 comments
3 participants
participants (3)
-
David Olofson -
Nathaniel Virgo -
Steve Harris