Subject: Re: [linux-audio-dev] PTAF link and comments
From: David Olofson (david@olofson.net)
Date: Sun Feb 09 2003 - 12:05:08 EET
On Sunday 09 February 2003 00.52, Tim Hockin wrote:
> > > I'm starting to agree. I really dislike the idea that the host
> > > has to read a plugin's output control to get extra stuff for a
> > > preset.
> >
> > This is not an exception. It has to do something like that all
> > the time, since inputs are not readable. Has everyone forgotten
> > that?
>
> We don't have to do this for most controls because the host knows
> what was last written to each input.
Yes, if the *host* is what writes the value, using an automatically
created UI or something. If you use a custom GUI, it's just like with
plugin->plugin connections; the host has to check the connected
output for the current value on an input.
> And we only save inputs in a
> preset, right?
Yes, but we have to track their values, or we have nothing to save.
Obviously, a host can just skip inputs that are connected to other
DSP plugins, and make an exception only for GUI "plugins". (Rather
easy, since an RT/non-RT gateway is needed for such connections
anyway.)
> However, these assumptions make a problem:
>
> 1) Writing a preset or saving the plugin state involves writing the
> value of all the plugin's (input) controls.
> 2) Controls can be directly connected, needing no host intervention
Correct.
> 3) Controls are not readable
*Input* controls are not readable. You're forgetting that any input
control that isn't set to a fixed value by the host will be connected
to some form of control output - which *can* be read in a rather
direct way, as a result of the connect semantics.
> 2 and 3 lead us to conclude that if the host does not snoop every
> event, it does not know the value of some controls. So how can it
> write them out?
It doesn't have to snoop events at all times just to find out the
value when it wants to. Just do it for 0 frames whenever you want,
and then restore the direct connections.
The alternative is to have a special "get current state of all inputs"
> Either the host has to snoop every event in order to cache every
> single control change, or controls need to be directly readable
> somehow.
>
> Is it so bad to have a control->get_value() method ?
Maybe not, but it has to be implemented, of course. The problems I'm
seeing is that connections are made through cookies (no direct
address->control code/data relation), and events don't *have* to keep
track of the actual values unless they're actually used directly.
That is, plugins may have to do extra work just to have the current
input values available at all times, and they will always have to
implement a method of directly grabbing that data for a specific
control, without going through the normal cookie->handler code path.
Outputs OTOH, already have a similar requirement - "must send current
value directly after connection" - as this is needed for connection
to work properly.
A control->get_value() method might make life slightly easier for
hosts, but it's not strictly required, and it would impact every
plugin.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
This archive was generated by hypermail 2b28 : Sun Feb 09 2003 - 12:03:55 EET