Fwd: Re: [linux-audio-dev] XAP: Pitch control

David Olofson david at olofson.net
Thu Dec 12 15:53:00 UTC 2002


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 ---



More information about the Linux-audio-dev mailing list