On 05/16/2014 12:46 PM, Raine M. Ekman wrote:
> Citerar Vesa <[email protected]>:
>> 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.
> My gut feeling says changing the step size should be easier than
> implementing sample-exactness. And if I'm reading you right it might
> have more impact than the sample-exactness. So, I'd go for that first.
Actually, not really - we already have most of the infrastructure we
need for sample-exactness, and implementing it is just a matter of
making things that use models (instrument tracks, mixer, effects etc.)
take advantage of it. The point was, that with the current model step
system, even if we have sample-exactness it still won't give smooth
model modulation, because the sample-exact signal gets fitted into the
steps.
>> 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.
> You're talking about interpolation at the receiving end? I don't off
> the top of my head see why that should depend on period size.
It does because currently, with no sample-exactness, each model gets
updated once per period. We can interpolate these values, but the
underlying "sample rate" of the model would still defined by period size.
> Just
> have a target value to aim for and a maximum change per period (frame,
> millisecond, whatever), change the value of the control at that speed
> until it hits the target (which could take less than a period, too!).
> When the next period comes, update target (if needed) and carry on.
So basically, what you're saying is run the model values through a
lowpass filter... could work, yes, but the results would still differ
with different period sizes...
> I'd say that is a prerequisite for adding any model-side sample-exactness.
>
Well, actually, not as such - we already have a way to fetch
sample-exact values on a per-frame basis, but that seems like it would
cost more CPU cycles than fetching the values as an array per-period.
This is more a prerequisite for having efficient sample-exactness which
could be used in playback as well as 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
