softcut (ugen and engine) : audio quality enhancements

[catfact]

we did some severe, last-minute corner-cutting on audio quality for the SoftCutHead ugen, for performance reasons.

• playback resampling uses linear interpolation (fractional rates have noticeable aliasing)
• all parameter changes are control-rate (bad artifacts when using lag on speed, fast last with record is ugly)

there are others, but these two are the most noticeable and i would love to revert them.

independently, we must fix the resampling for the write head. it doesn't even attempt to be correct linear interpolation right now. there is a softcut-resample branch, created before the quality-reduction changes, that does so (as well as refactoring / cleaning up.) for some reason this branch crashes on ARM but works on amd64 (hopefully something silly like a pointer error.) this task is orthogonal.

tasks

• revert quality reduction changes. (requires making CPU headroom somehow.)
• fix resampling branch for ARM.

[tehn]

reverting (to higher quality) would be great given the dropout/noises were unrelated

[catfact]

? they weren't unrelated at all. the changes reduced usage by 25% or something, which was enough to avoid glitches. adding -s to jackd isn't really a magic bullet, we still have glitches with too much usage (and less than i'd hope for), but maybe there is enough headroom again.

[tehn]

you’re correct, i was confusin my issues

…

On Thu, Jun 7, 2018 at 11:23 AM ezra buchla ***@***.***> wrote: ? they weren't unrelated at all. the changes reduced usage by 25% or something, which was enough to avoid glitches. adding -s to jackd isn't really a magic bullet, we still have glitches with too much usage, but maybe there is enough headroom again. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#407 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPEcG1o37FkZkxRomI6sJCwbqYQAvMSks5t6UVegaJpZM4Udhk0> .

[catfact]

i wasn't thinking about write-head interpolation as part of this - just that it would be nice to revert the changes to playback interpolation quality, and make speed change / trigger timing sample-accurate again.

right now, simply reverting those changes will cause a glitchfest. because they will push cpu usage for the scsynth audio thread back over the ~60% threshold that seems to still be the barrier for xruns (or IO stalls - i'm still not sure what these artifacts are since jackd doesn't report them.)

but yes, resampling the write head correctly is another related task. the changes insoftcut-resample branch work very well on amd64 systems, but the buffer writes in the Resampler class totally crash on ARM for some obscure reason i haven't yet identified.

that should properly be a separate issue - i should be able to get write-resampling working correctly independent of the changes referenced here, and vice-versa.

in any case, it's necessary to save CPU somewhere else before we can apply it to higher-quality algorithms here. my current investigation is into moving aux and insert FX processing to a separate scsynth instance. (#417)

[catfact]

another thing we could do is basically redesign the engine. i guess it's important for the vision of MLR to be able to arbitrarily read or write with any head. but it would be vastly simpler to have a dedicated record head that is locked at speed=1

[catfact]

with record level being at control rate, lag sounds bad (a sweeping glitch artifact, worse than a click.) so it is currently disabled in the SoftCutVoice abstraction.
https://llllllll.co/t/norns-dust/14015/110?u=zebra

[catfact]

actually if anyone wants to test the conclusion that .kr lag is worse than no lag, just uncomment these lines.
https://github.com/monome/dust/blob/master/lib/sc/abstractions/SoftCutVoice.sc#L53-L54

for speed changes the zippering is definitely noticeable; maybe level changes are not so bad.

[tehn]

success. splitting issue for record head