[linux-audio-dev] XAP: Control events

[Sami P Perttu]

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 at hiit.fi               http://www.cs.helsinki.fi/u/perttu