As topic says …for tape delay echo shit and stuff …
Multitapdelay time smoother …yuuuuy
Already done for Redux. But not everyone agrees that this is a good thing
https://forum.renoise.com/t/is-there-a-list-of-effects-changes-somewhere/43733
It all sounds fantastic apart from that, I can’t believe you’ve done that to both of them. That was a feature, not a bug.
It would be wonderful if you could choose smooth behaviour or old behaviour, maybe even with the old behaviour exaggerated when that mode is being used.
“‘Delay’ and ‘Multitap’. Changing delay times no longer creates those “zipper sounds”: delay time changes are crossfaded now” Any chance of the old versions of the devices, without that change being in the deprecated list?
I guess you’d want an additional parameter specifying the crossfade (smoothing) amount
Hm I would vote for the new crossfade stuff (and leave the old version for comp ability reasons), but if I test the new Redux delay, it produces somehow crackles on fast delay changes… Did I use it wrong? Or is it possible to optimize the crossfade, for example the length of cross fade dependent of the amount of value change?
Already done for Redux. But not everyone agrees that this is a good thing
https://forum.renoise.com/t/is-there-a-list-of-effects-changes-somewhere/43733
I guess you’d want an additional parameter specifying the crossfade (smoothing) amount
What do you mean already done for redux ?
The crossfade smoohing in redux sounds nothing like the examples above ,
Is is so hard to understand …changing a delay from 1000 ms to 200ms …with the proper smoothing algo …we get a pitch shift effect .just like old tape delays …
The posted audio example is from a reaktor ensemble I made …to give you an idea
https://app.box.com/s/ibvc1vw35bdlhcvmvq8q8nnsl6ia5k7g
Smoothing != Cross-fading.
Smoothing means slowly changing the delay time to a new value instead of setting it abruptly, but also results in those “zipper” sounds. That’s what Renoise’s old delay and multitap devices have done.
Crossfading is like having two separate delay lines, one with the current delay time, the other with the new one, then cross-fading from the old to the new delay line. This is what Redux’s delay and multitap devices now do.
Crossfading only works perfectly when there is enough time to actually finish the crossfade. If you start changing the delay amount again while it’s still crossfading the previous change, you will get some other form of crackles. This could only be avoided by having up to N delay-lines running in parallel to crossfade between N-1 delay time changes. This is not very practical - usually not worth the computational (and memory) overhead.
Zipper noises of the smoothing can be reduced by increasing the smoothing duration. If you want to get rid of them completely things start to lag a lot (behave like a tape machine).
Both ways have advantages and disadvantages. In general it’s better to do cross-fading when you don’t expect that the delay time gets modulated, but only to be changed every now and then. Which is what we now expect in the delay and multitap-delay devices.
Smoothing usually is better when you expect that the delay time gets changed constantly, when it’s automated - or when you want those zipper sounds. Delay lines in the Flanger and Chorus do such a smoothing for this reason.
And here 2 examples , xrni which currently aren’ possible anymore to achieve in redux
Rising pitch with the old chorus
https://app.box.com/s/qfrusg6xh5p39whumh6bc9g2tyhu2115
Rising pitch with the old delay
Hm I would vote for the new crossfade stuff (and leave the old version for comp ability reasons), but if I test the new Redux delay, it produces somehow crackles on fast delay changes… Did I use it wrong? Or is it possible to optimize the crossfade, for example the length of cross fade dependent of the amount of value change?
I haven’t encountered those crackles myself, but in theory this sounds like a possible refinement.
Zipper noises of the smoothing can be reduced by increasing the smoothing duration. If you want to get rid of them completely things start to lag a lot (behave like a tape machine).
In reaktor it is called an audio smoother ( not to be mistaken with event smoother ) , it interpolates/smoothes between audio samples by a user defined time…
Sure , it is more cpu hungry since it computes at audio sample rate , but since reaktor ain’t nowhere near efficient as low level c++ coding , I have a hard time believing that implementing this feature in renoise would cause cpu issues
Exactly , the screensots I posted above show exactly that , a user defined smooting time …20…50ms is more then enough to get rid of zipper noise …
I would be great if we had an option to set the smoothing time in the mutitapdelay
I haven’t encountered those crackles myself, but in theory this sounds like a possible refinement.
Maybe crackles is the wrong description, it’s more like this cheap repeater effect from old raggaton music.
Smoothing != Cross-fading.
Smoothing means slowly changing the delay time to a new value instead of setting it abruptly, but also results in those “zipper” sounds. That’s what Renoise’s old delay and multitap devices have done.
Crossfading is like having two separate delay lines, one with the current delay time, the other with the new one, then cross-fading from the old to the new delay line. This is what Redux’s delay and multitap devices now do.Crossfading only works perfectly when there is enough time to actually finish the crossfade. If you start changing the delay amount again while it’s still crossfading the previous change, you will get some other form of crackles. This could only be avoided by having up to N delay-lines running in parallel to crossfade between N-1 delay time changes. This is not very practical - usually not worth the computational (and memory) overhead.
Hm, but the usual case would be automation of the delay values, which would result in a constant value change in high frequency - just like a slider movement. So my question would be, is it possible to improve the smoothing / crossfading concept here, so also slider moves will sound smooth?
No clue if this is rubbish, but
- maybe at least bunch of crossfades at the same time, not only one, and length of crossfade dependent (or reversed dependent?) on amount of value change?
or
- limit the possible update frequency of the delay value in the fx itself, so e.g. the update would happen with 10 Hz or something and never faster, then the value change would sound much smoother… Since the change of the delay value always needs some time afterwards to be recognized anyway.