11 Dec
2002
11 Dec
'02
1:06 p.m.
On Wednesday 11 December 2002 17.17, Steve Harris wrote:
On Wed, Dec 11, 2002 at 04:25:56 +0100, David Olofson
wrote:
Well I was only talking about 12tET, if youre working in 16tET then
its 1/16. If your working in a non ET scale then its non trivial,
but we know that.
It's always <whatever>/note, and it's always trivial. The non-trivial
stuff goes on in the scale converter plugin.
MIDI pitch is always MIDI pitch, which is 1/note. This is the same
thing, only you can say
note pitch 0.5
instead of
pitch bend range +/-2; pitch bend 2048; note pitch 60
and do that independently for each note without going Universal SysEx
or one note/channel.
You don't change the value of "1" in the MIDI protocol when using a
MIDI scale converter. You don't change the value of 1.0 when using a
scale converter plugin.
(1/12)/note makes more sense because theres /is/ someting very
12ey about 12tET notes (the clues in the name ;), whereas there
is nothing 12ey about octaves. At all.
There is nothing 12ey *at all* about notes if you're into 16t...
So, 1.0/note makes sense, (1/12)/note does *not*. :-) Your piano argument is not really a problem as its the
piano
mechaism that generates the off-notes, that would be done at the
midi->pitch stage, sureley?
That *is* the scale converter, if you're dealing with a "primitive"
sampler that cannot implement this properly. But indeed, you may do
it directly in the sampler as well. (And IMHO, that's the way you
*should* do it, since, as I suggested, the need for this tuning is
directly related to the sound of the instrument.)
By the time it reaches the oscilators
its allready been shifted.
Maye I'm thinking at a different scope to you, but I view things
like big complex sequencers as working outside this API, for ont
thing it will have the same GUI issues as LADSPA.
A sequencer is just something that records and plays back events. A
kind of event processor. You may integrate it with your host, or you
may use some sequencer plugin that comes with the SDK, or whatever.
The API shouldn't rule any of this out, or it will rule out a number
of interesting plugins, such as phrase sequencers and virtual analog
sequencers.
The GUI is another issue - which indeed, is something we have to
consider for all plugins, if we're going anywhere with this API. The
way I see it, the Control interface should be a sufficient plugin/GUI
interface, so that all we need is a standard way of connecting
controls to the external, non-RT applications that GUIs will normally
be. Whatever comes in should go throgh the host's "preset database",
so that the host knows the current value of every control at all
times.
I'm thinking in terms of GUI == non-RT plugin, or rather client to
the event system. That is, inside a XAP host, you would see GUI as an
ordinary plugin in the net. Although it's not really physically in
there; what you see is a gateway plugin that interfaces with the
non-RT GUI plugin outside.
//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 ---