[linux-audio-dev] XAP: Pitch control

Steve Harris S.W.Harris at ecs.soton.ac.uk
Mon Dec 9 19:37:01 UTC 2002


On Tue, Dec 10, 2002 at 12:40:10 +0100, David Olofson wrote:
> If "actual pitch"; hint your pitch inputs as "linear_pitch". Now, you 
> get 12.0/octave, period. It could have been 1.0, but then someone 
> would need to convert back and forth, even in pure 12tET nets. Now, 
> you can effectively have your synth just "think" in 12tET, and still 
> be capable of playing in any scale. Scale conversion just expresses 
> the pitch of tones of the real scale as 12.0/octave - just as it 
> would have done with 1.0/octave; just a factor 12.0.

There isn't any conversion. A note is 1/12th of an octave.

> It doesn't matter if they seem illogical, since your synth (the kind 
> of plugins that would normally want linear_pitch) can effectively 
> think in 12tET regardless of which scale it's being used with.

Yes, but its totally artificial, and irrelevent!
 
> > It also ecourages the
> > 12tone way of thinking, which I dont particularly like (can you
> > tell ;).
> 
> Well, I must agree - but does representing note_pitch a 1.0/octave 
> make more sense? :-)

Of course. It meants there are no spurious factors of twelve you have to
remove to do any actual work on the pitch value.
 
> You could do that as well, but it means most control processors, 
> sequencers and stuff will have to multiply with 12.0 to get the 
> actual note pitch (1.0/tone) - which is pretty illogical as well, 
> considering that your output may well be interpretted as 16.0/octave!

Right and if there are 16 notes in your octave then you can multiply
by 16... I dont see the problem.

If we allow note numbering and pitch factors and you ask for pitch then
the chances are that youre interested in octaves, not notes anyway.
 
> So do I, but is it worth wasting cycles and add complexity, just to 
> prevent synth programmers from even thinking about 12tET?

If youre implementing a synth then 12tET shouldn't ever come into it,
you're told that 0.0=(some frequency) and 1.0 is double that, -1.0 is half
that. What could be simpler?

You dont implement oscilators in terms of notes.  It'd be far more
confusing to be told that 12.0 was double and -12 was half.

> Sequencers, most event processors (basic appregiators and the like) 
> etc will send note_pitch. Those plugins think in terms of notes, and 
> don't care much about what exact pitch each note represents on 
> whatever eventually makes the sound. (This is *exactly* the situation 
> you're in when working with MIDI.)

OK, I'm coming round to the idea that you want note events... it makes
sense that that would be 1.0 per note. I'm still adamant that 1.0 per
octave makes more sense for pitch though.

> With 1.0/note for note_pitch, and 12.0/octave for linear_pitch, we 
> have a nice and extremely simple "shortcut" available for all those 
> that use only or mostly 12tET:

and a headache if you dont want to work in 12tET. Its not like the
conversion is hard, the host could od it explicity if it only wants 12tET,
and if its wants other htings then its going to have to work anyway.
 
> 	linear_pitch = note_pitch * (12.0 / 16.0);
> 
> That is, "stretch" the scale so you need 16.0 note_pitch units to 
> span one octave. Now, all of a sudden, your synths - apparently 
> written for 12tET - can play 16tET. They don't know it, or understand 
> it, but they're playing the right notes.

Sure, I just think the factor of 12 is ugly.
 
> If for example, you have a pitch tracker that generates events from a 
> vocal track, it doesn't matter what scale you use for mapping actual 
> frequency to pitch values. As long as you use the same scale for 
> playing those events on a synth, that synth will play *exactly* the 
> same pitches.

Yes, I gave an exmaple of this in an earlier message. Its one reason why
its important the synth programmers aren't tempted to accept note data to
generate oscilator frequencies.
 
> > > If you don't like 12.0, scale and use whatever you like
> > > internally. It doesn't change anything.
> >
> > But it does mess up the API.
> 
> And forcing plugins to request information about what's going on 
> outside their input ports, and passing that to non-optional host 
> callbacks does not?

Well, that is optional, having to remove the factor of 12 isn't.
 
> No, but event processor coders are going to think that multiplying 
> with 12.0 to get actual note_pitch is rather strange when there could 
> be any number of tones/octave... ;-)

But youre always multiplying by the number of tones (for ET), so its much
less confusing!
 
> I simply don't think that using 1.0/octave and 12.0/octave is worth 
> the cost of figuring out when to translate, figuring out *how* to 
> translate and actually doing it. The actual translation is trivial 
> for 12tET, but getting there is not.

But the actualy translation is trivial! If you have 1.0 per octave you dont
have to work out when you have to do it, jst just always do it and the
trnaslation is just note = pitch * number_of_notes. How could it be
simpler?
 
> > Thsi has been a long discussion, so, my position:
> >
> > 	I do like 1.0 per octave, linear pitch
> > 	I dont like "notes" being in the API.
> 
> I agree. But how much is that allowed to cost?

The notes issue, maybe, but 1.0 / oct doesnt cost anything: Its not
confusing (to anyone), it doesnt cost any cycles.
 
> 	1. 1.0/note for note_pitch, 1.0/octave for linear_pitch.
> 	   Converter plugins required everywhere, even for 12tET.
> 	   Even 12tET-only hosts have to handle this.

Do you think its a good idea to have some hosts/plugins believing that its
ok to just cast pitch as notes? that sounds like a recipe for disaster to
me.

I realy dont understand how you can object to converting from pitch to
notes by multiplying by the number of notes pre octave, its seems
perfectly natural to me.

I'm still slightly concerned that this would encorage people to use notes
where they meant pitch, but I dont care enough about the dual repesentation
issue to argue that much. I'm predicting that it will cause problems
though.

- Steve



More information about the Linux-audio-dev mailing list