Oh, another advantage of audio rate controls is that they allow unambiguous control mixing. Though most hosts wouldnt implement that as it would be confusing which control ins can be mixed and which not. On Fri, Jan 16, 2004 at 10:56:21 +0100, David Olofson wrote: > > Not neccesarily. That only matters if the host allows > > plugin->plugin control chains. Not all will. Event to CV conversion > > is easy, CV to event is much harder and adds latency. > > Why would CV->event add latency...? For practicaliy reasons you need to chop it into ramp segments that are >1 sample long, so you need to be able to see into the future in order to get the slope/target right. > > Makes native UI control over IPC (which a lot of people think is > > desirable) tricky. It would need some kind of (optional) > > intermediate (and probably event like) representation to make it > > practical. > > That's a good point. Didn't even think about that. With ramped events, > you can pretty much transfer events as is, since it's obvious what's > intended if you look at the data. However, if you have to deal with > audio rate control data, you'll have to decimate one way or another. > Probably means users will have to tweak "quality" controls or > something, to balance accuracy and bandwidth... Thinking about it some more, the best theing to do is require event->CV conversion (thier easy just run the ramp code) and allow UIs to send events to control rate inputs. > > Other systems that have PCM control signals define a k-rate that > > can be less than the audio rate. I dont know if its neccesary, but > > its something to think about. > > Seems to me that a variable k-rate - that is, one that isn't fixed at > compile time - would eliminate most of the optimizations a lower > k-rate would allow. Requiring that the k-rate is always the audio > rate divided by a power of two would help a great deal, though. Good point. - Steve ---------------------------------------------------------------------- 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