Anti-nautilus (or, autoglitch)

Anti-nautilus theory

Giant interdimensional nautilus portal right into the cities of the world! Most people, those who will not run, will grab baseball bats, mace, bad art, even a sword! What do I do? Fight it with lasers of course! Lasers are the nautilus' natural enemy, as often observed in the natural world. Not having xeon gas at my disposal, I turned to the tools I knew well and built a stompbox laser.

The Anti-nautilus focuses a beam of.... err.. sorry.... it continuously samples audio input, and once a (settable) input threashold is hit, unmutes and plays back the previous snippen of sound back-and-forth in a kind of glitchy lasery freeze effect. The duraction of the audio sampling during lasering is set by the Buffer knob, and the Break knob provides additional stuttery-ness to it! It can sort of be seen as a very short looper too, ranging between 1000-th of a second to 1 second. Additional control over Pitch bending (up or down) while the duration of the lasering can be set. It can be locked to single octaves, or as much as the design can handle, in this case 6 octaves. A Fade knob provides decay over time in much the same way. External trimpots are there for the input gain, output effect volume, wet/dry blend and "trigger thresh" sensitivity.

Short version: It's basically an auto-glitch, auto-repeat thing with tweakability.

One green LED to show whether the effect is bypassed or not, and a purple LED to indicate when input threshold is achieved.

Picking out the hardware

I was already familiar with 8-bit AVRs (programmed using BASIC), but extra horsepower was really needed here. So I forced myself to learn C and the new PIC32 hardware. Mikroelectronica's little MINI-32 is a great way to get started! It's breadboard-friendly, and has a USB plug for easy programming. I wasn't going to use it for the final layout, but it's great for prototyping. For what I had in mind, the PIC32's internal 16KB of RAM was enough, so no need for external memory.

I needed an ADC and a DAC for audio. DAC was an easy choice. I had a bunch of PT8211's at hand which I was already familiar with! It's cheap (half a dollar each), easily found, easy to interface, small 8-pin package, 16-bit, fast and sounds good! I had my DAC.

ADC was gonna be trickier. I had spent much of the year researching and getting samples of 16-bit ADCs for whatever applications. 16-bit ADCs in a small easy to use package are a dying breed, everybody wants to use codec ICs now, which are a little overwhelming for me at the moment. I found a couple, but they were expensive ($12-$16), and were noisy. I settled instead for the MCP3201. It's 12-bit and quite a bit slower, but it worked for my needs. And it's far far quieter in terms of unwanted noise. Because of the slower speed, I had to limit the program's sampling rate to 22KHz, even if the PIC32 and much faster DAC could easily handle 100KHz (by my tests).

The PCB layout and schematic were drawn out in DipTrace.

What went right

Designing a solid programmable hardware base with 12-bit input and 16-bit output! I have a feeling I'll make a few developpement PCBs with this setup so I can easily and quickly start a new digital project! I'd probably want to fix the 12-bit ADC into 16-bit, though, and I'll want to tack on some external RAM. I think with a few modifications, I can make a nice little DSP dev board!

What went wrong

Using unsigned data format for audio storage instead of signed. Hooooo boy.... ok. How I went through the entire developpement was by storing audio input in an 8000-strong unsigned word array. Each "word" is a single sample, a value based on amplitude at that given moment that produces a number anywhere between 0 and 65535. That's 16-bit data. I'm not saying that's the best way, just how I did it.

That looks fine, doesn't it? It plays fine, anyway. Now below I've drawn out what took me over a week to figure out, without the aid of visuals or the experience of having dealt with hi-fi ish audio. I had most of the program done and working well, and I implemented the fade feature. I wanted to fade the audio by X amount every time the "loop" looped (or reversed direction). Except when I implemented that feature, I'd get an audible click or pop at each fade point. I thought I was goofing up the fade formula, or that I was "forgetting" to fade every first or last sample of the loop, or something. My UART was broken (thing I can plug into computer and see debug numbers sent by microcontroller), and my cheap oscilloscope was too limited to show me the "big picture" of what was happening. it literally took a week and a half of trying new code, listening for changes, guessing, rewriting the code on how the loop reverses direction, etc. Thinking the pop was a single sample that went up to 65535 because of a glitch, or something. Was data improperly being sent to the DAC? Or from the ADC? Had to test that too. No dice. Then one day I did what I should have done on day one, and simple recorded the pops with my soundcard and looked at the waveform.

....uhhh... wh.... oh... OOOOHHHHHHHH! Oops!

Those yellow lines in the otherwise beautiful sine wave represent what I was more-or-less seeing (though not so colorful). The click/pop was NOT some odd dropped sample, it wasn't some glitch when I told my loop to reverse direction, it was that I wasn't using the right data format. I understood it the second I had the visual clue in front of me. I was using unsigned (0-65535) data format, so whenever I told my program to "fade", it would shrink the waveform towards the arbituary 0 floor, and not towards the "center" of the waveform. Oops.

Once I recognized the problem, I tried hacking a solution by tricking my fade code that the number 32767 was the center of the universe, but that gave me more problems elsewhere in the program. I even tried non-destructive crossfade at each-loop point if I was fading. Not super easy to do when the loop is actually a reversal in playback direction. Didn't work. I accepted I had to change the fundamentals of the audio data format, that it couldn't simply be scotch-taped in. Blergh.

Unsigned data is 0 to 65535. Signed data is -32767 to 32767, where the "center of the universe" is exactly 0. This makes much more sense in the audio world. I converted parts of my code into signed format. My PCB was already done, so whatever changes had to be in code. Once the conversion was (mostly) done, I noticed that absolute silence wasn't exactly 0, likely because of the 5% tolerances of whatever resistors I was using in front of the ADC. I coded in an extra +200 "data" to each sample to offset it to 0. Close enough.

Much better. It's actually exagerated in this picture. The filtering I had in the circuit post-DAC took care of the rest. I will be using signed data for audio in these types of projects from now on.

Art

I had a pretty good idea of what kind of art I wanted on the pedal half-way through developpement. A giant squid, octopus or other tentacled entity wreaking havoc on humanity. Isn't that the best way to go? The sound of the pedal was "laser-ish" from conception, but I didn't want to do UFOs or particle accelerators. Definitely lasers though! Either attacked by or defending with. It took actual experimentation with a breadboarded prototype. I found I could get some really organic and "crawly" sounds out of it, as well as lasers! The idea of a giant many-limbed invertebrate settled into place shortly after. Oh, I know! A nautilus! I haven't drawn any of those yet!

The picture was clear in my mind, and what I like to do for images of that complexity is model it in 3D first. My day-job involves working quite a lot with 3DS Max, a professional 3D package. It's far more intuitive for me to sculpt objects in virtual 3D space than to sketch things in 2D and have to erase and start parts over. I didn't need details yet, just basic shapes. After a couple hours, I had this:

Then a few hours in photoshop to trace outlines and add details. I couldn't fit any lasers in the pic, so I was treading onto plot-hole territory. But I fugred the sounds I got from the thing were crawly and spacy enough to portray the grander terrifying invasion. This will be applied on a transparent decal.

Painting is fairly straightforward. A base layer of acrylic primer is applied and left to set for a day. A few base layers of acrylic paint is brushed on by hand. I usually dilute it with water. Say one part water and two parts paint. I have a small heating fan that I like to "bake" paint layers with. It's small, but next to a pedal, can easily raise it to toaster-oven temps! Also, it makes more sense to me to pick bring colors as the base layer, then go over it with dark later, instead of trying to paint bright on dark.

After base layers, combining toothebrush-spray-on splatter and hand-painted spirals and shapes to give it fun! I try and keep the areas which will have decals bright, so that the transparency works and is contrasted. I keep "baking" the box with the floor fan in-between steps and when I'm finished, sucking most of the water out.

I use Lazertran for laser printers. Fitting for the nature of the pedal! On it I print the picture I vortexed out of the 11th existencial plane, the border trim, and the words that will be under knobs and toggle switches. The printed decal is soaked in water, then seperated from the opaque backing. I apply it to the dried paint like a temp tattoo, with a bit of water based clear in-between! I have a few minutes to push the bubbles out or guiding them to the nearest pot hole. Let it sit for a while, then I do the heating fan trick again, though at a much lower heat! This kind of "melts" the decal (which is essentially plastic) deep into the paint. The lower heat is to keep it from bubbling, though a little isn't a problem.

One of the most important steps, clear coat! I've taken a liking to clear epoxy resin, rather than traditional spray or brunched-on clear coats. The disadvantage is that it's rather expensive (a $30 bottle will last you around 10 pedals), messy (don't drip it, it can't be washed. ever.) and hard to find in precisely the right viscosity. It's applied in one single thick syrupy coat with a plastic spoon! Why viscosity is important is that if it's too thin, too liquidy, it'll run off the sides of the box too much and won't provide adequate protection there. The thicket it is (when "wet"), the more of it will stick to the sides. The top isn't a problem, it hardens to a mirror shine without any polishing! Normally, it takes about two days to harden, but after letting it set for one, I can do the heating fan trick again, bringing it down to just a fistful.