> I'm not sure that I fully grasp your objections to events. As currently A resume of my previous arguments: First: Knob-like controls belong to the same group as signal generators. Button-like controls are events. I am talking about knob-like controls. Second, my main objections to events: 1. Events are larger than samples. An event is at least a timestamp and a value, but maybe also a type and a clue whereas a sample is just a value. At the same rate samples are always cheaper than events. BTW, I do not think that the sample rate has to be the same for all generators as long as the generators publish their sample rate. 2. Events are different from samples and thus have to be treated and coded differently, which is more work. You cannot use just any source as an event generator, you need special event generators. If you want to mix you are going to need convertors which complicate matters even more. 3. Events are rendered at the destination, thus there may be several consumers duplicating work. Samples are rendered at the source and only once. 4. Events cannot represent real-time signals because you have to wait and see what is happening before a decision to send an event can be made. 5. Events cannot represent arbitrary signals unless their frequency is high, which is undesirable because they are large (relatively speaking that is). 6. Handling events is more complicated than samples which makes code more complex and less robust. Callbacks or interrupts or however you handle events are not good for high rates. Think about DMA and IRQs. Basically you could see samples as events without the overhead of timestamps and clues. Or the other way round: events are compressed samples. In the first case you have to handle large sample buffers, in the second case you have to compress. There are many ways to gain something through compression, but you always pay a price somewhere else, the gain is at transport time, but you pay at zip and unzip time. You can only have an overall positive gain if you use lossy compression. Lossy compression imoses limits and limits tend to be reasons to change later the way we are doing something now. Indeed, if you only allow for smooth linear low-frequency control signals events may be the way to go, but the price to pay is flexibility. Crudesoft __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com ---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission. Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe