18 Dec
2002
18 Dec
'02
9:07 a.m.
On Wednesday 18 December 2002 12.38, Sami P Perttu wrote:
Yeah. (If we have splines, that is. Otherwise, just RAMP to the
default value, and then stop ramping with a SET before
disconnecting.)
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.)
[...]
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.
[...]
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 ---
On Tue, 17 Dec 2002, David Olofson wrote:
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.
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. :-) 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. 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. 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.) 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.