[linux-audio-dev] Plugin APIs (again)

[Tim Hockin]

> > 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. :)