I hadn’t worked on it for a while and recently I wanted to pick it up again but it didn‘t work properly anymore.
The sound now gets filtered every time it loops.
To loop sound I used multiple delay nodes in a row so I took a closer look at the Delay node and it looks like it has a build in filter now that you realy start to notice if you put multiple delays in a row. a lot of delays.audulus (42.8 KB)
Is there a filter in the delay node and when yes why was it added there?
There isn’t a filter in the delay node, but what I’m thinking is happening is the difference between the time knob value vs. sample rate gets compounded when you add a ton of them.
I just did an experiment and it seems to confirm that theory - especially since the version you uploaded had delays that were all slightly different times. If you string together 64 of them and have them all the exact same time, it seems like there’s an initial filtering, but then it holds pretty steadily. If you change it to a non-divisible number of 44.1k, the filtering is more extreme.
Did you know though that the Delay node can go up to 20 seconds? If you have 20 of them, that means you have the potential for 6+ minutes of record time per loop. If your max division is 16 bars, then each bar would last almost 3/4s of a minute at the maximum.
If you use just one delay node, your max time for each bar would be 1.25s - so maybe use just two or three?
I’ve also been thinking about whether it could be something like that. But why did it work when i first build the Looper?
After I build this prototype and tested it (which could be tree to four months ago) I couldn’t notize any filtering at all.
Yes I knew that and at first I only had 2 ore 3 delays per Loop but then there was a problem with clearing the loops.
To clear a Loop the mix-knops of all the delays are turned to 0 so that nothing gets passed to the next deley node.
The amount of time The mix-knops neds to be turned down must be as long as the delay-time of the delay node is set to.
Becauce of that I decidet to add more delay nodes so that the delays are set to a maximum of 3.84 seconds (when the loop lengthis as long as possible).
So I used 20 instead of 2 or 3 delays becauce then the time to clear a loop would only be about 4 seconds instead of 20.
Cool that all makes sense! Not sure what would’ve happened to delay node - nothing’s been changed under the hood. Perhaps there’s a feedback loop somewhere? Maybe sticking a unit delay node in there might help?
As you said here, the amount of the filtering caused by the sample error depends on the time the delay nodes are set to.
The amount of filtering in the looper is different for each bpm and there are even some BPMs where there isn’t any notizable filtering. E.g. 120 bpm which is the bpm I was testing the looper with the first time.
So I wasn’t hearing any filtering when I was testing it a few months ago becauce i had it set to 120 bpm and i was hearing some filtering when I tested it later bacauce I had changed the bpm to something else.
I found some more bpms where the saple error isn’t producing any notizable filtering and I made some kind of preset module that returns all bpms from 50 to 300 that won’t cauce the filtering. Goundhog usable BPMs.audulus (19.0 KB)
On some of the bpms the error will still occurre but only if the loop is set to a length of 0.25 bars.
If such a bpm is selected, the green light will turn red.