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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: Fwd: Re: [linux-audio-dev] XAP: Pitch control
From: Nathaniel Virgo (nathaniel.virgo_AT_ntlworld.com)
Date: Thu Dec 12 2002 - 17:10:07 EET


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

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

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.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Dec 12 2002 - 17:09:05 EET