24 Mar
2003
24 Mar
'03
7:22 p.m.
Interesting stuff worth talking about.
Is this a clean, natural division? I don't think
so. Why does the
model treat the output of an envelope generator as being (in many
respects) more like a string than it is like an oscillator output?
Why isn't it clear what an LFO's output type should be? Why does
something as simple as a ramp spawn so much complexity?
Some good questions. In fact, maybe an LFO _should_ be audio data. Or at
least Audio-rate. But one can argue that an LFO is LF enough that you can
represent it reasonably well with a series of short linear ramps, and have
less overhead.
Maybe XAP should consider some method of identifying Audio-rate control
ports. If your control expects audio-rate input, you should be able to ask
for it? Why not use actual audio ports for that, then, and just hint that
they are control signals? An envelope generator or an LFO should be audio
outputs that go into audio inputs. Maybe.
Even where the audio/event distinction looks clear
cut, its not. The
user toggles a switch. Thats an event, surely? Wellll... maybe it is,
but then, what does the plugin do with the event? If the switch is
switch *is* an event. But the rise and fall
characteristics should
belong to the owner of the source, not to the destination. An app
Disagree, here. The flip of a switch is a binary event. The receiver needs
to handle it. Non-binary things like knob turns will already either be
interpolated by the sequencer, by a custom UI, or by the plugin. Or all
three.