[linux-audio-dev] PTAF link and comments

[David Olofson]

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 ---