[linux-audio-dev] Synth APIs, GluttonAudio

Sami P Perttu perttu at cc.helsinki.fi
Fri Dec 13 14:13:15 UTC 2002


On Fri, 13 Dec 2002, David Olofson wrote:

> > What is that? If a plugin got an audio port event it would just
> > update a pointer. Past samples should be kept in temporary
> > variables and future samples should not be looked at.
>
> Correct. But consider this example:
>
> 				out[s] = left[s] + right[s];
> 				++s;
>
> Now, if you get a new buffer for left in the middle of the buffer,
> what happens...? This is what I'd call "non-obvious implications".

Oops, I didn't consider that. Solution: require that pointers point to
start of block even though there may be no data there :).

> IMHO, this is complicating the API for no good reason.

Then we are back to square one: multiple versions of plugins that differ
only in control and audio port details. If the plugins will, as you say,
indeed be higher level than CSound then it won't be a problem.

> > I don't see anything physical about audio ports in XAP,
> > although it might be better if they were actual objects.
>
> 	typedef	XAP_sample *XAP_buffer;
>
> Do you need an object for that? :-)

No, sorry, I should make myself clearer. I was thinking about the pull
model again.

> BTW, I am indeed going to look into some sort of "process only this
> range" feature for the rendering engine. Some sounds take a while to
> render, and there's no point in waiting for the whole sound to render
> when you're just tweaking the attack.

...or let the rendering run in a background process.

> How? It's not the host that sends these events in general; it's other
> plugins. The host never touches the events in the normal case.

Okay. I'm lost here because I don't know what a XAP app would look like. I
only know trackers :).

> > Logically, controls are like ports: they have a definite value at
> > each point in time.
>
> You *could* say that - but don't forget that many plugins are
> oversampling internally...

> internally. As a result, the filters and oscillators see zipper noise
>
> Now, if control was seen as continous rather than sampled, it would
> [...]
> That said, the problem is that you cannot get away without actually
> implementing this. If there are cubic interpolation events, all
> [...]
> Well, you could just use the extra argument as "slope", to suggest
> the desired slope when "target" is reached. So, for chained sections,
> you get <value, slope> for start and end of each section. Either just
> ignore the slopes and do linear interpolation, or do something more
> sophisticated, to take the slopes in account as well. (Basic splines;
> "smoothest path".)

What happens between sample values. Now we are too far in the
hair-splitting territory :).

If we are dealing with 3rd order polys then both point-slope and
coefficient formats contain the same information. I guess we should pick a
representation that allowed lower-order approximations to be made
efficiently. If plugins can't handle anything but constants they would use
the average value; linearly ramping plugins would use the initial value
and the slope as you describe. 2nd order approximation is probably
useless. Plugin picks the order and invokes a macro to get the
coefficients. Conversion between 3rd order poly coeffs and point-slope is
pretty trivial. Take your pick. Perhaps some spline expert could comment
on this?

--
Sami Perttu                       "Flower chase the sunshine"
Sami.Perttu at hiit.fi               http://www.cs.helsinki.fi/u/perttu




More information about the Linux-audio-dev mailing list