[linux-audio-dev] XAP spec & PTAF comments [merge]

Steve Harris S.W.Harris at ecs.soton.ac.uk
Fri Feb 7 15:22:00 UTC 2003


On Fri, Feb 07, 2003 at 03:22:27 +0100, David Olofson wrote:
> On Friday 07 February 2003 11.07, Steve Harris wrote:
> > On Thu, Feb 06, 2003 at 08:38:10 +0100, David Olofson wrote:
> > > > It sounds like the wrong thing, the general case is that the
> > > > host generates values its knows to be in range, then the plugin
> > > > checks it again to check its in range...
> > >
> > > Not the host; the *sender*. That is the sequencer (which can be
> > > part of the host), or more interestingly, any plugin that has
> > > control outputs.
> >
> > OK, but it seems like a bad requirement to place on the plugin.
> 
> Yes, that's exactly my point - and the motivation for having plugins 
> clamp input controls with hard ranges.

No, no. I mean doing its own clamping is a bad requirement to place on
plugins. Much of the time it wasted effort, and its just loads of
duplicated code in each plugin.

Maybe the host could signal that a control might go out of range and the
SDK could do the checking? Thast ways its transdparent to the plugin.
 
> Yeah... So, where are we going here? The alternatives I'm seeing so 
> far:
> 
> 	1) All controls are [0, 1] hard ranges.
> 		* Easy, but plugin authors must decide on
> 		  the ranges once and for all.
> 
> 	2) All controls are [0, 1] soft ranges.
> 		* Plugins that actually have hard ranges
> 		  must clamp internally.
> 
> 	3) Controls are [0, 1] hard or soft ranges.
> 		* Someone (probably the host) must deal with
> 		  clamping for controls with hard ranges.

All of these are a big step back from LADSPA, so I'm ignoring them.
 
> 	4) Controls have plugin defined hard ranges.
> 		* Either all plugins clamp their inputs, or
> 		  hosts snoop all connections.
> 
> 	5) Controls have plugin defined soft ranges.
> 		* Plugins that actually have hard ranges
> 		  must clamp internally.

This is what we have in LADSPA. The hard ranges are not expressed to the
host, and they probably dont need to be.
 
> 	6) Controls have plugin defined hard or soft ranges.
> 		* Someone (probably the host) must deal with
> 		  clamping for controls with hard ranges.


> [...]
> > > Good point, though it doesn't make silence useless in Audiality,
> > > at least. If the reverb *does* go "silent" within any reasonably
> > > amount of time, the information is useful. Synths generally go
> > > silent as soon as the release phase of the last note is done
> > > (which is generally well defined), so it's *definitely* useful
> > > there.
> >
> > Useful for post-roll yes, but not really useful saving a few
> > cycles.
> 
> I think you're underestimating the complexity and dynamics of a full 
> song running as a single net. You may have lots of sounds in a song, 
> all with their own effect sub nets, but you generally never play all 
> sounds at once. This depends a lot on what kind of music you're into, 
> of course, but it's hardly an unusual special case.
...
> Just as an example, you don't run the chorus and the verses of a pop 
> song all in parallel, but they may (and usually do) have totally 
> different processing.

OK, but this is only worth anything if the tails of the verse dont
overlap with the start of the chorus at all, and that is a special case.

In any case these kind of optimisations blow the ~constant cycles / sample
assumtion out of the water, which will make using it reliably very hard,
except in the situation where the total CPU taken by the plugin processing
is minimal compared to the rest of the (non RT) system. I dont think thats
likly to happen in XAP, though it may in audality.

- Steve



More information about the Linux-audio-dev mailing list