> > controls, two filter controls etc and making them slightly > > different and behave differently in each plug. Are we better to > > define the behavior, or at least offer a suggestion? > > 2D "address space": > Dimension 1: Channel > Dimension 2: Control
Do we really want to have different controls for different channels? I can see how it might be neat, but since multiple channels is convenient for hardware people, shouldn't we leave the controls the same, too? :) Simpler perhaps: nchannels master_controls[] channel_controls[] voice_controls[] or, if we agree flags for this are best: controls[] (each is flagged MASTER/CHANNEL/VOICE) > What if you need *only* pressure, and don't care about attack or > release velocity? Why not just make velocity optional as well? :-) Even though I have conceded this point - JUST IGNORE IT? Whatever, it's old news :) > However, it might be handy for the host to be able to ask for the > values of specific controllers. It may or may not be useful to do > that multiple times per buffer - but if it is, you'll definitely want > the timestamps of the "reply events" to match those of your request > events, or things will get hairy... Uggh, can we keep the get() of control values simpler than events? My previos proposal had a control->get() method and a ctrl->set() method. Obviously, the set() is superceded by events. Is the get, too? > > SILENT (plugin to host - sent when reverb tails or whatnot have > > died..) > > Great idea. Sample accurate end-of-tail notification. :-) (In > Audiality, I do that by fiddling with the plugin state, which is > rather ugly and not sample accurate.) I noodled on your state-model and realized that a state-change is just an event. :)
