[linux-audio-dev] XAP: Control events

David Olofson david at olofson.net
Wed Dec 18 08:08:01 UTC 2002


On Wednesday 18 December 2002 12.38, Sami P Perttu wrote:
> 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?

Why? At least, I'd find Hz *really* inconvenient when programming 
filters on synths. I want them in the same unit as pitch, to make it 
easy to have filters track pitch and that kind of stuff.


> Not to
> mention that most (?) plugins need to convert to Hz/samplerate
> anyway, involving an expensive exp().

Someone, somewhere has to do that anyway. And calculations differ 
depending on what you're doing, especially when you're processing 
events rather than just generating audio from them.


> 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, I can't think of any serious use for exactly 0 Hz, or even 
anything very close to it.


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

Yeah. (If we have splines, that is. Otherwise, just RAMP to the 
default value, and then stop ramping with a SET  before 
disconnecting.)


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

Right. That's why you basically don't let ramps run across block 
boundaries.

That said, it's perfectly legal to aim for longer distances, since 
you can just send a new ramp or set event at any time. The current 
state when the new event is handled is the starting point of the new 
ramp. It doesn't matter where the original ramp was *supposed* to 
end, since that's basically just an aim point. (If you sent slope 
instead of target + duration, you would have rounding errors build up 
over time.)


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

Yeah - and there's another reason not to do splines: overshoot. 
Doesn't mix with controls with hard ranges.


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

Ok. Although it seems like we're not having splines after all, due to 
various mathematical and implementational issues mentioned earlier.


//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 ---



More information about the Linux-audio-dev mailing list