So, each automatable model has a "step size" property, which is used for
determining the accuracy of the knobs. A step size of 0.1 causes the
knob values to move in 0.1 increments, a step size of 1 causes the knob
to only move between integer values, and so on.
This is of course good for user convenience, because it's easier to
adjust to a specific value when the knob values are constrained to
reasonable steps. There's just a problem with this: it also affects
automations and controllers, which is particularly bad for volume controls.
With volume controls, we don't even benefit from sample-exactness,
because the volume will still be moving in those 0.1% or 1.0% steps,
which causes very noticeable quantization artifacts and noise in the
resulting signal. So even if we make the volume control sample-exact, it
will still have quantization caused by the step size of the model.
You can see this easily in fast volume slides - automate a volume knob
and add an automation pattern that goes from 0 to 100% in one bar. The
crackles you hear are caused by quantization, the volume not going up
smoothly but instead in steps. Part of the problem is no
sample-exactness in playback, but part is because the step size prevents
gradual change so that even with sample-exactness the problem still
exists. Solving this would make peak/LFO controllers much more useful
and flexible, as you could connect them to volume knobs on instrument
tracks without quality loss.
So I've come up with some ideas on solving this dilemma.
1. Interpolate all volume controls (and others where similar issues
exist) - so that volume transitions would always be smooth and not
sudden: when the volume is changed, it slides from oldvalue to newvalue
in the time of one period. The problem is, the behaviour and quality of
the controls will still be dependent on period size ("buffer size" in
settings). Regardless, this could still be a good idea to do because we
don't always get sample-exact data, and this way we could smooth the
changes in automations as well.
2. Make the step size only affect the knobs, and possibly the automation
grid, but allow the actual values of the model to also go between steps.
Maybe make this behaviour configurable per-model, add a flag or
something that determines how step size is used. A boolean member could
be named "strictStepSize" or something, and it determines whether the
step size applies only on the knob or will it be "strictly" applied to
the values of the model.
3. Add a second "step size" property, so that there's two of them: one
that gets used by the widget (knob), and one that actually determines
the internal step size of the model.
Sidenote: For sample-exactness, I think the model should also offer a
second way of fetching sample-exact values - not just per-frame, which
is wasteful in CPU cycles, but a way to fetch an entire period of values
at once as an array or QVector. This way we could implement
sample-exact controls more effectively and also have it as a playback
option, not just in export.
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
LMMS-devel mailing list
LMMS-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lmms-devel
