11 Dec
2002
11 Dec
'02
1:24 p.m.
(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 <david(a)olofson.net>
To: Nathaniel Virgo <nathaniel.virgo(a)ntlworld.com>
On Wednesday 11 December 2002 18.09, Nathaniel Virgo wrote:
On Wednesday 11 December 2002 4:29 pm, David Olofson
wrote:
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.
On Wednesday 11 December 2002 13.59, David Gerard
Matthews wrote:
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. Steve Harris wrote:
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. 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. 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 ---