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.
