I thought I'd try something. For years I've wanted to build my dream looper. When I first started DIY stompboxes and noise-generators 6-ish years ago, I never in my right mind would I have guessed I'd be doing projects at the complexity I am now! And original ones at that! But still, these last few years, I've been gearing up (mentally) to tackle something huge (to my eyes). Looping is not only an important part of my music, but the ability to manipulate loops on the fly as well. I've tried many loopers. While many were excellent, they all lacked something another had that I thought was fantastic! So here I am now, thinking about how to combine those very best features and add a few of my own.
And I thought I'd start a thread about it, and log it as I make progress. :) Complete with a pretentious thread title!
I've only just started, and there will be many firsts for me in this project as well, so I'll try and keep it informative. How I made certain decisions and not others.There isn't a whole lot of information out there when it comes to non-ISD based loopers. Maybe this thread will contribute in some tiny bit. A reference of things that come up for such a project, to others. A mixture of technical and laypersons theory, and I will try and keep the theory to a maximum! But mostly, it will be a curiosity! It will also be a learning experience. I don't claim to be an expert, and I will make mistakes and errors in judgment. I'm learning as I go along with this ambitious project.
So really, what do I want?
- Hi-fi. 16bit 44khz is my goal.
- Variable fidelity/sampling rate for stepless time/pitch effects.
- Overdub with variable feedback. No question.
- Resonant LP / HP filter, and an automatic antialiasing filter
- Complete mixer to be able to mix from selectable inputs
- Same-pitch time stretching
- Automatic & manual "scrubbing" (http://wiki.answers.com/Q/What_is_audio_scrubbing)
- Ping-pong scrubbing, or "freeze" effects
- Reverse
- Loop cropping / trimming. Defining start-end loop points in realtime.
- Modulation
- Clickless seams
Will not do / not smart enough to do:
- Undo
- SD card storage
- Multitrack or stereo
- BPM or time-sensitive quantization
What have I done so far:
A simple breadboarded setup that can pass 12bit audio at around 100khz! ;D It doesn't do anything but pass audio, no recording or feature whatsoever. Just raw analog-to-digital conversion and back again. I'm concentrating on getting simple audio right before I do any sort of recording, playback, logic or feature.
What I'm using so far:
I've started using MikroC, which is a C compiler for various microcontrollers. This is a very big step for me. Up 'till now, I had been using 8-bit AVRs and Bascom. While great for LFOs, presets and automation, they simply don't have the horsepower to do anything but telephone-quality audio. I've experimented quite a bit with audio on them, but I don't know assembly, so wasn't hitting good samplerates. What I made were fun little glitchy noise boxes that sample and loop, but in no way were they going to satisfy my looping needs. Bascom (basic) only supports AVRs, so I need to learn a new environment, and while I'm at it, language. A common language like C opens up future possibilities for other platforms as well, unlike Basic. So now, I learn. I'm still very much at the beginning of the language fundamentals of C.
Another new thing for me will be heavy use of surfacemount packages. I've done a few before, but with AVRs and most pedal builds, it wasn't really needed. With high-speed audio and data, it will be needed, and often in tiny pitch (0.5mm). I'm considering buying a cheap stereo microscope to aid me in this and other projects.
(http://nearworlds.org/stuff/pass_audio.jpg)
CPU:
A PIC32 board from Mikroelectronica. A little expensive but it's in an easy to use footprint on a DIP40 stamp and packs a punch! The chip on it is 32bit and clocks at 80MHz.
Digital-to-analog:
A PT8211 16bit DAC. Same company who make our beloved 2399 delay ic! Easily found for cheap (2 bucks a chip on ebay) and in an easy to use package (DIP8 or SOIC8), and specced to deliver better than CD-quality sound. I've tested it, it sounds good, it's cheap, it's fast, it works, I'm set!
Analog-to-digital:
Currently an MCP3201. It's easy to find and cheap, but is "only" 12bit and is quite slow. I can get decent samplerates with it, but data/SPI transfer isn't fast at all, so it doesn't leave the CPU much free time to do logic. I'm using it at the moment because I know it and I had some at hand. Must find something else. I've orded a couple LTC1864 which is, according to the datasheet, an extremely fast 16bit ADC in a nice SOIC8 package! Pretty expensive though, at $14 each. According to how hard my PIC32 is currently chugging, and if my math is right, I will be able to get 200khz sampling speeds at 16bit, just raw audio pass-through! That should leave my PIC32 with tons of time to perform logic and whatnot if I'm aiming for 44khz!
RAM:
This was the hard one. I've made some calculations. How much looping time do I want? Well, 10 seconds is a nice round number! Lessee..
- 1 sample at 16bit uses up two bytes.
- At 44khz, 44000-ish samples per second, one second uses up 88000 bytes, or 88KB.
- 10 seconds needs 880KB, or 1MB if we're rounding up for easy findability.
I've used Microchips 23k256 RAM ics a few times. They are in nice DIP8 packages, use fast and easy SPI communication, but they are only 32KB. Forget it. So I hop onto Mouser and Digikey to see what my RAM options are. This takes several days of reading datasheets and measuring options, actually. I have to filter out anythign that comes in BGA. So, a few kinds of RAM:
- FRAM. SPI communication, fast, easy package, but still small storage quantity
at 128KB and costs a leg at $28 for that little amount. Scratch that.
- Parallel RAM. Cheap-ish, common, easy to understand, VERY fast as its parallel
instead of serial com, but uses a ton of pins. 8 data pins + 20 address pins + 2-3
extra. I need over 30 free pins on my CPU! If I was using a large PIC32, I could do that,
but I'm not. I'm using a 64-pin micro on a 40-pin stamp, and not all of those 40 pins are
the right "kind". Also, I don't want the headache of routing the PCB for all those traces.
Still... parallel RAM is the de facto standard when it comes to consumer audio looping
and sampling at high-speed. Better order a couple, in case.
- Flash memory. Cheap, easy to use, nice packages, but a little slow, and limited write
cycles. 100,000 or so. If I'd be using this as a traditional looper, that might be enough,
but I have to plan for the time where I set the loop-trimming to 5 milliseconds and hit
record. There, I just burnt through 10% of the chips available rewrites in a second! ;D
Scratch that.
- MRAM. Specifically MR25H40. Hmm... doesn't seem to be a common type of memory.
But oooOOOHH! Look at these specs! Lightning-fast SPI com, zero read/write time, infinite
rewrites, and available as a 512KB! $14 is a bit pricey, but I'm willing to spend that much
if I only have to use one or two of them in the project! But... wait.... ohhhh
effffffffffffffffffffffffffffffff..................................
DFN package. That's nearly as bad as BGA.It's like... THERE ARE NO PINS! The pins are tiny little exposed metal UNDER the 8-pin square. Anyways, I order a couple, ball a bit of solder directly on the "pads", tin a SOIC-to-DIP adapter's pads (same footprint), and melt the balled-DFN onto the tinned adapter. It seems to have worked. Okay, I can do this. The specs make it worth it! Oooohh, data retention under no power even!
Speed test:
I have the digital oscilloscope (a cheap 25mhz Owon) hooked up to the circuit. The red lines represent the SPI clock hooked up to the slow 12bit ADC. The yellow lines are the clock on the fast DAC and MRAM. The green line I added represents a single sample. It represents an elapsed time of almost 30us. That's 30 millionths of a second! That's a short amount of time to us humans, but to a 32bit 80MHz microcontroller, a lot can be done in that amount of time. Here is how many millionths of a second my PIC32 hs to work with for each sample:
- 44khz = 23us per sample
- 33khz = 30us per sample
- 22khz = 45us per sample
Considering that, at the time I took this picture, I guess it was sampling at about 35khz, which in all honesty to my ears, sounds mostly fine.
(http://nearworlds.org/stuff/ada_oscilloscope.jpg)
The two large red blocks represent 8 clock pulses (for a total of 16, which is what the ADC needs to sample a single 12bits). They're just tight together which is why they look like one single huge pulse. The yellow represent the SPI clock hooked up to the much much faster 16bit DAC and MRAM ic! All 8 of the yellow lines have 8 little clock pulses of their own. Just so much more tightly together they appear as a single line! The first two of those blocks (16 pulses) are for the fast 16bit DAC, and the other 6 (48 pulses) for the MRAM.Once I get my new fast ADC, those two large red blocks will shrink to the size of the tiny yellow ones, and the PIC32 will have much more free time for logic/features, and/or will be able to achieve even higher samplerates!
I can measure how long it takes to read or write to the MRAM, about 4us, how long it takes to output to the DAC, 2us, and how long it currently takes to sample from the ADC, 8us.
It's half past midnight so I'll stop now. In a day or three, I'll write about why I chose to use a seperate ADC and DAC rather than use an audio codec chip, which is what's comonly used. Also, what I've learned about antialias filtering! Also, I'll fill in some links to stuff.
Subscribed. Put me down on the pre-order list... ;)
Testing new parts:
As I've said, this project has a lot of new things for me! New kinds of fast parts, a new language and environment, a brand new type of microcontroller. I didn't just plug new parts together and hoped I could get it working! ;)
I know AVRs (8bit micros) fairly well, so when I purchased the new MRAM and 16bit DAC, I hooked those up to the AVR instead to see if I knew how to use them, figure out the routines, data order, control bits, etc. It made debugging and discovering a new part FAR easier. There were issues, but I could remove the AVR from the equation because I knew how to use these. Once I had a set of rules on how to use my new ics, I could move on to the new language and PIC32 and "translate" those rules. The AVR is far far too slow for decent audio.
Sounds really cool. Good luck!
This looks really great!
This is possibly the start of the greatest thread in diystompbox history, look forward to seeing where it goes.
Quote from: slacker on March 15, 2012, 01:57:26 PM
This is possibly the start of the greatest thread in diystompbox history, look forward to seeing where it goes.
Apparently you have forgotten about this thread http://www.diystompboxes.com/smfforum/index.php?topic=76932.0 (http://www.diystompboxes.com/smfforum/index.php?topic=76932.0) :D
Seriously, I've been wanting a looper diy for a while, but my programming skills are rudimentary at best.
That thread is gold. :icon_biggrin:
Inspiration:
Looping is my main part of my solo sets. I use loopers as instruments if at all possible, and not just as stomp-and-forget boxes. I've used so many, and sold them after a while. I did keep four of them, though! And they're kind of my main inspiration for this project, feature-wise.
- Timefactor. Awesome looper! Has loop cropping/trimming and is pretty flexible! Wish they would of gone the extra mile with the crazy features, though!
- Stereo Memory Man / Hazarai. My simple workhorse looper when I don't need something complex. I like the filter on it and how fast one can lay down a loop.
- 2880. Not too many crazy features, but the UI design is something I admire! I think I prefer the tabletop format. I wish I could make mine multitrack, but for the moment, best focus on a single track.
- PDS-8000. Just love it!
Separate ADC / DAC vs codec IC:
I think a standard for these types of applications is a dedacated codec IC which incorporates ADC/DAC as well as audio-optimized filtering and stuff. I know my 2880 uses one of the Texas Instrument ones, maybe the PCM3001 (from memory), and I've seen them in a lot of other products where audio quality was important. They're an "all-in-one" audio solution to be connected to a microcontroller or CPU, which only handles the thinking. They're generally not too expensive, and have a lot of built-in audio features that normally I'd need a lot of external components for, but I chose not to go this route for one reason. They also all require a secondary clock that's hundreds of times higher frequency than the SPI/data transfer clock.
An SPI clock is a clock signal that drives the "engine" of a part to deliver or recieve data in that specific timing. This can be a variable speed, but is usually multiples of two. Some parts can send/recieve data to and from the PIC32 very quickly, while others require a slower clock running parallel to the data stream. Codecs are a bit more difficult, as they require a secondary clock that's exactly 256 or 512 times the samplerate (well into the MHz), and it has to be in sync with the SPI clock at all times! The SPI clock has to scale along with the samplerate, and that I simply can't do. I've read about it, and it's way way over my head. There are strict rules in place when it comes to codec timing and control. Maybe someday I will get familiar enough with this language and environment that I'll be able to use a codec, but at the moment, I'd rather find another way. Separate ADC and DAC it is. They are much "looser" in terms of these kinds of things, and are operated simply by SPI which I know pretty well. No additional clock required. No strict scaling of the SPI clock relative to the samplerate.
Using an ADC/DAC combo over a codec however brigns on another challenge. Antialias filtering. A codec IC wwhen properly controlled will filter the sample "stepping" in digital audio and will adjust the filter according to your samplerate. This is very helpful to have in a single chip! But since I'm going to be using an ADC/DAC combo, I'll have to devise external fitlering to get rid of the jaggies, and I'll need to sweep the filter when I tune the loop down to a slower speed. I'll probably end up using a MAX7404 ic which is a filter-on-a-chip controllable by either capacitor or clock input. If I use a clock, it won't have to be scaled perfectly with the SPI clock or samplerate. I can just wing it, use my ear. Much easier! More on that AA filter some other time.
Using an ADC/DAC combo vs a codec is moves much of the work involved from programming in the new environment (not my strength), over to external components and "winging it". Fine with me!
Display:
I'm gonna need some sort of visual feedback, though I haven't figured out what I want yet. An LCD would be nice, but I don't yet know how to cut squares in metal.
I think that we are on the same page as far as loopers go, as a matter of fact last night I did a looping based song for a compilation of music recorded on cell phones.
My favorites are:
Boomerang+ (the III is nicer, but I have a wife, therefore I can no longer buy expensive things) because it is just laid out so well for live looping.
EHX 16 Second Delay because of the sweet glitch stuff you can do with it
Digitech RDS-900, my first looper, I love it most likely for all the same reasons you love your PDS
This is pretty relevant:
http://www.youtube.com/watch?v=TRflDaVqfuQ
It's a looper I built a year and some months ago, but it is very very lo-fi and unreliable. It could use some extra features too. I guess what I want to build now is what this should have been, but couldn't be.
I still haven't recieved my new 16bit ADCs yet, but I may still work on this on the weekend. maybe try and get a timer running on the PIC32 for a variable samplerate. at the moment I set the samplerate just with a wait state. maybe try and get a
(samplerate*100) clock output going at the same time, which is what those filter chips described earlier need to clean up the sound.
Quote from: wavley on March 16, 2012, 09:19:51 AM
I think that we are on the same page as far as loopers go, as a matter of fact last night I did a looping based song for a compilation of music recorded on cell phones.
My favorites are:
Boomerang+ (the III is nicer, but I have a wife, therefore I can no longer buy expensive things) because it is just laid out so well for live looping.
EHX 16 Second Delay because of the sweet glitch stuff you can do with it
Digitech RDS-900, my first looper, I love it most likely for all the same reasons you love your PDS
I actually have the rang III ! I'll probably sell it though. it's mostly great, but a couple things keep me from using it. 1. I don't like the interface. I like to have buttons for each feature if possible, not have to assign buttons with the dial. and 2. you can't change the speed of the loop except by half. it has some other great features going for it, though! the free play mode, for instance!
I have never had the pleasure of using the 16 sec delay! one day, maybe, one day.....
i would encourage another look at codec chips
there are some that are easy to work with
i have used the wolfson wm8731 a fair bit
and made a sampler out of it
http://www.openmusiclabs.com/projects/microdec/
mikroelektronika uses it as well in their codec breakout board
http://www.mikroe.com/eng/products/view/484/audio-codec-board-proto/
the antialiasing filters that are built in are way better than anything i could make
and it frees up a fair bit of data passing time for more processing time
i see your point about wanting to simply modify the codec clock to get different playback speeds
but this could also be done with interpolation
although that has a completely different sound
i havent tried this
but i think you can vary the codec clock pretty easily
even though it is up 16MHz or whatever
and the wm8731 doesnt require the spi transfer
to be a submultiple of the codec clock
Quote from: g_u_e_s_t on March 17, 2012, 04:12:37 AM
i would encourage another look at codec chips
there are some that are easy to work with
i have used the wolfson wm8731 a fair bit
and made a sampler out of it
http://www.openmusiclabs.com/projects/microdec/
mikroelektronika uses it as well in their codec breakout board
http://www.mikroe.com/eng/products/view/484/audio-codec-board-proto/
the antialiasing filters that are built in are way better than anything i could make
and it frees up a fair bit of data passing time for more processing time
i see your point about wanting to simply modify the codec clock to get different playback speeds
but this could also be done with interpolation
although that has a completely different sound
i havent tried this
but i think you can vary the codec clock pretty easily
even though it is up 16MHz or whatever
and the wm8731 doesnt require the spi transfer
to be a submultiple of the codec clock
I don't know, I've read the datasheet and it's one of the more complex codec chips I've come accross. there are a whole bunch of registers to set. a little overwhelming. and I avoided that ic specifically as well because mikroelectronica have been promising samples for their WM8731 board since summer of 2010. it's kind of a joke on their forums now.
"soon" they'd keep saying, and occasionally the
"writing a library turned out to be more complicated than we thought" kind of says to me that if mikroelectronica are having trouble doing it after a year and a half, then there's no way I'd be able. I'm just learning this platform, as well as this language, and if I can get an ADC and DAC to sound good, then it's good enough to me. I appreciate the advice, though!
the filter ic I have in mind is the MAX7404, which is built for exactly such purposes.
I'll not outright dismiss the possibility just yet, but I've already poured through my compiler's help. I don't know yet how to output a multi-MHz clock using their compiler, and I didn't get any answer on their forum.
yes there are a lot of registers to set
but i have documented them and have stuff written for it
so that could make it easier
i didnt know about the problems with mikroelecktronika
i saw that mouser says they have them in stock
http://www.mouser.com/ProductDetail/mikroElektronika/MIKROE-506/?qs=sGAEpiMZZMuNcqZxhMNT33vXtqfzWVVK
i also made a wm8731 breakout
http://www.openmusiclabs.com/projects/codec-shield/
its more of an arduino shield
but can be used as a breakout
but it looks like you have a good path chosen
im not certain the best method of sending a different clock to the codec
if the clock is generated from a microcontroller
then it will not have a fine granularity
unless there is a PLL onboard or something
so maybe an external analog oscillator would work
it isnt digitally settable but is easy to make
im getting quite curious about externally clocking this chip now
perhaps a 4046 PLL would do the trick
if i prototype something up i will report back
Lets say I get my PIC32 to supply an external codec clock.
The max frequencies I can get with a timer on the mikro is 1.6MHz (tested it this morning). And without a timer, just a pin toggle in a loop, about double that. It's still not enough for a codec, they needs several MHz at least.
I'll look up the 4046 datasheet. I haven't done much discreet logic (just the odd schmitt trig or binary counter).
what sort of frequency range were you thinking of using with your current setup
if the fastest the mikroc can go is 1.6MHz
then there might be a granularity issue already at 100khz sample rate
also
are you planning on having your anti aliasing filter change with sample rate
i noticed the top speed of the MAX7404 is only 10kHz
it can be overclocked but then it gets noisey
Quote from: g_u_e_s_t on March 17, 2012, 04:28:00 PM
what sort of frequency range were you thinking of using with your current setup
if the fastest the mikroc can go is 1.6MHz
then there might be a granularity issue already at 100khz sample rate
also
are you planning on having your anti aliasing filter change with sample rate
i noticed the top speed of the MAX7404 is only 10kHz
it can be overclocked but then it gets noisey
yeah I may eventually get a different MAX ic with a higher freq cuttoff.
basically, I want the filter to change with the samplerate. lets say I find a MAX ic with a higher cuttoff. if I'm sampling at 44khz tops, then the MAX ic requires a clock input of (frequency*100), so a clock input of 4.4MHz.
as for the lower frequency, I want well below 6khz.
I've used the MAX6404 before, but with an input cap and a pot to ground. I had an AVR drive a vactrol between the timing cap and ground for control of the MAX chip. even specced at 10KHz tops, I still got a filter sweep that was adequate for me. I'll have to experiment further. if not the MAX ic, then some other PWM-controlled filter.
say I use a codec ic. they require a clock that's 256 or 512 that of the sameplrate. and since I want a continuously variable samplerate, it must be supplied by the mikro. 44khz * 250 is 11.264MHz, which is impossible for my PIC32. unless I use a PLL (havent played around with those yet) or an external clock generator.
I have options. right now I'm leaning towards voltage controlling a MAX filter or some other kind of filter. the filter sweep doesn't have to be totally accurate or linear. just "good to the ear".
Quote from: cloudscapes on March 17, 2012, 02:46:56 PM
The max frequencies I can get with a timer on the mikro is 1.6MHz (tested it this morning). And without a timer, just a pin toggle in a loop, about double that. It's still not enough for a codec, they needs several MHz at least.
http://ww1.microchip.com/downloads/en/DeviceDoc/61106G.pdf
page 6
23.1.3 Audio Protocol Interface Mode PIC 32 family has already a codec interface built in, it's the SPI working in I2S mode. Since, according to the Table 1:
http://ww1.microchip.com/downloads/en/devicedoc/61168b.pdf -page 2
all the PIC32 family chips have 2 SPI/I2S modules, you can use one to interface the memory and the 2nd one to communicate with codec.
Quote from: free electron on March 18, 2012, 04:11:45 AM
http://ww1.microchip.com/downloads/en/DeviceDoc/61106G.pdf
page 6
23.1.3 Audio Protocol Interface Mode
PIC 32 family has already a codec interface built in, it's the SPI working in I2S mode. Since, according to the Table 1:
http://ww1.microchip.com/downloads/en/devicedoc/61168b.pdf -page 2
all the PIC32 family chips have 2 SPI/I2S modules, you can use one to interface the memory and the 2nd one to communicate with codec.
Yeah I have a couple of those MX2's. Unfortunatelly they'e half the speed of the one I'm currently using, which doesn't have an I2S protocol. :( I don't have anything to program them with anyway. The one I'm using is a stamp with a USB bootloader already integrated. I'm currently using it because I didn't have to buy an expensive programmer.
Thanks, though!
Ran into another snag. My compiler's on-chip ADC libraries (for pot input) are really slow. I mean
really slow. A single 10bit conversion eats up almost half a millisecond. Even the 10bit ADCs on AVRs are 100 times faster (no exaggeration). According to the mikroelectroncia forums, I will have to write my own library for quickness. My options for pot input are:
1. An external SPI 4-channel ADC. I'd lose a lot of clock cycles.
2. Writing my own custom ADC library in mikroC. Reading about that now.
3. Switch compilers entirely. Wouldnt be the first time I was frusterated by a design decision in this one, but that would mean I wouldnt be able to use these DIP boards anymore.
Quote from: cloudscapes on March 18, 2012, 08:40:16 AM
Yeah I have a couple of those MX2's. Unfortunatelly they'e half the speed of the one I'm currently using, which doesn't have an I2S protocol. :( I don't have anything to program them with anyway. The one I'm using is a stamp with a USB bootloader already integrated. I'm currently using it because I didn't have to buy an expensive programmer.
Thanks, though!
You can program the PIC32 with Pickit2, which is quite cheap, you can build one for yourself, too. I did that recently because i needed a small and quick eeprom burner/logic analyzer.
Quote
Ran into another snag. My compiler's on-chip ADC libraries (for pot input) are really slow. I mean really slow. A single 10bit conversion eats up almost half a millisecond. Even the 10bit ADCs on AVRs are 100 times faster (no exaggeration). According to the mikroelectroncia forums, I will have to write my own library for quickness. My options for pot input are:
1. An external SPI 4-channel ADC. I'd lose a lot of clock cycles.
2. Writing my own custom ADC library in mikroC. Reading about that now.
3. Switch compilers entirely. Wouldnt be the first time I was frusterated by a design decision in this one, but that would mean I wouldnt be able to use these DIP boards anymore.
I am afraid You will have to choose the "2" anyway if you plan to do some serious things and spend time debugging
your code, not the poorly coded libraries.
If you are thinking about switching the compiler, maybe it would be good to switch the hardware, too?
http://www.st.com/internet/evalboard/product/252419.jsp
Take a look at the specs and then at the price - probably cheaper than the mikroc pic32 board.
Quote from: free electron on March 18, 2012, 05:34:15 PM
You can program the PIC32 with Pickit2, which is quite cheap, you can build one for yourself, too. I did that recently because i needed a small and quick eeprom burner/logic analyzer.
I am afraid You will have to choose the "2" anyway if you plan to do some serious things and spend time debugging your code, not the poorly coded libraries.
If you are thinking about switching the compiler, maybe it would be good to switch the hardware, too?
http://www.st.com/internet/evalboard/product/252419.jsp
Take a look at the specs and then at the price - probably cheaper than the mikroc pic32 board.
Pretty cheap! I'm not ready to jump ship to an entirely different architecture, though. ;) Maybe when I've exhausted all options.
I also don't like boards when they have all the peripherals, to be honest. I just wanted the IC and its support circuitry. Having no peripherals helps reduce headaches when you're debugging. Takes them out of the equation.
I'll see what I can do about writing my own custom ADC code before deciding to completely change what I'm doing. I hope you understand. I'm not against starting over. I just want to make sure it's my only option if I do.
there is also the maple for the stm32 series
if youre thinking of jumping ship
http://leaflabs.com/devices/maple/
although if youre familiar with the avrs
you could probably do what you want with one of those
Quote from: g_u_e_s_t on March 18, 2012, 08:42:35 PM
although if youre familiar with the avrs
you could probably do what you want with one of those
the avrs are way too slow for what I've had in mind. I've tried. ;) I hit their limit (have even been overclocking them), which is why I'm learning a new thing.
Quote from: cloudscapes on March 16, 2012, 09:21:49 PM
I still haven't recieved my new 16bit ADCs yet, but I may still work on this on the weekend. maybe try and get a timer running on the PIC32 for a variable samplerate. at the moment I set the samplerate just with a wait state. maybe try and get a (samplerate*100) clock output going at the same time, which is what those filter chips described earlier need to clean up the sound.
Quote from: wavley on March 16, 2012, 09:19:51 AM
I think that we are on the same page as far as loopers go, as a matter of fact last night I did a looping based song for a compilation of music recorded on cell phones.
My favorites are:
Boomerang+ (the III is nicer, but I have a wife, therefore I can no longer buy expensive things) because it is just laid out so well for live looping.
EHX 16 Second Delay because of the sweet glitch stuff you can do with it
Digitech RDS-900, my first looper, I love it most likely for all the same reasons you love your PDS
I actually have the rang III ! I'll probably sell it though. it's mostly great, but a couple things keep me from using it. 1. I don't like the interface. I like to have buttons for each feature if possible, not have to assign buttons with the dial. and 2. you can't change the speed of the loop except by half. it has some other great features going for it, though! the free play mode, for instance!
I have never had the pleasure of using the 16 sec delay! one day, maybe, one day.....
Yeah, that was my complaint about it too, when I first saw it I said "Why are there less footswitches and no roller for the volume, that's the whole reason the rang and rang+ are awesome" Looks like they are trying to fix that with the sidecar, maybe I'll wait for the 4 to come out. It seems strange that you can't change the speed by anything other than a half, the older ones have several different divisions, my only complaint about that is that you have to set the interval in the firmware by holding down a button while powering up, not very good for live.
I'm checking out MPLAB now. See what a different compiler is without necessarily switching hardware. If I can get it to compile for my mikroelectronica board when I might switch.
The interface isn't as sexy, but the library syntax looks a lot better to my eyes. Example, in MPLAB, configuring the ADC might look like this:
#define PARAM1 ADC_MODULE_ON | ADC_FORMAT_INTG | ADC_CLK_AUTO | ADC_AUTO_SAMPLING_ON
#define PARAM2 ADC_VREF_AVDD_AVSS | ADC_OFFSET_CAL_DISABLE | ADC_SCAN_OFF | ADC_SAMPLES_PER_INT_2 | ADC_ALT_BUF_ON | ADC_ALT_INPUT_ON
Since I already have general knowledge of microcontrollers, it's pretty self-explanatory. It's english and uses words! But on mikroC, the same thing might look like this:
AD1PCFG = 0xFF7F
AD1CON1 = 0x0004
AD1CHS= 0x00070000
AD1CSSL = 0
AD1CON3 = 0x0002
AD1CON2 = 0
Huh? Wha? AD1CHSNCYTBDS = 0x04723HYEN6 indeed!
So, what to do:
1. See if I can even get MPLAB and this ICD2 to work on the mikroelectronica board I use.
2. Port my code over.
3. Try ADCs again.
Take a look here, this is the section of the reference manual describing the ADC module:
http://ww1.microchip.com/downloads/en/DeviceDoc/61104E.pdf
page 14, what you'll find there is a step by step explanation about configuring the ADC.
Later on you'll find even some code examples in C.
If something doesn't work the way it supposed to or i am encountering some weird problems the first thing is to read through the reference manual. Microchip has nicely written ref manuals, although i found a few unexpected surprises, too. That's why the second thing i'm looking into is the chip errata.
There should be no problem with getting the MikroE board working with the ICD2. You will be using standard PGC+PDG+MCLR lines instead of the bootloader.
Quote from: free electron on March 20, 2012, 04:49:45 AM
Take a look here, this is the section of the reference manual describing the ADC module:
http://ww1.microchip.com/downloads/en/DeviceDoc/61104E.pdf
page 14, what you'll find there is a step by step explanation about configuring the ADC.
Later on you'll find even some code examples in C.
If something doesn't work the way it supposed to or i am encountering some weird problems the first thing is to read through the reference manual. Microchip has nicely written ref manuals, although i found a few unexpected surprises, too. That's why the second thing i'm looking into is the chip errata.
There should be no problem with getting the MikroE board working with the ICD2. You will be using standard PGC+PDG+MCLR lines instead of the bootloader. Allow me to mini-rant. ;)
Yeah, I saw something like that in the PIC32 ref manual. Didn't see that one exactly, though.
I think it's the bit setting I have most of a problem with. And HEX. Like the following:
QuoteAD1CHS= 0x00070000;
// Connect RB7/AN7 as CH0 input// in this example RB7/AN7 is the input
So for some reason, the number seventy-thousand means I'm rerouting RB7 as channel0 of the ADC. Fair enough. According to the datasheet, if I wanted to route it to channel15, it wouldn't be seventy thousand, it would be 987504. ....... 987504! Really.
Now, I *know* that these values actually can be converted into binary, where say the 16th, 17th, 18th and 19th bit flag which channel I'm rerouting RB7 to. Nevermind that in "AD1CHS", there's absolutely no indication of that. If I was going on intuition, I would have guessed it was RB1, or channel 1 or something, because of the "1" in there. You would also think that the 70000 somehow meant AN7 in the example, but no. The 70000 just meant it was the decimal version of a string of bits to be flagged.
That's my problem. It's completely counter-intuitive. Random bit flags pertaining to the ADC "1" (which somehow means RB7/AN7) are lumped together in a seemingly arbitrary number such as 70000 or 987504 (the difference between channel0 and channel15). I *know* it's not arbitrary, but all the examples are written that way. My mini-rant is that it makes learning
extremely difficult. I can copy and paste the example code okay, but when it came time to swap between channel 0 and 15, it took me 30 minutes of reading to understand this concept, and I couldn't believe the counter-intuitiveness of it when I did. I was boggle-eyed. :icon_biggrin: And then I was trying to change something else and I gave up after hour. Something else that, had everything been written in plain english, would have taken 5 seconds.
Maybe I'm mistaken somewhere here, because I haven't gotten stuff to work yet. But that's just my point. I feel like the documentation and examples assume you're already a pro in this environment. I am not. Some people like to dive into the hard stuff when learning something new, liek a new programming language, IDE or type of hardware. Not me. I've always been a "hold my hand and walk me through the simplest examples imaginable, pretend I'm 7 years old" guy. Bascom/AVR had exactly that, and after two days I was already coding some serious little routines! mikroC/PIC32 doesn't have that, and I'm frustrated.
end rant. ;)
I had a look at MPLAB last night! The mikroelectronica PIC32 board is programmed via bootloader, so I've been using the bootloader app to flash MPLAB's program to it with some degree of success. I loaded up a complex led blinker program, and the two debug leds on the mikroe board blinked. I loaded up an ultra-simple led blinker program, and I haven't gotten it to work. I'll try and figure it out tonight. Right now I've got to go to work. At least I know I don't need a programmer with these boards, for the timer being!
I'll have a thorough read of your PDF later today. Thanks!
Quote from: cloudscapes on March 19, 2012, 06:58:41 PM
I'm checking out MPLAB now. See what a different compiler is without necessarily switching hardware. If I can get it to compile for my mikroelectronica board when I might switch.
The interface isn't as sexy, but the library syntax looks a lot better to my eyes. Example, in MPLAB, configuring the ADC might look like this:
#define PARAM1 ADC_MODULE_ON | ADC_FORMAT_INTG | ADC_CLK_AUTO | ADC_AUTO_SAMPLING_ON
#define PARAM2 ADC_VREF_AVDD_AVSS | ADC_OFFSET_CAL_DISABLE | ADC_SCAN_OFF | ADC_SAMPLES_PER_INT_2 | ADC_ALT_BUF_ON | ADC_ALT_INPUT_ON
Since I already have general knowledge of microcontrollers, it's pretty self-explanatory. It's english and uses words! But on mikroC, the same thing might look like this:
AD1PCFG = 0xFF7F
AD1CON1 = 0x0004
AD1CHS= 0x00070000
AD1CSSL = 0
AD1CON3 = 0x0002
AD1CON2 = 0
Huh? Wha? AD1CHSNCYTBDS = 0x04723HYEN6 indeed!
So, what to do:
1. See if I can even get MPLAB and this ICD2 to work on the mikroelectronica board I use.
2. Port my code over.
3. Try ADCs again.
Actually, I prefer the mikroC option. At least I can easily know what I'm setting on or off, with english words, sometimes it's not so clear what you are setting, if the words aren't the same as the ones on the PIC datasheet.
I think I've figured out at least one thing. Copied straight from the manual:
Quote
AD1CHS = 0x00020000; // Connect RB2/AN2 as CH0 input
// in this example RB2/AN2 is the input
And that thing is.... that in the ADC reference manual (http://ww1.microchip.com/downloads/en/DeviceDoc/61104E.pdf), the comment doesn't match the code. Reference manual says bits 16-19 define which pin is CH0. 0x00020000 converted to binary is:
00000000 0000
0000 01001110 00100000
With bits 16-19 hilighted. 0000, according to the reference manual means CH0 would be connected to RB0/AN0. Yet the comment says it's RB2/AN2.
......
Using RB2/AN2 would make bit 17 into 1, making it 151072, not 20000....
...I mean, unless I'm mistaken. :'( Ugh. It's past midnight. I need sleep.
You have converted a decimal 20000 to bin, while 0x........ is hexadecimal.
How does memory access work on those RAM chips? Do you use any of the built in addressing features, or just your own library? That is, after setting everything up, can you create a circular buffer, and address each sample, or are you just able to sequentially fill up the memory, then read it out?
I've been futzing with a DsPIC based effects platform, and was looking for advice on expanding the memory. It would be awesome to have enough memory available to have a looper as well!
I'm still using the built in ADC and DAC, but I think I've settled on the TI AIC23 for the future, when I make a board. It's pretty well supported, and seems easy enough to use. There is just a lot to spec out on the project (and I have been very busy), so I'm having trouble getting rolling, but I can let you know how it works out if I ever get that far.
Quote from: Hal on March 21, 2012, 07:13:36 PM
How does memory access work on those RAM chips? Do you use any of the built in addressing features, or just your own library? That is, after setting everything up, can you create a circular buffer, and address each sample, or are you just able to sequentially fill up the memory, then read it out?
I've been futzing with a DsPIC based effects platform, and was looking for advice on expanding the memory. It would be awesome to have enough memory available to have a looper as well!
I'm still using the built in ADC and DAC, but I think I've settled on the TI AIC23 for the future, when I make a board. It's pretty well supported, and seems easy enough to use. There is just a lot to spec out on the project (and I have been very busy), so I'm having trouble getting rolling, but I can let you know how it works out if I ever get that far.
here's my write and read code
Quote
void RAM_write(long int valueADDRESS, unsigned int valueRAM) {
char RAM_WRITE=2;
DisableInterrupts();
Chip_Select_RAM = 0;
SPI3_Write(RAM_WRITE); //write command
SPI3_Write(valueADDRESS >> 16); //address msb
SPI3_Write(valueADDRESS >> 8); //address middle
SPI3_Write(valueADDRESS); //address lsb
SPI3_Write(valueRAM >> 8); //value msb
SPI3_Write(valueRAM); //value lsb
Chip_Select_RAM = 1;
EnableInterrupts();
}
void RAM_read(long int valueADDRESS) {
char RAM_READ=3;
DisableInterrupts();
Chip_Select_RAM = 0;
SPI3_Write(RAM_READ); //write command
SPI3_Write(valueADDRESS >> 16); //address msb
SPI3_Write(valueADDRESS >> 8); //address middle
SPI3_Write(valueADDRESS); //address lsb
ram_value = SPI3_Read(buffer);
ram_value = ram_value << 8;
ram_value |= SPI3_Read(buffer);
ram_value = ram_value << 1;
Chip_Select_RAM = 1;
EnableInterrupts();
}
1. 8 bit command, read or write, or a veriety of options.
2. 24bit address word. my SPI is configured in 8bit mode so I do it in 3 8bit chunks
3. input data to be saved. and here's the answer to one of your questions. once you've got the command byte in, and the address, you can enter a single byte, two bytes (what I'm doing) or write a long string to your heart's content. as long as chip-select is held low, you can keep entering or receiving bytes sequentially!
I'm not doing anything with the ram yet aside from a simple test to make sure it works. I use the automatic "sequential" to be able to read and write two bytes at a time, since I'm doing 16bit sound, but that's all I'll be doing. the features I have in mind require totally random access, so long sequential reads/writes are not needed. though they can be done!
I'm just gonna brute force it. every 44000th of a second, I'll just call that read or right routine over and over again, for whatever 16bit word I need at that given time. that's the extent of my library.
Quote from: free electron on March 21, 2012, 12:58:08 AM
You have converted a decimal 20000 to bin, while 0x........ is hexadecimal.
thanks! I've been reading this wrong.
I'm still reading the ADC ref manual. I haven't found the part where they explain how AD1CHS pertains to CH0 if 0x00020000 is RB2/AN2. CH1 is AD2CHS maybe, and CH15 is AD16CHS. I'll keep reading...
edit: scratch that, AN2CHS doesn't even exist. somewhere in "AD1CHS = 0x00020000" is a reference to CH0, and it's not the 0x00020000.
I don't have pots working yet and thus no realtime control, but this weekend I'll try and hard code a loop record then playback and post some sound samples at various samplerates.
the new 16bit ADC has a bit of background hiss that the 12bit ADC didn't have. might be because of the breadboard, might not. the hiss can't be heard at all when there's actual playback, but it's there when silence. I think I'll just gate the output with a vactrol when there's silence. I did exactly that on a ringmod I built years ago to get rid of carrier bleed.
got the ADC workingnow. I'm both initializing and sampling every 10ms and it does both very quickly (a couple us, less that the length of a sample). :icon_biggrin: it took a lot of searching and reading on other forums how people do it. with examples. just instructions don't do it for me. I need to see examples to be able to parse what I'm reading..
http://www.microchip.com/forums/m593633-print.aspx
so I now have one pot that controls the samplerate in realtime (updated every 10ms) between 66KHz and 1KHz. :icon_biggrin:
Quote from: cloudscapes on March 21, 2012, 08:37:25 PM
I'm still reading the ADC ref manual. I haven't found the part where they explain how AD1CHS pertains to CH0 if 0x00020000 is RB2/AN2. CH1 is AD2CHS maybe, and CH15 is AD16CHS. I'll keep reading...
edit: scratch that, AN2CHS doesn't even exist. somewhere in "AD1CHS = 0x00020000" is a reference to CH0, and it's not the 0x00020000.
Page 3, block diagram of the ADC module.
The ADC channels are described as AN0...AN15, not CH0...CH15. This is why you won't find the reference.
0x00020000 has "1" on bit 17, that means the bitfield CH0SA (bit 19-16) has a value 0b0010 which is decimal 2 and corresponds the AN2/RB2 pin on the chip.
Quote from: free electron on March 22, 2012, 03:46:17 AM
Page 3, block diagram of the ADC module.
The ADC channels are described as AN0...AN15, not CH0...CH15. This is why you won't find the reference.
0x00020000 has "1" on bit 17, that means the bitfield CH0SA (bit 19-16) has a value 0b0010 which is decimal 2 and corresponds the AN2/RB2 pin on the chip.
I got it working last night, thanks!
Basically, here's how I got confused. I was going through each ADC init line by line, making sure I could understand the steps. The manual tells me:
AD1CHS = 0x00020000
..assigns RB2 to CH0. Alright, I do it, and it works on RB2! Then here's where the "fun" starts. Since I want to use at least 3 ADC channels, I look for the part where it explains where I assign another channel to another pin. I was totally expecting to have an init that looks something like this:
AD1CHS = 0x00020000
AD2CHS = 0x00060000
AD3CHS = 0x000B0000
AD1PCFG = 0xFFFB;
AD2PCFG = 0xFFFC;
AD3PCFG = 0xFFFD;
..you know? And so on. I had it in my mind that the only way to configure an ADC on this chip, on any chip, was to set up each channel or each pin at the start of the program. That's how I did it with AVRs and Bascom. And I was frusterated because no where in my manuals did I find an example where multiple channels were being used. They were simple, single-channel examples.
It took searching on other forums some real-life code examples to finally understand that AD1PCFG (and other registers) must be set differently before a channel is sampled. Each time. It took a different way of seeing things.
Controls (so far)
Here are the controls and features I will be trying to implement. The how's are mostly already clear.
Knob –Speed (PIC32)
Knob –Forward/freeze/reverse (555)
Knob –Freeze granularity (555)
Knob –Start point (PIC32)
Knob –End point (PIC32)
Knob –Drift (PIC32)
Knob –Filter cutoff (analog)
Knob –Filter resonance (analog)
Toggle –Filter post/pre feedback (analog)
Knob –Modulation speed (AVR)
Knob –Modulation depth (AVR)
Knob –Feedback
Knob –Input gain
Knob –Wet
Knob -Dry
Button –Record/play
Button –Bypass/erase
The stuff in brackets is how its gonna be done. PIC32 means the pot will be directly connected to the micro and will be handled in code. Analog means just that, and AVR means I have a little 8pin modulation AVR I like to use for these kinds of thing. It'll PWM a push and pull into the Speed pot's ADC.
The Forward/freeze/reverse and freeze granularity is what I think I'm most excited about. Here's how:
Forward / freeze / reverse
Nearly all (or all) loopers I know of manage reverse in one way. A button, or a toggle switch. Off it goes forward, on it goes in reverse. I want something a bit more special than that. I want a knob that has totally variable states between:
- full speed forward
- slower speed forward (no pitch change)
- very slow forward (still no pitch change)
- freeze
- very slow reverse (still no pitch change)
- slow speed reverse (etc..)
- full speed reverse
Here's how I'm gonna do it. The PIC32 will have a digital input pin. Low pin is forward, high pin is backwards. Then I attach a 555 with controllable speed and PWM! This image is a representation of the PWM signal to be generated by the 555 and fed into the PIC32 forward/reverse toggle pin.
(http://nearworlds.org/stuff/PWM_freeze.gif)
Each segment is a short period of time. For the sake of the argument, lets say 5 milliseconds. On full forward, there are no pulses, just a low signal. The PIC32 interprets that as forward playback.
Turn the pot a bit and the 555 generates a little duty cycle. In this example, 25%. The PIC32 interprets that as mostly forward playback, with 25% rewind. Since this is done very quickly, every couple of milliseconds, our ears and brains will interpret that as "slower speed", and it will preserve the pitch.
If the pot is in the center, then the forward and reverse duty cycle are the same, and a "freeze" is achieved. Turn it even more, and the reverse state is longer than the forward state and so you start to go back in time. An additional potentiometer can be
This is not a "perfect" method of pitch-preserving time stretching. That would probably involve blending microsamples and advanced DSP stuff that I'm no where near ready to try. This is a hack, but it works! I've tried it on an AVR sampler a year and a half ago. This time, it'll be fine-tuned and hi-fi.
Quote from: cloudscapes on March 22, 2012, 09:03:02 PM
I had it in my mind that the only way to configure an ADC on this chip, on any chip, was to set up each channel or each pin at the start of the program. That's how I did it with AVRs and Bascom. And I was frusterated because no where in my manuals did I find an example where multiple channels were being used. They were simple, single-channel examples.
This is an example of why bascom can be good to start to play with MCUs, it's easy a delivers a quick results. On the other hand it leaves bad habits, because many functions are hard coded into the compiler and you don't really see what are they doing inside the chip.
Since you got the ADC working... the PIC32, DSPIC (this is where i'm using it) and most modern >8bit MCUs have a few nice features to optimize the ADC conversion, especially non time critical parameters like DC pot values.
Let's say you have 3 or more pot to read. You can configure one DMA channel to work together with the ADC so they will do all the conversions, store them in a DMA buffer and when all pots are read, the interrupt will be triggered, where you can copy the values from the buffer to your variables. Basically instead of doing "n" single conversions with manually setting the channel, starting, waiting to be completed etc, you let the ADC collect the data, call the DMA module when a sequence is finished, pass it the "n" words of data, then the DMA will call your main program "hey! here are your pot values". All this happens in background without sacrificing the cycles you can use to process the audio samples. The only thing your program need to do is to copy the data from the DMA buffer in the interrupt subroutine.
Might be very useful if you plan to do multiple reads/writes to the RAM via SPI.
With all the things PIC32 has on board i'm pretty sure you could code the Speed/Forward/Freeze/Reverse (555) and the LFO (AVR) into the chip. What the 555 does looks exactly like a DDS with phase distortion implemented and a square wave output. You need one timer for that, it could also do the LFO.
Yeah on second thought I might just go ahead and do the modulation on-chip. I was just being lazy, already having an AVR solution. But it'll keep the PCB space lower and it'll be a learning experience.
You're right about Bascom basically doing the hard stuff under the hood. I stuck with it for years. Maybe I should have moved on to more advanced compilers after the first.
The DMA stuff is way over my head. I thought that was used to interface parallel RAM? What would I get out of what you're describing that I don't already get just by triggering an interrupt ever 10ms and reading the 4 ADCs only then?
Quote from: cloudscapes on March 24, 2012, 03:38:13 PM
The DMA stuff is way over my head. I thought that was used to interface parallel RAM? What would I get out of what you're describing that I don't already get just by triggering an interrupt ever 10ms and reading the 4 ADCs only then?
DMA is your delivery guy. You can use it with many peripherals, accessing parallel RAM is only one example.
What are the benefits? Less processing power used for background tasks like reading the pot values, more power (cycles per one sample) for processing audio data or other important things, like an LFO for example.
Simplifying the process a little bit, because there are also interrupt priority levels and stack operations - what your program needs to do now is to break every 10ms, jump to the timer ISR, start conversion, wait until its done, read the result, change the channel, repeat it 3 times.
Using DMA+ADC the converter works in background and fully automatic doing all four conversion and storing them. When they are ready, the delivery guy knocks at your door (DMA interrupt) and serves you all the data.
It's just one way to optimize the performance and make use of the features the PIC32 has onboard.
Quote from: free electron on March 25, 2012, 09:28:21 AM
DMA is your delivery guy. You can use it with many peripherals, accessing parallel RAM is only one example.
What are the benefits? Less processing power used for background tasks like reading the pot values, more power (cycles per one sample) for processing audio data or other important things, like an LFO for example.
Simplifying the process a little bit, because there are also interrupt priority levels and stack operations - what your program needs to do now is to break every 10ms, jump to the timer ISR, start conversion, wait until its done, read the result, change the channel, repeat it 3 times.
Using DMA+ADC the converter works in background and fully automatic doing all four conversion and storing them. When they are ready, the delivery guy knocks at your door (DMA interrupt) and serves you all the data.
It's just one way to optimize the performance and make use of the features the PIC32 has onboard.
I looked up a bit of this.
I'm thinking, seeing how this is my very first project using this architecture, compiler and language, that I should stick to simply upgrading/translating previous AVR experience and making sure I can get that much. With the added flexibility and horsepower of course. The ADC "struggle" was an example of that, but I was already familiar with the concept of ADCs and what they were used for. DMA, however, I'm still not sure what it does exactly, after reading. It's way over my head, so I think I'll skip it this time around seeing how so far I've got lots of cycles per sample.
Tonight I'll measure exactly how long the new ADC code is taking every 10ms interrupt.
Crossfade
Another thing I want to implement is some kind of realtime crossfade at the loop point. Not an audible one, though. Just enough to get rid of the nastiest of the pop/click at loop point. Say 100 samples worth. How I incision doing this:
As soon as a new loop recording is done, all samples are saved but the actual played loop will be 100 samples shorter. Only a couple milliseconds worth, it won't make a difference to the ear. As the loop playback hits (total loop length - 100), it adds (first of extra samples / 100), to the current one and divides the result again by 1.5 or 2 (I'll have to experiment with that whether I want a linear crossfade or log). The next sample adds a little bit more of the second of extra samples. And so on. Not the most efficient of algorithms so I'll figure something better out. But that's the gist of it.
It'll be realtime and not "cooked" into the saved samples, because I want to be able to move the loop point around dynamically.
didn't have much time to work on this lately because of job and because I'm building vibratos for a while, but tonight I made this:
(http://nearworlds.org/stuff/holysht.jpg)
Oh, that is AWESOME!!!!
revised design, assuming I can cut squares in metal without hacking a finger off
(http://nearworlds.org/stuff/holysht2.jpg)
Wow - Looks Fantastic !!!! :icon_biggrin:
thanks :icon_biggrin:
started working a little on it again. got a MAX297 filter ic working to de-alias the sound at lower samplerates instead of having that "samplerate reduction" effect, which I don't want in this looper. today I'll try and control it with the PIC32 via PWM so that the filter sweeps along with the samplerate.
maybe I'll get some audio samples up!
I'm also thinking that now that my breadboard is getting rather messy (6 ics) and not immune to background noise (inherent of high speed electroncis on breadboard), that it might be worth it to pay the $40 to design and have manufactered one or two prototyping PCBs with a solid base, along with sockets for expandibility.
the 9-digit display isn't set in stone.
it's not the electronics that bother me (they make chips for this, and I could make my own co-processor without too much difficulty just to drive the display), it's the square holes in metal. filing is a pain, and hammond boxes are too thick for nibblers.
(http://www.hwdyk.com/q/images/isecondthatemotion_02.jpg)
a much bigger rectangle for a backlit LCD might be easier than 3 smaller holes, but 7-seg digits are so much sexier! or maybe I can have one long rectangle, still with the 7-seg displays but with space between the three groups, and a blinking led between them. or something.
You could bring the boxes to a machine shop to broach them; if you do so, make the plain segment between the windows a bit larger or you might have a few broken/unusable boxes.
I agree, seven segment leds look great.
Check this out:
http://www.adafruit.com/blog/2012/02/22/review-–-the-solder-time-led-watch/ (http://www.adafruit.com/blog/2012/02/22/review-%E2%80%93-the-solder-time-led-watch/)
You could use different colors for each set of digits (red for three digits, blue for next three, yellow, and so on) but you'd have to use a separate led driver for each group due to brightness differences and forward voltage differences for varying color. Or use different current limiting resistors, whatever. But I think that would look cool.
Or what about using a small OLED display with a serial interface?
http://www.sparkfun.com/products/8537 (http://www.sparkfun.com/products/8537)
yeah I have a couple small oleds I got from ebay, a few lcds too. I think it's a bit overkill for what I need. a character LCD is the absolute max, and it won't be as high contrast as bright 7-seg displays.
the numbers in the graphic above are 7mm by 4mm, exactly based on some I found on mouser. a little small for reading, but at least the contrast is high.
What did you use to draw the mock-up?
Maybe make holes like this
(http://cosarthistory.pbworks.com/f/1248753226/venn.diagram.gif)
and file down the points? It could be a cool bubbly shape display.
Quote from: markseel on April 28, 2012, 09:51:16 PM
What did you use to draw the mock-up?
just photoshop CS3
Quote from: CynicalMan on April 28, 2012, 10:58:39 PM
Maybe make holes like this
(http://cosarthistory.pbworks.com/f/1248753226/venn.diagram.gif)
and file down the points? It could be a cool bubbly shape display.
I've always had trouble drilling those kinds of holes. the bit and/or box tend to move around out of alignment when it hits the outline of a neighboring hole.
another try
(http://nearworlds.org/stuff/holysht3.jpg)
A little update. :)
It got sidetracked by my 1000th-page contest entry, another design, and general life. The great part is my 1000th-page entry uses the same architecture that I will use for this looper, the PIC32! I learnt a great deal about it, and C programming (which I hadn't really done when I first started the thread). The looper project is clearer now, and I'll slowly start work on it again now that I've made this:
(http://nearworlds.org/stuff/pic32_dev_board_v1.jpg)
Commercial dev boards are all so complicated, packed with features I'll never need, so I decided to design my own. At the moment, it's just the minimum. A beefy 100 pin PIC32, the crystal, a 3.3v and 5v power supply and what the pic needs to stay alive (the decoupling caps are SMD under the board). Also, a way to mount some pots for digital control, with the 0-3.3v all connected up, and the wipers to the pic's ADCs. This will probably be the first dev board of a few. Once I get RAM, the DAC and the ADC pretty much done, I'll include those right on the next version of the board, as well as whatever refinments I need.
Please tell me that you are planning on offering up some boards when you're done!!!! This project looks like the only looper that will fit the bill of replacing my Boomerang+ with all the features that I would really need/use. Plus it will look really sweet next to my Phase II when I get it done!
I <3 cloudscapes!
I can't guarantee it'll feel much like the 'rang, though. ;) I used to own one and felt it wasn't for me.
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. :P 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.
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. ;D 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.
Quote from: cloudscapes on November 10, 2012, 10:33:45 AM
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. :-[
Quote from: alparent on November 14, 2012, 08:07:10 AM
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).
Thanks for the lesson!
It's always good to to hang around smart people.
Is it a dead project ?
Quote from: Bluexav on December 04, 2013, 02:40:36 PM
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..... :icon_neutral:
Quote from: cloudscapes on November 14, 2012, 06:08:54 PM
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.
Quote from: potul on December 08, 2013, 04:06:11 PM
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.
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.
Quote from: Perrow on December 10, 2013, 02:21:44 AM
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.