13 Dec
2002
13 Dec
'02
3:12 p.m.
On Fri, 13 Dec 2002, David Olofson wrote:
Oops, I didn't consider that. Solution: require that pointers point to
start of block even though there may be no data there :).
No, sorry, I should make myself clearer. I was thinking about the pull
model again.
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". 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? :-) 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(a)hiit.fi http://www.cs.helsinki.fi/u/perttu