[linux-audio-dev] XAP again - channels, etc.

Tim Hockin thockin at hockin.org
Mon Mar 24 18:23:00 UTC 2003


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.





More information about the Linux-audio-dev mailing list