Hi all, I’m trying to implement a looper with switchable feedback. I’m finding that recycling a captured loop by feeding it back into itself is resulting in a nasty distortion even at less than 100%. The looper examples I’ve found don’t have feedback. They just capture the sound. Any ideas? Psy
1 Like
Do you mean feedback as in “overdub”, or something more advanced/fx-like?
I guess I’m after a delay but with a ‘freeze’ function.
What kind of object are you using? Blocking DC in the feedback loop with an HP filter solves many problems.
Ah, I’ll give that a go today thanks! I was surprised how quickly the sound degraded in a nasty digital sounding way. I wouldn’t expect that from a high quality digital feedback system. Anyway thanks for the tip.
Would you recommend any particular HP filter? 2pole vs 4 pole for instance?
Also make sure you’re using 32b versions of the delay reads, writes, and/or tables (if they exist. delay/ * ms are all 32b)
1 Like
Thanks for the advice. Adding a high pass filter cleaned it up a lot but it still sounds like a 12bit pedal from the 90’s. I compared it to my boss DD20 from the early 2000’s and the sound on that is much cleaner. If you have any other advice
I’d appreciate it. Cheers, Psy
This one runs on 16 bit, search for “write 32b sdram” (and also check the related read objects)
Thanks. I tried this but I can’t find an interpolated 32b read object. I’m losing the will to live here. I don’t think this is doable. Are there any high quality delay patches in existence for Ksoloti? Thanks for your help.
the objects by rbrt have feedback. check rbrt/looper/ldub and then the help patch.
the feedback is happening internally, so 100% clean
Thanks for the heads up. I can’t see a file with the name ‘rbrt/looper/ldub’ but the looper_stomper does have feedback so I’ll give that a go - cheers!
Well that works and there’s no fizz as it decays. Unfortunately when closing a loop there’s often a click which renders it unusable for me, (it doesn’t seem to be editable either). It does prove though that it’s possible to get a clean sound from this system. I was beginning to think my unit was faulty. I’ll keep trying examples until I find a clean delay.. Thanks for proving a point anyway.
I found it puts a click on the splice. Thanks though.
OK, I think I have the solution. The ‘CPwitz tape delay’ object doesn’t degrade the sound UNLESS you run it at a low sample rate. I’m not sure if that’s what I was doing using the other delays but this one sounds really clean so I can get on with building my time machine Mwwwhhahahaa…
Thank you all so much for helping me out with this. I know the pain will be worth it in the long run. Back to my vision of integrating loops and delays into my modular system.. 
Good that you’re making progess!
- I may have been wrong that there are 32b versions of delay/read objects. It looks more like the delay/read’s usually work at 32bit and will figure out the conversion based on information passed to them from the respective delay/write. In short, the write should do “32b” as in 32 bits - otherwise the fine details of the signal get lost really quickly as it is recycled several times.
Here are some thoughts for anyone’s future reference:
- A possible reason you’ve had lofi, bit-crushed effects may have been because when you implement object feedback (patch a wire from “right to left”), it may introduce a phase delay of at least one k-rate cycle (= one buffer size), i.e. of at least 16 audio samples, which at 48k sample rate amounts to 0.333 milliseconds. Also depends on where on the canvas the objects are located (execution order)?
- This delay (or phase shift, if you will) is enough to mess up the signals and introduce a sort of comb filtering effect.
This is (if I am not mistaken) the reason why this sort of multiple recording/overdub/feedback business is best handled inside one single object, i.e. within the same k-rate cycle, and using tables - when “freezing” a delay signal, it should not be written to, but the delay read and write system is repeatedly rewriting the signal plus additional overdubs to the delay line. - Another reason might have been possible clipping when signals are added together - it may require using a compressor at the input or output of the delay line to guarantee satisfying loudness while avoiding clipping.
1 Like
That’s interesting. Wouldn’t the phase delay produce a comb filtering effect? I didn’t try sending the output signal back in via the A/D, D/A converters believing that that would produce a degraded signal but maybe I should though the original idea was to have multiple feedback systems within the same patch. The patch I have doesn’t allow me to insert processing into the feedback patch unfortunately but at least it’s clean. Thanks for the advice..
Yes, that would likely be a comb filter effect. You could also try inverting the phase of the fed-back signal, so-called negative feedback, sometimes helps to avoid nasty spikes.
Actually running the line output back in the line input would introduce more delay, I believe the overall latency “inside Ksoloti”, from line in back to line out, is 2 ms (because of some additional buffering and conversion shenanigans)
1 Like