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

David Olofson david at olofson.net
Thu Dec 12 07:24:00 UTC 2002


On Thursday 12 December 2002 12.43, Nathaniel Virgo wrote:
> On Wednesday 11 December 2002 8:31 pm, David Olofson wrote:
> > > 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...
>
> 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...


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



More information about the Linux-audio-dev mailing list