On Tue, 17 Dec 2002, David Olofson wrote:
Thanks for the
explanations... there is still one thing I don't
understand. Do you intend to have both frequency (Hz) and pitch
(logarithmic Hz) controls? It seems redundant.
There will not be Hz at all, if I can help it; just linear PITCH, and
hopefully "linear" pitch hinted as "I really mean *linear*" - ie
NOTEPITCH. :-)
What about things like filter center frequency, isn't it "unnatural" to
give these as logarithmic frequencies? Not to mention that most (?)
plugins need to convert to Hz/samplerate anyway, involving an expensive
exp(). Also, you can't specify negative frequencies in logarithmic Hz, and
0 Hz is the awkward minus infinity. But maybe they are not needed.
Well, we'd have to switch to 64 byte events for
that. However,
there's no good reason to double the start/end data, for reasons
explained below.
Okay, I realize it makes sense, especially the bit about switching
connections.
That said, giving ramp events a specific duration,
after which the
ramping should stop *might* be nice. I'm still suspecting that this
is an illusion that won't help real code at all, though. (It didn't
in Audiality, at least, and I can't think of a real situation where
it would be useful.)
I agree. Plus it adds a conditional per sample, which is not nice.
Click free? Just have the host take over the port for
a while, before
really disconnecting it. (The plugin that owns the input will never
notice this.) Send a ramp event of suitable duration, that takes the
control back to the default value. Then disconnect.
This is cool. With a target slope of 0 the control settles nicely to the
new value.
The timing of
the next event need not agree with the duration given in the
current event - the next event may arrive at any time.
What's the point? As a control data generator, you can't just jump in
and out as you like. Either you're connected, or you're not. When
you're connected, you do your job, and deliver a stream of structured
data that represents a continous signal.
Well, I think it is a good semantics for duration: nobody knows what
will happen in the next block, and the plugin should not need to check if
the section has ended.
[...]
Note: it is assumed that plugins choose their
approximation
irregardless of the actual polynomial, which can be constant or
linear. I think this is a good assumption. Exact linearity cannot
be detected anyway due to the inaccuracy of floating-point
arithmetic.
Yes, that's an important point. Plugins should be concistent rather
than "smart" in this case. It would be rather annoying if some
plugins toggled "randomly" between two different sets of artifacts...
*heh* (That's a great way to make it glaringly obvious that there
*are* artifactsl even if they're very subtle.)
True. Plugins would need to generate different code for the different
approximations, anyway. Not to mention that the linear approximation is
very different from the full form... if the sign of the target slope
differs from the sign of the difference between target and current value,
the polynomial will overshoot somewhere in the middle. Etc.
As to "hitting the target", well, I think we
must analyze this more
carefully, to see how big a difference float vs double makes here,
and when. How far off can you land?
I'll investigate.
Or just use XAP_A_SET, and wait for the host to give
you your default
values that way. I think that's the best way, actually, since it
eliminates lots of boring and potentially incorrect initialization
code in plugins.
Okay.
Well, in Audiality, I just have inline functions that
allocate, fill
in and send events of the common kinds. That's the cleanest way by
far, from the plugin code POV.
Okay.
We'll have to settle on the conventions for
control generators,
though. IMNSHO, *they* should be the "smart side" of the connection,
while the receiver just does what it's told. I'm basically trying to
achieve this: [...]
Agreed. We are on the right track.
There was an error in SET_OVERSAMPLED_..., I'll fix it. Then I have to
check how to recover slope from a control variable. Then float vs. double.
I'll send a revised version shortly.
--
Sami Perttu "Flower chase the sunshine"
Sami.Perttu(a)hiit.fi
http://www.cs.helsinki.fi/u/perttu