Rhythmic Delay v2

sonic_explorer

sonic_explorer

Active member
I have updated the Rhythmic Delay program and added a few new features. I posted some ramblings about the new version here, but there is a summary below also. The gitHub link to the code and a compiled .bin (in the build directory) are here. I hope to make a demo showing some sounds in the next few days.

Like the original Rhythmic Delay, this version uses the Binson Echorec as inspiration, but is not trying to perfectly mimic it....because I have never played a real Echorec. This version has the same controls as v1 (Delay Time, Mix, Feedback, Tone), but adds 2 more controls and gets rid of the 1kHz whine. The program can do normal delay sounds, but I think it really shines with more space filling / full sounding / washed out sounds.

In tests with my Terrarium builds (and those who volunteered to help test) the 1kHz whine seems to be gone with this program. I did two things to help mitigate the whine:
- Set blocksize=1 with the samplerate=48kHz, which puts the whine frequency ( = samplerate/blocksize) at 48kHz, which is well above the range of human hearing.
- Break ProcessAudio down into 4 parts where a max of 1 part is called during an AudioCallback to minimize processing.

v2 added controls are Age and Swell. Age adds subtle modulation on the left half of the control and adds something that feels like degradation (to me at least) on the right half of the control. The Swell control mixes in a faux reverb sound that consists of sending the delayed repeats back through a 4 head delay with all heads on (and same head spacings and the normal delay). I also changed the right footswitch to set the feedback to 0.95, which creates really long (but not infinite) repeats to produce kind of a sound-on-sound feel. The right LED also shows the delay time of the longest delay (head 4).

I tried to add a lot of comments to the code, but if people have questions about specific parts let me know. I am happy to hear suggestions for the program, but also one of the great things about making the code public is anyone can take a stab at tweaking things to their own taste. A few very easy things to tweak if people want to get their feet wet is adjusting the maximum amplitude of the modulation and what value the feedback goes to when the second footswitch is engaged.

A special thank you to those who helped confirm that the 1kHz whine was eliminated with their setups: @Dali, @Gordo, @bretvh, @untamedfrontier.

EDIT: Here is a short demo of the program.
 
Last edited:
I had my Terrarium nearby so I just had to try it quickly. Very nice additions to the program, can't wait to try it for real tonight.
Thanks for sharing!
 
The new rhythmic delay is interesting and I need to play with it more. The age dial has some unexplored territory that is fun with long repeating delays. Add a reverb control to the mix and it starts trespassing into Deflector territory. How did you wire in the two additional switches to your Terrarium Board, and what are you using them for?
 
Thanks for sharing this! The modulation and reverb controls add a lot of versatility. I'm not hearing any of the 1kHz whine (is this the solution?). Although I think that the tap tempo would be a welcome addition to effect (it's a rhythmic delay, after all), I do really like the 0.95 feedback. The only issue is I'm getting some harsh clipping with high feedback settings (and humbuckers). Is that a product of the daisy, or is that with a high amplitude signal hitting rails on buffer circuit?
 
benny_profane said:
Thanks for sharing this! The modulation and reverb controls add a lot of versatility. I'm not hearing any of the 1kHz whine (is this the solution?). Although I think that the tap tempo would be a welcome addition to effect (it's a rhythmic delay, after all), I do really like the 0.95 feedback. The only issue is I'm getting some harsh clipping with high feedback settings (and humbuckers). Is that a product of the daisy, or is that with a high amplitude signal hitting rails on buffer circuit?
Click to expand...
It might be signal level, but I'm not sure, since it sounds like the repeats might not be as clean as the dry signal with this version even when the feedback/mod/decay/swell settings are at their minimums. I find myself using the tone control more to dial down the high end with this version. I need to spend more fun time with it to see if dialing down the input level cleans it up.
 
zgrav said:
How did you wire in the two additional switches to your Terrarium Board, and what are you using them for?
Click to expand...
Before I soldered the pots on the Terrarium I soldered a bunch of extra wires to the pot side of the pcb where the pin headers poke through. The Terrarium only uses a few of the Daisy GPIOs so there were enough open pins for me to add 2 extra mini switches and to fully wire up 3 RGB leds. I have been trying to write programs for other Terrarium users, so I have not used the extra switches in a final program - but I have used them occasionally in debugging and trying different things. For example I wanted to hear the difference between two different modulation values, so I used one of the extra switches to switch between them and had the rest of the pedal operating as it would normally.

benny_profane said:
The only issue is I'm getting some harsh clipping with high feedback settings (and humbuckers). Is that a product of the daisy, or is that with a high amplitude signal hitting rails on buffer circuit?
Click to expand...
I get this when maxing out the feedback pretty quick, independent of single coils or humbuckers. It seems like the signal is getting clipped to me, but I don't know if it is the Daisy chip or the opamp (my guess would be the Daisy). You could make the max feedback <1.0 if you wanted to avoid this from everything happening.
zgrav said:
It might be signal level, but I'm not sure, since it sounds like the repeats might not be as clean as the dry signal with this version even when the feedback/mod/decay/swell settings are at their minimums.
Click to expand...
The way the code is written I *think* the repeats should be the same quality as the original signal. I do get a higher noise floor with my Terrarium build no matter what program I use though, so I don't know if that is a Daisy or Terrarium or just my build thing.
 
Hey thanks you for that update !

I really dig it.

I don't know if it's my Terrarium build but it looks like FS2 is always illuminated and I don't really get the effect described (Sets the feedback at 0.95 to produce a kind of sound-on-sound where repeats take a very long time to decay).

Anyone can provide a small video of the feature so I see if it's just my build.

I use the ready-made BIN file by the way.

Thanks again @sonic_explorer for sharing your talent!
 
Hey @Dali - Sorry for the late feedback, I just uploaded a video trying to show how the second footswitch works: youtube link. .....I could not resist adding a bit of noodling to the clip too. I still hope to do a more thorough demo, but this is what I have for now.

It seems like something may be up with your build if the second footswitch is always illuminated. It is supposed to flash with the time of the delay and not change at all when the second footswitch is pressed. Is the second LED on all the time with other program loaded onto the Daisy?
 
I put together a short one take demo for the Rhythmic Delay v2: link here. It is pretty much just me playing the same A minor pentatonic riff over a few different settings for 12 min. Maybe it will encourage someone to load it up or build a Terrarium though.
 
I built a Terrarium and flashed this. Works great, and sounds good, thanks!

If I leave the pedal plugged in for a while, it eventually crashes, and I need to unplug and restart it. Is there anything that can be done about that?
 
soggybag said:
I built a Terrarium and flashed this. Works great, and sounds good, thanks!

If I leave the pedal plugged in for a while, it eventually crashes, and I need to unplug and restart it. Is there anything that can be done about that?
Click to expand...
I will look into this. It is an annoying problem for sure, but it is also annoying to fix - because each time I make a potential fix I have to wait the hours or days until it crashes to see if it is actually fixed.
 
@xconverge I do have an stlink and find it very useful for iterating on a program (flashing and reflashing and reflashing as I change things). Maybe I am not using the stlink right or to its full capabilities though - how would you use one to hunt for this issue quickly?
 
sonic_explorer said:
@xconverge I do have an stlink and find it very useful for iterating on a program (flashing and reflashing and reflashing as I change things). Maybe I am not using the stlink right or to its full capabilities though - how would you use one to hunt for this issue quickly?
Click to expand...
A lot of options but you want to build with debug symbols and then attach the debugger, and leave it running for a few hours and come back to it and see the stack trace when its crashed. There are a lot of other options but this is my favorite/preferred way, I would experiment/play a bit to make sure you understand it (by putting in some break points with your IDE, viewing the call stack, etc) before waiting the full few hours

In my makefile I put this to make sure my call stack will be most useful (optional but you WILL want debug symbols at some point):

OPT=-Og -g

Then I use vscode and have this https://github.com/bkshepherd/DaisySeedProjects/blob/main/Software/GuitarPedal/.vscode/launch.json

and use the vscode Cortex debug https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug extension

Once all setup, I build the binary with the debug symbols (make command), then I flash it, then I run my debug task and it "Attaches" to the pedal, restarts the sw automatically, and pauses at the first line of main(). I then press "Execute/Resume" and it starts running normally.

You can press pause or put a break point somewhere and look at the call stack/see whats going on, look at variable values, etc, but in your scenario you just want that call stack to give you a line number/function to point at exactly whats happening. When this happens if your debugger is attached you can even look at variable values, etc to get a full picture of what happened, if you have an index out of range or a nullptr somewhere, etc

Getting Started - Daisy

daisy.audio daisy.audio

printf debugging is fast and classic for a reason, but if you have the stlink already, running under the debugger (for all embedded work IMO) is invaluable if you start to run into memory/crash/confusing things. One thing that can bite you (but probably wont for this case, since its probably a buffer overrun or something) is running under the debugger or changing the optimization flags can and will change behavior for some types of bugs/race conditions when multithreading, etc
 
You must log in or register to reply here.
Back
Top