11 Dec
2002
11 Dec
'02
2:50 p.m.
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 ---