DIY looper/sampler chronicles

[cloudscapes]

For speeding up and slowing down the loops, I think I'm gonna give software interpolation a try.

Normally, I would just clock a timer interrupt at 44khz, and then up or down-clock it to get speed/pitch warping. It's easy to implement, but has a few downsides:

1. Requires steep filtering at whatever is the nyquist of the current sampling rate.
2. Can only go so fast. If I up-clock it to 100khz or so, it doesn't leave me many clock cycles to do my magic.

With software interpolation, my ADC and DAC can be at a fixed 44khz samplerate (or more, if I can afford it) and set up a "virtual" sample number. Instead of counting from 1 to 100,000 samples in intervals of 1, I can have sample #1.3, #204.8, #16,028.4. A pot would control the incrementation in floating point instead of integers, and increment +0.3 per ADC/DAC cycle rather than just +1. A simple algorythm will be used to take that decimal and do linear interpolation between the sample # without decimal, and the next sample. This has a few advantages:

1. No filtering needed, except the most rudimentary.
2. No longer cycle-limited at whatever the max speed-up would have been. More room to do magic.

I spent a few hours last night over graph paper charting out virtual samples and interpolation at various speed-ups and slow-downs.  I'm not great at math so having visual aid really helps me. What I found ios this should work just fine when slowing down a loop (sample increment <= 1). But when I'd slow down my on-paper virtual loop, I'd get aliasing at really high frequencies. Say 15khz and up, just at the limits of hearing. To know really how bad it is, I guess I'm just gonna have to code a test and find out first-hand.

[cloudscapes]

So I wrote some linear interpolation between samples when I slow the loop down under 44khz. It worked okay. I didn't do it for when it's being sped up, no real point. In doing so, I did it so that regardless what speed the loop is being recorded or played back, the internal timing will always be 44khz! That means I'm no longer limited by how fast I can clock it if I want to speed things up!

I've also made the decision that I won't be using linear interpolation.  Nor an automatic analog filter that scales with the samplerate. I've come to realize that this type of looper will appeal to those of us who really like the bitcrush/low samplerate effect! Oh there will be an analog filter all right, but it'll be independant, so that you can optionally dial it in if you want it.

I've also decided that I think I want to implement undo/redo. Code-wise, it's not too difficult. Once I've finished recording a loop, the program can look at what's the available remaining memory, and if I'm using half or less, I can swap between areas of memory each time something is overdubbed. Undo will swap backwards.

I'll need a lot of memory, though. So far I'm reconsidering parallel SRAM chips instead of the serial MRAM I wrote about on first page. Having a lot of trouble finding SRAM (non-dynamic) with capacities more than 8mb, so I know I'll need at least 2 of them.

[alparent]

I'll need a lot of memory, though. So far I'm reconsidering parallel SRAM chips instead of the serial MRAM I wrote about on first page. Having a lot of trouble finding SRAM (non-dynamic) with capacities more than 8mb, so I know I'll need at least 2 of them.

OK, I know nothing about this subject (All I can do in the digital world right now is do basic stuff on my Arduino).......but I'm following 'cause it's very interesting.

But what about using a micro SD card? To slow? Or laptop/computer memory?

Feel free to educate me or just ignore.  

[cloudscapes]

OK, I know nothing about this subject (All I can do in the digital world right now is do basic stuff on my Arduino).......but I'm following 'cause it's very interesting.

But what about using a micro SD card? To slow? Or laptop/computer memory?

Feel free to educate me or just ignore.  

Don't worry, I like to run my mouth with little tidbits of info.

An SD card is often a good solution to interface samplers and loopers to. They're easy to interface (via SPI) and the speed is fine, also. My concern is that they have limited write cycles, being flash based memory. A few hundred thousand writes I would guestimate. This is fine for most things, but for the looper I have in mind, I have to take into account the possibility that I (or someone using it) sets the loop time REAL low, a few tens of milliseconds, then hits "overdub". It'll overwrite that section of memory a thousand times in a couple seconds, burning a percent of that section of the SD card. Leave it on for a minute, and.. you get the idea. Too much potential to waste the card very quickly. There are also ICs which work the same was as SD cards, so you don't have to deal with actually mounting the card at all if you don't need to replace it.

Older computer memory could be interfaced, and even the individual chips are cheap (a few bucks each) and have a fairly decent capacity. I saw some the other day on digikey, 128mb for a couple dollars. Good for a couple minutes of recording time! They are SDRAM (or DRAM). The D stands for Dynamic, which means that the memory has to be REwritten to hundreds of times a second even if you aren't writing anything new. Like refreshing its memory. It can be done, but the PIC32s I'm using won't do it automatically (I"d have to write my own drivers) so I just don't want to deal with that right now.

SRAM is the best option for me. It's Static ram, meaning it keeps its memory without the microcontroller's help, and it's fast. Problem is it's really hard to track down in capacities greater than 8meg, under 12 seconds of recording time. Double the capacity need if I want undo (which I think I do). They're also quite large (the 8meg ones anyway).

[alparent]

Thanks for the lesson!
It's always good to to hang around smart people.

[Bluexav]

Is it a dead project ?

[cloudscapes]

Is it a dead project ?

no, just on hold. I worked on a sampler/glitcher pedal in the meantime to get a better grasp of the tools I wanted to use, plus just general life getting in the way. I'm stuck because of two things, mainly:

- codec. I can use an external ADC and DAC just fine, but the ADC is only 12bit. using a 16bit ADC or codec involves digital communication that I'm just not smart enough to do (and I've tried, so hard). I'm close, but it's just not working the way it should.

- RAM. for the quantity I need for this to be worthwhile, either it's dirt cheap but involves tricky coms and timing that I can't wrap my brain around (SDRAM/DRAM)....... or it's really easy to interface, but is super expensive, over $60 for one chip, or that amount in many chips (MRAM, SRAM). Or, it's cheap AND easy to interface (PSDRAM, pseudo DRAM with SRAM interface) but is only available in 0.75mm pitch BGA package which even OSH Park can't handle (needed via and trace size is too small). I haven't decided whether I want to go the rediculously expensive but easy-ish route, or cheap but this-is-way-too-advanced-for-me route.

I could start this looper with 12bit ADCs and only 10-20 seconds loop time RIGHT AWAY, but.... ehhhhhh.....  

[potul]

Don't worry, I like to run my mouth with little tidbits of info.

An SD card is often a good solution to interface samplers and loopers to. They're easy to interface (via SPI) and the speed is fine, also. My concern is that they have limited write cycles, being flash based memory. A few hundred thousand writes I would guestimate. This is fine for most things, but for the looper I have in mind, I have to take into account the possibility that I (or someone using it) sets the loop time REAL low, a few tens of milliseconds, then hits "overdub". It'll overwrite that section of memory a thousand times in a couple seconds, burning a percent of that section of the SD card. Leave it on for a minute, and.. you get the idea. Too much potential to waste the card very quickly. There are also ICs which work the same was as SD cards, so you don't have to deal with actually mounting the card at all if you don't need to replace it.

If I'm not mistaken, SDcards have some intelligence integrated that will balance this. So, even if you write always to the same address, the card will re-map this to a different physical sector of the memory.

[cloudscapes]

If I'm not mistaken, SDcards have some intelligence integrated that will balance this. So, even if you write always to the same address, the card will re-map this to a different physical sector of the memory.

This is true, however it remaps it to a small reserved section of memory that's not part of the main accessible memory. It doesn't really solve my "problem" because in cases where sectors start dying because I've got overdub on all the time, it would be whole huge sections, way more than the few Mb's that are in reserve on the sd card.

However... all this made me have an idea! It might be that it was already suggested in the thread and I didn't get it at the time over a year ago, or not, I cant remember, but now I think it's the best bet.

Memory would be separated into two kinds of chips:

-Small capacity SRAM but with unlimited endurance, like the MR25H40
-Large capacity flash with limited endurance, like 64Mb microchip flash, 100,000 rewrites, or better, micron phase change memory, 128Mb, 1,000,000 rewrites

Whenever in record/overdub/write modes, I'd have the looper decide which memory chip to use. If the loop (or cropped section of loop) is being recorded/overdubbed, I'd use the small capacity SRAM with unlimited endurance, such as the MR25H40 I've been trying out, 4Mb, good for a little over 5 seconds of audio at 16bit 48khz. I can do a million overdubs on that small bit of memory without issues. If I "uncrop" the loop, extend the loop (or just re-record a larger loop), greater than 5 seconds, I'll have the looper seamlessly shift the data into the limited endurance high-capacity flash memory, all in the background. It would take months of continuous overdubbing if my loop is over 5 seconds long to burn through flash memory, so no real issue.

The real challenge is having the looper switch between the two types of memory based on whatever amount of audio is "active" at any given moment, then moving to the different memory without interupting audio.

[Perrow]

Write the first five seconds of any given loop to the high endurance memory,  I think that might be all the logic you need. But then I haven't given it as much thought as you have.

[cloudscapes]

Write the first five seconds of any given loop to the high endurance memory,  I think that might be all the logic you need. But then I haven't given it as much thought as you have.

Thanks, still! Sometimes you get so into the details that you forget to look at the obvious. Still, this can't work if I'm to have some of the features I want. One of which is loop cropping/trimming.

Say I record only the first 5 seconds into high endurance, and the rest in low endurance. Hypothetically I record a 10 second loop. That's cool, but then I trim the audible loop (part I'm hearing) down to a few seconds, between sec 4 and sec 7. It's a shorter loop, just a portion of the original, but the original is still in memory and can be accessed by "untrimming" the loop. So if I go full overdub between seconds 4-7 (total 3), the first 1 will be high endurance but the last 2 won't be, and I'll burn through those last 2 seconds.

That's why I gotta do something adaptive and "intelligent" which is always paging audio between the two kinds of memory in the background depending on what I have trimmed.