On Tue, Jan 04, 2005 at 09:23:10AM -0800, Crudesoft wrote: > Knob-like controls belong to the same group as signal > generators. Button-like controls are events. I am > talking about knob-like controls. This is not an argument for your case, this is begging the question. In concept, knobs are like signal generators. It's not necessarily the *right* way to handle it. > 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, Unless you modify the event stream with start/stop gates, then sampled control streams are vastly less efficient for anything < samplerate/4 (or thereabouts) event rates. And you're ignoring ramps altogether. A single ramp event can describe sample-accurate control events for any number of samples. Far more efficient. > 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. You keep saying this, and we keep reminding you that all events must be sample-accurate. The control rate needs to be >= sample rate, or you need to be able to re-align control rate to sample rate on any arbitrary sample. > 2. Events are different from samples and thus have to > be treated and coded differently, which is more work. Control events are *always* going to be different from audio samples. We decided a long time ago that we are not building an all-normalized all-numeric modular system when any output can plug to any input. It's more useful to have natural values and natural data types. Control != audio. > 3. Events are rendered at the destination, thus there > may be several consumers duplicating work. Samples are > rendered at the source and only once. yes, and this is *correct*. Events are rendered with exactly the level of accuracty that a receiver can handle. > 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. This is not any different than sampled control streams. Look. Grab a MIDI knob. Turn it as fast as you can, and record the MIDI events. Then plot that against 44.1kHz sample points. You are massively steppy. Now tell me that it makes sense to send all those redundant samples? Let me explain more. Let's assume you can spin a MIDI knob completely from 0 to 127 in .25 seconds. Let's assume 44.1kHz sample rate. First off, MIDI is event driven. So you get 128 events in 11025 samples. That means that you have a step function where each step is ~86 samples wide. Why do I need to send 86 samples of the same value, when I can just send 1 event? Realtime inputs are inherently unpredictable, and the best you can do is to provide the changes with as little latency as possible. Whether you send a buffer full of control samples or you send a link-list of events, you have exactly the same problems. There is no forward knowledge. Well, actually, there is a bit - 1 buffer's worth. So you can peek ahead by however big your buffer is (and consequently, how bad the latency is). > 5. Events cannot represent arbitrary signals unless > their frequency is high, which is undesirable because > they are large (relatively speaking that is). Event streams can be arbitrarily high frequency. As we've shown, ramps give you SUB-SAMPLE accuracy for pre-calculated events. Yes, you pay more for a very high rate event stream. But with sample rates currently at 48 kHz or 96 kHz, I'm not worried about it. I don't think that realtime event streams will be coming in at 48000 events per second, and especially not for any extended period of time. And realtime events are what matter, because who really cares if there is a bit more overhead during a non-realtime operation. So my point again: 1) You can have sample-rate events. 2) You won't see sample-rate events in realtime. 3) You might see sample-rate events in non-realtime, and nothing breaks. > 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. I'm a systems guy by design. I *always* think about DMA and IRQs. Now I'm looking to you to explain how DMA and IRQs figure into this discussion at all. If you read the reqs, you'll see that event delivery happens BEFORE a buffer is processed, and is not async. > Basically you could see samples as events without the > overhead of timestamps and clues. Or the other way ..and with the overhead of having to be at sample-rate. Once more. How many knobs in a running graph? I have synths with literally HUNDREDS of knobs. At any given time, maybe a dozen knobs are being automated, and the automation is on the order of tens of changes per second. Not tens of thousands. ---------------------------------------------------------------------- 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