Subject: Re: [linux-audio-dev] Plugin APIs (again)
From: Tim Hockin (thockin_AT_hockin.org)
Date: Sun Dec 08 2002 - 07:52:28 EET
> > 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. :)
This archive was generated by hypermail 2b28 : Sun Dec 08 2002 - 07:57:00 EET