12 Dec
2002
12 Dec
'02
7:45 a.m.
On Wednesday 11 December 2002 8:31 pm, David Olofson wrote:
At this particular moment I can't see any circumstance where an arpeggiator
wouldn't be better off and more useful as a seperate plugin from the synth,
which is why I think that note_pitch processors should generally be seperate.
Incidentally, I think you could make a sensible arpeggiator that worked in
linear_pitch - it could just create notes by multiplying the frequency by
integer ratios like 3/2 (which is approximated by a perfect 5th in 12tET).
It might not sound good on all scales but it would make sense.
Alternatively, if it's the kind of arpeggiator that makes sequences out of
chords then it could use either representation of pitch. In fact,
linear_pitch is probably better for this kind of arpeggiator because you can
create octaves, which you can't do in general in note_pitch. This sort of
thing is in extreme danger of making the whole thing far too confusing for
the users.
Well, you're probably right.
Ok, then I agree.
Point taken - you'd have to jump through hoops to actually enforce those
rules in the API.
There is one good argument for making pitch converters special, though: A
good sequencer client needs to be able to insert them implicitly. As a user
I wouldn't want to have to worry about all this until I want to use a
non-standard scale.
A synth could
still have a built in event
processor, but it should only process linear_pitch events.
Yes - but you could not implement a useful arpeggiator that way, for
example. It would do the wrong thing as soon as you're not using
12tET anymore - and *now*, users wouldn't have clue as to why this
happens, because the synth *lies* and says that it cares only about
linear_pitch... Scale
converters should definately not be built into synths.
I think I agree, but I bet *someone* will eventually figure out a
valid reason to do it... ;-) 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.
Yeah. We could "strongly suggest" things, but officially saying "you
cannot do this" about things that are physically possible is
dangerous. Host coders might actually take your word for it!
And then everyone goes "Hmm... That's actually useful, after all."
Bang! VST host incompatibilities reinvented... *heh*