On Mon, Jan 03, 2005 at 03:36:50AM -0800, Crudesoft wrote: > > Show me where we have exceptions? We've tried very > > hard to make GMPI > > consistent, so far. There is even an argument to > > *only* have ramp events, > > and get rid of point events (a point is a ramp with > > duration 0). > > Ramp events are the exception. How do you implement > ramp events for more or less randomly changing knobs? I think you're trumping up "randomly moving knobs". Look. There are 3 main types of knob movements I can see: 1. Human initiiated. These come in from a GUI or from MIDI or something like that. They may be random at a macroscopic level, say over the course of a second. But over the course of 25 ms, they are NOT random. They are mostly linear. Why? Because humans are slow. Keep in mind also that MIDI is not capable of sampling a control signal at 44k. 2. Automated. These *could* be random on the microscopic level, but I'd be really really surprised if any majority of users did this. I could be wrong, but I don;t think so. 3. Plugin controlled. Think LFO. Here's a case where random could happen. But I think again that a signal that is random at a sub-buffer level is going to be very marginally useful. > For me it is simply not a natural approach. Events may I agree that ramps are not a natural way to think of things - this is my biggest problm with it it and my biggest attraction to audio-rate controls. But it's not an arument by itself. > Events may look good on paper but I think they will be > a pain to implement. IMHO control signals are like Just for the record - events are how most every DAW software works *today*. > Although control signals are often rather low > frequency signals this is not necessarily always true > and their bandwidth should not be limited by > specification. Audio rate events? I don't think so. They have to be audio rate in order to be sample accurate. Unless you have another solution. But you have been presented with this and not solved it. > modules as a result. Efficiency issues of today should > not be part of a standard that wants to be a standard > of tomorrow. Ahh, so you mean that tomorrow we'll all have enough disk and memory bandwidth to not worry about it? Don't think so. > Let me put it this way: > Knobs are signals, period. Treat them that way. Let me put it this way: You have not made a strong enough case. Further, we're finishing *requirements* now. If you feel very strongly about this, I really invite you to get on the implementation team, make a solid case, show a proof-of-concept implementation, and convince us/them. I've already said I'm willing to listen. I've even argued your position, somewhat. Cheers Tim ---------------------------------------------------------------------- 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