long digital delay build log

[Marcvv]

  wow. Even boxed and all... Looks great, well done! It was great to follow your process, also as a long time pds8000 user.

[cloudscapes]

thanks guys

I'll repost an updated schematic once I've confirmed all my bodges work as intented (they seem to)

[micromegas]

wow! I would definitely buy one of those.

[cloudscapes]

I won't be selling these anytime soon, though. It still needs work, and I want to focus on building more of an older design this year anyway.

[micromegas]

I completely understand . It just seemed like a cool pedal to play with, but I think I'll have to stick to my 3sec-Timefactor for now... well, I am learning how to program pics, but DSPics are far for my knowledge at this moment.

Love your finishes btw!

[cloudscapes]

timerfactor is great though! better than mine in so many ways, stereo delays, more kinds of modulation, and overall higher sound fidelity. the loop cropping is great also, I based an earlier pedal around that feature.

[cloudscapes]

hit a bit of a snag, software wise. the hold mode. I had superficially tested hold while it was on breadboard, thoguh the "hold point" was noisy. I put that down to my not implementing debounce on the hold switch, creating a few milliseconds where it would engage in and out of hold/rec several times, creating a burst of noise.

looks like I forgot about how loops just.... loop



the normal delay works just fine! each sample (between 18k times a second, to 72k times), the sample in memory is shifted out of the DAC, and a new sample is shifted into the very next place in memory. it works great! but then when I hold, I failed to remember that loop point has the potential to have a razor sharp cliff between samples who normally weren't meant to play next to each-other.

currently thinking about ways to fix this. one is to have the loop "generate" new samples to be able to crossfade the two ends of the loop. I'm not expecting on getting perfect Freeze-like smoothness, but enough to get the edge off the loop.

[wavley]

Yeah, when you do decide to sell this/work out the bugs I'm totally up for one, my RDS-900 I've been using for 25 years can't live in my rig anymore, I'm just really tired of trying to find it's random noise floor issues and crackles and it's rack enclosure is inconvenient, so it moved over to my recording stuff to be used for special effects.  The memory boy that a friend gave me because he was so disappointed in it that I'm kinda using in it's place is, well, disappointing... it's a little *too* analog says they guy with two space echoes in his rig, it crosses the line of analog into muddy mess, I don't mind grainy nastiness at long delay times, but the short repeats are kinda gross too.  I dealt with the volume jump, this weekend I'm hoping to bias the delay chips better and get some kind of usable sounds out of it because I love the square wave modulation for the delay time even better than I loved using the modulation of my RDS in delay or hold mode. 

[~arph]

Two other ways I can think of:

1. Playback the loop in a ping pong manner, this can only work when the loop is short.
2. Apply an envelope to the signal. in such a way that at the beginning/end of the loop the volume is zero (x0) and then quickly rises to x1 this way the ends will always connect at 0.

[SISKO]

2. Apply an envelope to the signal. in such a way that at the beginning/end of the loop the volume is zero (x0) and then quickly rises to x1 this way the ends will always connect at 0.

This

[slacker]

What they said

[anotherjim]

I'd suggest envelope too.
Never done it in hardware, but know that when editing in an ancient audio editor that didn't easily allow crossfade, a short fade in and out wasn't  audible, may have been as short as 5mS.

I'm also wondering, if you might get away with interpolating (averaging) sample values at the transition, so there can't be an abrupt jump in level.

[cloudscapes]

- thought of ping pong, but not sure about it. the delay just isnt that kind of delay, and reversing the loop at loop point can still cause spikey waveforms (think of a wave going downward and flips/reverses right at the half-way point).

- the fade out-in envelope is a pretty good idea! I think I'll try this first, since it's pretty easy to do in software. the moment hold is engaged, the delay still acts "normally" for a few milliseconds while fading out, then the actual hold, and fade in, writing to memory for those first few milliseconds for fade but not during the rest of hold.

- interpolating the two loop points is a bit tricky, since for that to really work, I need to "look ahead" in time, which the delay isn't really built to do. it has access to the current sample, plus a few samples back in time. but not ahead. I'll have to think about it some more....

thanks for ideas!

[SISKO]

- interpolating the two loop points is a bit tricky, since for that to really work, I need to "look ahead" in time, which the delay isn't really built to do. it has access to the current sample, plus a few samples back in time. but not ahead. I'll have to think about it some more....

I think its doable, but not worth it unless fade in/out doesnt work

[cloudscapes]

I think its doable, but not worth it unless fade in/out doesnt work

maybe. it's really hard for me to imagine these sorts of things though. never been good with numbers, or figuring out what it takes to manipulate numbers over time like this.

interpolation might work like this:

- user hits hold button and is acknowledged by software,
- software "holds" and creates two new temporary samples. one slightly before the loop point, one slightly after (a few samples). it also needs to temp store the position in memory the hold occurs.
- software lets the loop go another loop around, until the stored memory position for the first temp sample
- at this memory position, it starts interpolatinng between sample A and sample B over, say, 40 samples (about 1ms at the delay's middle setting). overwriting the memory at this spot.
- once finished overwriting 40-ish samples during hold mode at the loop point, it can "forget" the temp samples/mem locations and just loop normally.

this seems horribly complicated, even if doable. I also realized that regardless what kind of loop smoothing I do, I'll need to do something similar when I disengage hold and go back to delay mode. a similar fade-out / fade-in when ihold is disengaged.

I just did an experiment, recorded the delay loop noise, loaded it up in a sound editor and simulated 5-10ms fade out/in on each loop point. there's still an audible "point" where you can hear the loop turn over, but it's MUCH better. I think I'll try this first, as it's the most straight-forward.

- user hits hold and is acknowledged by software
- software is still sampling, but as of the moment of hold, a short 10ms fade-out is applied.
- 10ms later, it stops sampling and just plays back memory at that position. a fade-in is applied to another 10ms of in-memory audio as of that point. writing the fade-in envelope back to memory for this duration.
- once done this 20ms fade out/in, it can stop worrying about this and just play back the loop normally.

[knutolai]

- interpolating the two loop points is a bit tricky, since for that to really work, I need to "look ahead" in time, which the delay isn't really built to do. it has access to the current sample, plus a few samples back in time. but not ahead. I'll have to think about it some more....

If you are able to look a few samples back in time, wouldn't changing the "now"-point (reading from another place in you input data-buffer) give you look-ahead by adding some tiny extra delay? The last sample in you input data-buffer does not need to be your "current" sample right?

[cloudscapes]

- interpolating the two loop points is a bit tricky, since for that to really work, I need to "look ahead" in time, which the delay isn't really built to do. it has access to the current sample, plus a few samples back in time. but not ahead. I'll have to think about it some more....

If you are able to look a few samples back in time, wouldn't changing the "now"-point (reading from another place in you input data-buffer) give you look-ahead by adding some tiny extra delay? The last sample in you input data-buffer does not need to be your "current" sample right?

Because adding a tiny extra delay would change a whole lot of the fundamental stuff everywhere in the delay. It's possible, just risky, and doesn't seem worth it.

[SISKO]

this seems horribly complicated, even if doable.

This is what i was tryin to say.

I just did an experiment, recorded the delay loop noise, loaded it up in a sound editor and simulated 5-10ms fade out/in on each loop point. there's still an audible "point" where you can hear the loop turn over, but it's MUCH better. I think I'll try this first, as it's the most straight-forward.

Some ideas :Try less time ¿1mS?, try differents kind of envelopes, linear might do good, but exponential could do better,

[cloudscapes]

Interpolation is doable, but it just feels like such a headache. I can barely grasp the concept, and the bit about waiting a whole loop turn to apply it seems like it'll create more bugs than fix it. It doesn't sound that much better than fade in/out when simulating it. There's still the sudden change of levels of the signal that really only true crossfade can fix. And to be able to do that, I'd have to shorten the loop at the moment of hold. That part's easy, but it gets really complicated when I un-hold. I can't really unshorten it when the loop has been altered to crossfade.

I'll keep giving interpolation some thoughts these next days, but it just feels orders of magnitude more complicated and error prone to me.

I'll also see if I can get fade out-in working today. And yeah I will def make sure I can vary the length of the fade at will. It'll be interesting to try several lengths. I'll see about log envelopes. I'm no DSP wizard.

I'm also gonna see if I sample/capture the loop point straight out of the dac (rather than pedal out, with all the filters) just to get a clearer picture of everything. I'm a visual person like that, it helps with the thinking.

[anotherjim]

Thinking about it, for guitar, 2-4ms ought to be sufficient for fade length. In a band/multi-track scenario, I doubt it would be noticeable.
For crossfade or interpolate, I think your system would have to always be "playing behind" by some buffer so it can fake looking ahead.

What if on hold, hold doesn't happen until a zero crossing sample (within a small offset of it, since it might be a while until an exact zero value occurs)? Start of loop is muted until another near zero crossing sample( or the buffer start pointer is moved to one)? That still leaves the problem of not getting a perfect splice, because you might get a last half-cycle dropping from positive leading into a first half-cycle rising positive.  May or may not be tolerable.