(Same thing again...) ---------- Forwarded Message ----------
Subject: Re: [linux-audio-dev] XAP: Pitch control Date: Wed, 11 Dec 2002 18:15:59 +0100 From: David Olofson <[EMAIL PROTECTED]> To: Nathaniel Virgo <[EMAIL PROTECTED]> On Wednesday 11 December 2002 18.09, Nathaniel Virgo wrote: > On Wednesday 11 December 2002 4:29 pm, David Olofson wrote: > > On Wednesday 11 December 2002 13.59, David Gerard Matthews wrote: > > > Steve Harris wrote: > > > >On Wed, Dec 11, 2002 at 12:40:18 +0000, Nathaniel Virgo wrote: > > > >>I can't really say I can think of a better way though. > > > >> Personally I'd leave scales out of the API and let the host > > > >> deal with it, sticking to 1.0/octave throughout, but I can > > > >> see the advantages of this as well. > > > > > > > >We could put it to a vote ;) > > > > > > > >- Steve > > > > > > I vote 1.0/octave. > > > > So do I, definitely. > > > > There has never been an argument about <something>/octave, and > > there no longer is an argument about 1.0/octave. > > > > The "argument" is about whether or not we should have a scale > > related pitch control type *as well*. It's really more of a hint > > than an actual data type, as you could just assume "1tET" and use > > both as 1.0/octave. > > I don't think that should be permitted. I think that this case > should be handled by a trivial scale converter that does nothing. > No synth should be allowed to take a note_pitch input, and nothing > except a scale converter should be allowed to assume any particular > meaning for a note_pitch input. 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) 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. > 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 ---
