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

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

Subject: Re: [linux-audio-dev] XAP spec & PTAF comments [merge]
From: David Olofson (david@olofson.net)
Date: Fri Feb 07 2003 - 16:22:27 EET


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.

> If
> we allow it, it really should be to be the host that enforces it.

Well, as long as we assume that hard ranges are really rather unusual,
this isn't much of a problem. If it happens too frequently, though,
I'm afraid that the cost of one extra Queue and the code to handle it
will become significant. (You can't do it with less than one Queue
per control, since events don't contain full target addresses. The
Queue part is lost as soon as you send the event, and the cookie part
is expensive to deal with for anyone but the final receiver.)

> > > If we allow hard ranges (not really neccesary, as LADSPA shows)
> > > then the host should enforce them.
> >
> > Which would mean the host has to break in whenever you connect
> > two controls, *only* to do this.
>
> Yes, thats (one of the reasons) why its bad.

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.

        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.

        6) Controls have plugin defined hard or soft ranges.
                * Someone (probably the host) must deal with
                  clamping for controls with hard ranges.

Quite a few alternatives there... (I'm in a bit of a hurry, so I
haven't considered each one carefully. Please comment if you think of
some problems or advantages with each approach.)

[...]
> > Why? Is +/- 42.0 P-P or something a better 0 dB reference? :-)
>
> Ah, I meant "not the right phrase", not "not the right thing".

Ok, I see. :-)

[...]
> > 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.

[...]
> > Whether or not this is useful in your average studio is another
> > matter, but it does *work*.
>
> Right, I suspect it isn;t the reuirements and aims are different.

Yeah, Audiality will have to deal with multiple songs and soundscapes
- but when I think more carefully about what a full mix of a real
song actually looks like, I have to shift my position on this
slightly.

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.

//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 : Fri Feb 07 2003 - 16:24:44 EET