[linux-audio-dev] PTAF link and comments

[David Olofson]

On Wednesday 05 February 2003 19.27, Tim Hockin wrote:
[...]
> A generic output is a plugin which wants to emit control data, but
> it doesn't know what it is connected to - might be pitchbend, might
> be oscillator shape, might be pan.  Generic outputs should emit
> normalized data 0.0-1.0.  To connect it to anything useful, you
> need to scale it by the targets true range.

Ok.


> It seems more obvious to me, though, that controls DO need to do
> bounds checking for their inputs, or the host needs to do
> snoop-and-fixup for every control.

Yeah, that's basically where I'm getting. I don't really like it, 
considering what it does to plugin code, but it's not *that* bad, and 
it makes life a lot easier. The cost of having hosts do it would be 
*much* higher, and you'd basically have to do it all the time, I 
think.


> > > So the way I see saving the state of a plugin:
> > >
> > > For each control
> > > 	save snooped control data to output (maybe XML)
> > > endfor
> > > if (plug->get_extra_state)
> > > 	d = plug->get_extra_state()
> > > 	save d as if it were a raw control
> > > endif
> >
> > Well, that eliminates the need for the in/out pair, which *is* a
> > special case after all.
>
> right, we only need to 'read' data we didn't write.

Actually, do we? Where would that data come from?

IIRC, we concluded that default values should be part of the metadata, 
rather than built into the plugin code. Motivation:

	* Having plugins load defaults at some point would
	  violate the semantics of inputs. Inputs should not
	  change their values spontaneously, but *only* as a
	  result of incoming CONTROL events.

	* Default values must be available to hosts, for
	  various reasons, so there must be a way to read
	  them no matter what. If plugins are supposed to
	  initialize their own inputs, that would mean that
	  1) they'd all be doing simple stuff that hosts
	  could handle easilly, and 2) there'd be code that
	  may have bugs that can take long to be noticed.


So, the host *would* have access to that data, no matter what. If it's 
really input data we're talking about, the plugin is not allowed to 
modify it, so the default, or whatever we write to the input applies 
- just as with any control input.

If it's output data, it's generated by the plugin, and all we can do 
is read it. Unless it's "custom" data that some other plugin 
understands, in's essentially useless, as we can't write it back. 

There *could* be an in/out pair though, so you could feed that data 
back into the plugin. That's a separate issue, and I'm not sure what 
purpose it would serve, or if it even makes sense at all.


Now, if this doesn't apply at all to the problems that you want to 
address with save_extra_state(), please expand. I *suspect* we're 
talking about two (or more) different features here.


> > However, how do you actually transfer the raw data through that
> > call? It's just not about a function call, but also about the
> > data transferred. We'll need an RT safe solution for the
> > controls. What to do here? Just assume that it's not RT safe?
> > (Which means you can't save states without taking plugins out of
> > the net, or requiring that they're thread safe WRT this call...)
>
> I'd assume this is NOT RT safe.  Don't save a preset while your
> track is running :)

I don't like that. It seems nasty to prevent people from saving their 
work without shutting down the whole engine for a moment. I'm 
strongly opposed to the idea of confusing audio time with musical 
time, and this is a typical example of assuming they're almost the 
same. Stopping the sequencer does *not* mean the audio engine stops. 
It *might* in some apps, but that's incompatible with what most users 
of "real" synths expect, and should not be enforced.


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