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: [linux-audio-dev] XAP: Pitch control
From: David Olofson (david_AT_olofson.net)
Date: Mon Dec 09 2002 - 22:04:17 EET


On Monday 09 December 2002 18.35, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 05:20:26PM +0100, David Olofson wrote:
> > > Just to make it clear, I would have the host provide a
> > > pitch->note number and note number->pitch mapping functions
> > > (for the "current scale").
> >
> > 1. There is no "current scale". You may have different
> > scales for different instruments. (As a matter of
> > fact, you *do* most of the time IRL - except when
> > working exclusively with synths.)
>
> Sure, there is potentially a current scale for each note processor.

There is potentially a "current" scale for each *Channel* of an event
generator/processor. (I'm not even sure it's that simple...)

> > 2. I don't like one or more function for every other
> > event! There's a reason why I designed a totally
> > inlined event system. :-)
>
> I dont understand this. You still need host callbacks to implement
> the note->pitch or pitch->note conversion in your conversion
> plugins. The only difference is that you have the extra overhead of
> a (hidden) plugin.

Well, this is Audiality's code for linear pitch -> "whatever"
conversion with linear interpolation:

/*
 * Interpolated linear frequency -> frequency factor lookup.
 *
 * 'pith' is a 16:16 fixed point linear frequency value.
 *
 * Returns engine pitch as 16:16 fixed point.
 */
static inline int ptab_convert(int pitch)
{
        int bfrac;
        int btone = pitch >> 16;
        if(btone < 0)
                return __pitchtab[0];
        else if(btone > 127)
                return __pitchtab[128];
        bfrac = (pitch & 0xffff) >> 8;
        return (__pitchtab[btone+1] * bfrac +
                        __pitchtab[btone] * (256-bfrac)) >> 8;
}

(Fixed point. XAP would deal with floats, of course.)

You may have that as an inline or a host call, and in the latter
case, you might throw the scale management in as well - but either
way, there are a few remaining problems that can't be solved with a
single pair of conversion calls/macros:

        * Getting what you actually *need* for the synth. Is
          this something that can be narrowed down to one or
          two formats (frequency and period?), or is it perhaps
          better left to plugins to perform the linear->"value"
          conversion? Is there a point in using a host callback
          to make sure you have linear pitch, if you *still*
          need to convert again, into something else?

        * How do you manage scales, if they're not handled by
          "normal" plugins? Should all hosts have built-in UIs
          for this? How sophisticated must this be to actually
          be usable?

        * If you have a host callback for converting note pitch
          into linear pitch (or something else), how would the
          plugin know what scale to ask for? Given that the
          majority of people actually use only 12hET, how many
          plugins would actually get this right? In fact, how
          many plugin coders would even bother to implement this,
          if you *usually* get away with just assuming that the
          input is 1.0/octave or 12.0/octave or whatever, and
          that all pitches are based on 12tET?

> > Anyway, still the same thing: *plugins* should be used for
> > conversions between the two; not host callbacks.
>
> I strongly disagree. Conversion plugins are a nasty hack.
> Especially implicit ones.

They don't have to be implicit. If you assume that 12tET is the
standard scale, you'll *only* need scale converters when you want
something else.

Again, that's why 12.0/octave makes sense. It doesn't make a
difference technically, but it makes *this* stuff a whole lot easier,
since it just "happens" to result in note_pitch and linear_pitch
being identical as long as you stick with 12tET.

If you want some synth to play something else, just throw in a scale
converter and pick or tune your scale. That's what you do with
hardware synths, unless they come with a built-in "foreign scale"
features, or when those are insufficient.

Why make this a special case, when it's actually just another event
processor - on that most people will never need to use?

> > Oh, and here's a good reason to actually use 12.0/octave for
> > linear pitch: You won't need any scale conversions at all, as
> > long as you use 12tET. :-) (That's why I decided to use that in
> > Audiality in the first place.)
>
> But if you use 12.0 per octave then pitch modifying LFOs and mixers
> wont work right (for a start), unless they know about the scale
> issues...

Unless your LFO or whatever *understands* scales (ie has it's own
built-in scale converter, or can actually "think" in non-linear
scales), it would *always* see and generate 12.0/octave.

If you don't like 12.0, scale and use whatever you like internally.
It doesn't change anything.

> What happens when your not using 12 tone? Do you use eg.
> 5.0 per octave?

Nothing. You still se, and are expected to send, 12.0/octave.

> To me 1.0 per octave seems far more natural.

It's just a figure. Scale as you like.

The reason to use 12.0/octave is, as I said, just that it makes note
and linear pitch identical on the physical level, which means you
don't need any conversion at all, as long as you're using 12tET.

> Its what CV
> synthesisers settled on after a good few years of battling, it just
> makes everything simpler.

1.0 Volt is a nice and handy figure. Easy to remember, and it goes
well with SI units when you design analog cirquits. There's nothing
magical about the figure as such.

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


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

This archive was generated by hypermail 2b28 : Mon Dec 09 2002 - 22:12:57 EET