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

Nathaniel Virgo nathaniel.virgo at ntlworld.com
Wed Dec 11 13:51:00 UTC 2002


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



More information about the Linux-audio-dev mailing list