Re: [linux-audio-dev] PTAF link and comments

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] PTAF link and comments
From: David Olofson (david@olofson.net)
Date: Wed Feb 05 2003 - 21:21:06 EET


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Feb 05 2003 - 21:20:54 EET