Discussing 4.10. Ramped or Smoothed Events
Personaly, I think using events for smooth control
signals is generally a very bad idea. It may be ok for
pre-recorded linear ramps, but it will be hopelessly
complicated for non-linear functions and real-time
changing knob-style controls: how do you define the
events?
Ramps and linear motion are easy, but what about
non-linear movements, even pre-recorded? You would
have to piecewise approximate to get some usable
events and how to do that in real time? And what about
the precision? Events may be sample-accurate but the
control function will be approximative, a bad
trade-off if you ask me.
Basically there are only two types of controllers,
continuous (knob-style) and discontinuous
(button-style), and they should be handled seperately.
A knob-style control may be seen as a (low frequency)
signal generator and as such should use a well defined
sample rate. Let the control publish its sample rate
(IMHO all generators, control or not, should do that)
and/or make it accept a global control sample rate (as
in CSound). Need more accuracy? Pump up the
control('s) sample rate or let the consumer
interpolate.
A button-style control generates events and the
consumer has to figure out how to respond. If the
consumer wants to do a smooth transition, that's his
problem. These events should be sample accurate.
It may seem a good idea to define a third class of
controls, like predefined function controls that can
be described by a set of control points. But these
functions have to be interpolated anyway, so why not
do it directly at the source instead of letting every
consumer doing it for himself? (And messing things up
due to different function interpolation
implementations per consumer.)
Hints? Clues about trends? "Yeah, well I am going to
do some kind of parabolic rising thing and then at 63%
drop down rather quickly to 10 or so, all in about,
lemmesee, 400 ms I guess."
Crudesoft
