slackdsPIC - some experiments with dsPICs for audio mangling purposes

[samhay]

nice one Ian.
I must get back to the proper digital stuff soon. Your analogue schem doesn't mention the pot values - are they all 10k?

[Digital Larry]

Awesome work man!  Just think how good it would sound with Germanium voltage regulators!   

Did you write your own pitch shift code?  I have been trying to fix the ramp LFO simulation in SpinCAD Designer for about a year now, what a pain!  I think I'm getting close, but some of the sounds that come out in the meantime are occasionally hilarious.

[slacker]

Cheers folks

I've got some more chips on the way Rob, hopefully that solves the problem otherwise I'm a bit stumped.

Pot values aren't critical Sam, anything from 10k to 100k should work fine, I'm using 100k because I had them to hand.

Germanium voltage regulators, could be just what I need to mojo up those 1s and 0s. Yes I wrote my pitch shift code, it's essentially same method the FV-1 uses, as described in the LFO appnote. The actual pitch shifting was pretty straightforward but it took me ages to get the cross fading between the two taps working properly, Sean Costello's excellent articles on the subject really helped me understand the concept http://valhalladsp.wordpress.com/2010/05/06/digital-pitch-shifting-early-work/. The code is here https://github.com/slackDSP/slackdsPIC/blob/master/slackdsp.c afraid I haven't got round to commenting or documenting it.

[slacker]

After a fair bit of head scratching I finally figured out the problems I was having with the 23LC1024 SRAM. Thinking I'd damaged them by leaving one of the pins floating I added the required pull up resistor and stuck a new chip in, still the same problem, no output from the chip. Totally confused me because I had them working on the breadboard albeit with some distortion, which I put down to the missing pull up. I started poking about with the scope and noticed that if I probed the clock pin the thing would work, I then tried holding a resistor between the clock pin and ground and that made it work as well. Armed with something to google I found a forum post about the exact same problem, luckily with a solution
The problem was with the set up of the PIC's SPI port used to talk to the SRAM, this works by having a clock signal and a data signal, on the rising edge of each clock pulse  the SRAM reads in a bit of data. There's a setting that tells the PIC to change the data either on the rising edge of the clock or the falling edge, I had this set wrong so I was changing the data on the rising edge, which is the same time the SRAM is trying to read it so it was just reading garbage and as a result it wasn't doing anything useful. Correcting it to change the data on the falling edge and everything worked as it should because the data has time to settle before the next rising edge comes along and the SRAM tries to read it. What must have happened was that the capacitance of the scope probe was enough to slow the rising edge of the clock down just enough for the data to have settled, the breadboard must have done the same thing but not quite as well which probably explains the distortion. No idea why the 23K256 works fine with the same incorrect settings, there's no obvious difference I can see in the data sheets.

Here's a demo with 8 seconds delay. Starts with the delay set a 2 seconds, then switches to 4 and finally 8, then I loop it and finally play the loop in reverse. The hiss in the clip is from my camera not the pedal. Apologies for the fret wankery I got a bit carried away.

[deadastronaut]

 @#$%ing @#$%ing @#$% @#$%ing @#$% ...man i @#$%ing want/need one of those!!!!!!!!..or even 2..

totally epic work man!!!!!! UBER COOL.

could it have a time indicator..like a countdown or something to tell you when the max loop is near/end type thing?..

what size box is that?..

[slacker]

Cheers Rob thought you'd like it. It still needs work, it's probably too noisy for general use, it's OK at bedroom levels but at gig levels it adds a noticeable amount of hiss and noise but it's proved the concept and given me something to try ideas out with.

I like the idea of a time indicator, you could use the LEDs as some sort of indicator maybe have one light up as you get near the end, or have it flash and make the speed increase as you get near the end.

The box is a 1590XX, the same size as the big EHX pedals.

[deadastronaut]

yeah man love it, something really cool to look forward to for sure..

a delay time indicator would be useful too... me and my led addiction eh......

[slacker]

Tap tempo delay and flashing LED is doable. If I switched to a bigger PIC I could go the whole hog and fit an LCD screen that could do all sorts of cool stuff, that would mean going to SMD though, not sure I fancy that for now.

[deadastronaut]

excellent,

yeah smd is off my list, my eyes are too buggered ...

[SISKO]

Whether they are fast enough will again depend on how fast your sample rate is and how fast you can run the SPI clock. I'm using a 10MHz SPI clock and to read or write a sample takes about 6uS for the 23K256.

Slacker, how do know how much time it takes to write the RAM?
Sorry for the bump!

[slacker]

I can't remember exactly how but I measured it, the code sets the chip select pin low at the start of the read/write sequence and high again at the end so I probably just measured that with my scope. Most of the time it takes is the actual communication between the PIC and the SRAM, with a 10Mhz SPI clock each bit takes 100ns so each byte takes 800ns, reading/writing a 16 bit value takes 5 bytes, one byte to set read or write mode + two address bytes + two data bytes so that's 5 x 800ns = 4us. That's the real limiting factor, which you can only get round by increasing the SPI clock speed.

[ElectricDruid]

Hey, snap! While you've been busy with this, I've been working on something virtually identical:

http://electricdruid.net/diy-digital-delay/

Same idea - dsPIC with serial SRAM, for the same reasons (handy DIP format for prototyping). The major difference is I was using the 33FJ64GP802, since it's one of the two chips that includes a 16-bit DAC for the audio output. That makes life a bit easier. I suppose the other difference is I used ASM not C. Otherwise, pretty similar - I've also got a 32KHz sample rate - as you say, convenient. I had similar problems with getting the SRAMs running, needing to put pull-ups on the correct lines. I've been playing with delays, and have added high and low shelving tone filters which give a nice effect with the long delays. Currently I'm struggling with working out how best to make the delay time smoothly variable, since I'd like to add an expression input for that.

It's very interesting to see how someone else has approached something you've worked on yourself. Thanks for sharing, Ian.

Tom

[slacker]

Great minds etc... That looks very interesting look forward to hearing it in action, like you say the audio quality is plenty good enough for delay based effects. Be very cool if you end up selling programmed chips for it as you'd have a delay people could just build but those who wanted to could develop their own firmware for it, might get more people into DSP.
I'd be interested to see what you come up with regarding getting smooth variable delays, that's something I haven't figured out yet either, Cloudscapes did a similar project and he seemed to have it cracked, I'll see if i can find a link to it.
I was going to try one of the chips with the built in DACs, not sure why I didn't in the first place but instead I redid the whole thing using a WM8510 audio codec, this gives you 24 bit audio at up to 48Khz, although I'm still using 16 bit at 32Khz. The sound quality is much better but it does mean at least some SMD is involved.
I need to get round to posting it here.

[cloudscapes]

For smooth variable delay, I had the entire delay line and sample address counter in a timer, and elsewhere had potentiometer adc input control the timer's reset. it was pretty smooth. I'd range it from something like 6khz to 72khz (from memory, so I may be off a little).

input pots I'd sample only 50 times a second or so, including thje delay time pot. you don't need to waste cycles for something as slow as a human hand turning a pot. but where I'd update the timer period register was in the timer interrupt's routine. same place I put all the audio-rate stuff, like cycling memory address, using the dac and adc, etc. I found that if I updated the period register at a slower rate (like at the same rate as sampling input pots) I''d get occasional audible glitches and pops where it would drop a few samples. I think it was when it would update the period register to a value much lower than the counter was currently at. something like that.

[ElectricDruid]

For smooth variable delay, I had the entire delay line and sample address counter in a timer, and elsewhere had potentiometer adc input control the timer's reset. it was pretty smooth. I'd range it from something like 6khz to 72khz (from memory, so I may be off a little).

input pots I'd sample only 50 times a second or so, including thje delay time pot. you don't need to waste cycles for something as slow as a human hand turning a pot. but where I'd update the timer period register was in the timer interrupt's routine. same place I put all the audio-rate stuff, like cycling memory address, using the dac and adc, etc. I found that if I updated the period register at a slower rate (like at the same rate as sampling input pots) I''d get occasional audible glitches and pops where it would drop a few samples. I think it was when it would update the period register to a value much lower than the counter was currently at. something like that.

Ok, so you went with a variable sample rate scheme. I can see the advantages!

Currently my code works the other way - a write pointer and a read pointer chasing each other around a circular buffer (the whole RAM). Changing the size of the gap between the pointers alters the delay time. The sample rate stays the same. This has the advantage that I've always got the same bandwidth, so no crunchiness at longer delaytimes, and no audible aliasing creeping in. The disadvantage is that that if you jump the read pointer to a new location, you get a glitch. Your variable sample method is guaranteed to read out every sample - my way isn't. The only way round that is to either crossfade between the old location and the new, or to "speed up" the read pointer so it (say) starts to catch up the write pointer. Since this is a fixed sample rate, that means doing some interpolation to find samples in-between samples, and if you push it too far, you get weird artefacts, but if you don't, it takes ages to change delay time. I'm not sure what to do for the best.

I've been doing a few other things while I mull it over, hoping that inspiration might strike if I put the project down for a bit, but so far, no luck.

Tom

[cloudscapes]

I can upload my program for the delay I wrote later today, it's in C and used in a PIC32. It's a bit messy and has a lot of extra features (like reverse delay) you don't need but maybe it'll provide a tiny bit of help. This is my build log, with the finished delay at the last couple pages of the thread.

I haven't messed with interpolation at audio rates since I'm bad at that stuff. Did do a bit of cross fading.

http://www.diystompboxes.com/smfforum/index.php?topic=109314.0

Personal opinion, I think fixed bandwidths/samplerates in a delay is a bit unnecessary. You would need more aggressive filtering obviously if you're doing variable, but, shrug. It might come down to personal taste, but I don't mind that it gets a little crunchy at the low end of the bandwidth in a variable delay. Nostalga trip to 80s/90s digidelays where everything ran on a variable master clock before SHARC dsps took over.

If you want to stick with a fixed bandwidth/samplerate, you might be able to avoid the glitch by having the program keep track of areas of memory that are "unsafe to read", until new audio data is written to it. An interesting detail on how older digidelays switched over to longer delay ranges (kind of what you're doing, increasing the memory size for longer delay). If I switch my PDS8000 from a short delay range to a long delay range, it "switches modes" for a couple seconds where there is absolute silence. I think it goes through the entire memory once over in silence to avoid glitches.