We’d been talking about mass-spring systems and resonators, so I decided to use a bank of parallel resonant filters to simulate the springs.

I implemented a Resonator class, following Robert Bristow-Johnson’s biquad formula for a resonant LPF [1]. Each resonator tends to ring at a particular frequency, and the impulse response looks like a decaying sinusoid.

By combining a few hundred of those simple resonators, each resonating at a different frequency and driven with a complex sound, you can approximate the sound of a spring reverb.

Here’s the Resonator implementation file – the rest of the plugin source is on the bitbucket page linked below:

[1] http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt

The finished PCB

pucktronix.snake.corral is a computer-controlled dual 8 x 8 analog signal routing matrix. Two independent matrices are presented, each with 8 inputs and 8 outputs. Within each matrix, any input (or summed combination of inputs) can be routed to any output. The device can switch and route any type of analog signal within the range of +/- 5V. The main electronic components of the pucktronix.snake.corral are a Teensy 2.0 and a pair of Zarlink MT8816 analog switching matrix ICs. The MT8816 is a bidirectional 8 x 16 matrix with minimal signal bleed. Like the USB-Octomod, the pucktronix.snake.corral is powered from the USB bus.

A Max/MSP patch which allows the user to define and switch between presets and/or apply various algorithmic rhythmic effects to the switching matrices has also been developed.

Using the pucktronix.snake.corral, a modest number of synthesis modules can be used to create interesting rhythmic and timbral variety. The ability to rapidly switch or reconfigure a large number of signal connections enables a level of rhythmic complexity which is difficult to obtain through other means. Sharp cuts between disparate types of musical material are made possible, and patches can be stored and quickly recalled.

PCBs will be available soon, and you can follow discussion on the project here:

http://www.muffwiggler.com/forum/viewtopic.php?t=51389

Here’s the pinout:

Each of the pins beginning with “A” is an address pin – they’re how you address a specific X/Y connection. To interface this with an Arduino, you need to connect 11 digital output pins from the Arduino:

• 7 address pins (AX0-AX3, AY0-AX2, these use a strange binary-ish number system – more on that later)
• DATA (High or low to indicate whether to open or close the specified switch)
• CS (Chip Select – you can just tie this high if you’re only using one)
• STROBE (Setting this high writes the DATA to the indicated address)
• RESET (I found that if I didn’t reset the chip upon powering the circuit, I’d get strange results)

Other than that, you need to connect VDD, VSS, and VEE to +, GND, and – supplies.

So, as I mentioned, the addressing scheme is a little strange – and caused me 2 – 3 lost days of head-scratching and frustration. Here’s the info from the datasheet:

As you can see, the address pins indicate an address in a parallel, binary-ish scheme. So, if we’re going to select a particular matrix point – let’s use X3/Y1 – we use all of the address pins at once to indicate the numbers we need. Pins AX0 – AX3 give us 4 X address pins – 4four bits, which lets us count from 0 – 15 in binary. AY0 – AY2 give us 3 bits, 0 – 7 in binary. The 4-bit binary representation of our X address, 3, is 0011, and our Y address, 1, is 001. Consulting the table above, we can look up the value for X3 and see that it is actually 0110, and if we jump down a bit, we see that Y1 is 001. So, to represent our X3/Y1 we just turn our Arduino pins X1, X2, and Y0 high, and leave the others low.

This is all pretty clear, and the addressing follows binary counting rules until you get to X6. Look at the data sheet – X12 and X13 are actually represented by the binary numbers 6 (0110) and 7 (0111). I found an easy fix for my application, but long story short – never assume your chip follows any logic, and always read the datasheet thoroughly. I will admit to much profanity upon discovery of this design “feature” – you can see I had fun on this one…

Here’s my code, apologies for crummy WordPress formatting. Note that I’m only using an 8 x 8 subset of the chip, so my compensation may not work for your needs.

void togglePins(int chip, uint8_t x, uint8_t y, int state){
if(x >= 6){ // compensate for strange x-axis addressing scheme
x += 2;
}
digitalWrite(chip, HIGH);
// next lines convert from integer to binary address
// bitRead returns whether a given bit position in the binary representation of a value is high or low
if(bitRead(x, 0)) digitalWrite(X0, HIGH);
if(bitRead(x, 1)) digitalWrite(X1, HIGH);
if(bitRead(x, 2)) digitalWrite(X2, HIGH);
if(bitRead(x, 3)) digitalWrite(X3, HIGH);
if(bitRead(y, 0)) digitalWrite(Y0, HIGH);
if(bitRead(y, 1)) digitalWrite(Y1, HIGH);
if(bitRead(y, 2)) digitalWrite(Y2, HIGH);
// after address pins are set, set strobe high
digitalWrite(STROBE, HIGH);
// make sure DATA pin is the correct value
digitalWrite(DATA, state);
// reset all pins to low
digitalWrite(STROBE, LOW);
digitalWrite(X0, LOW);
digitalWrite(X1, LOW);
digitalWrite(X2, LOW);
digitalWrite(X3, LOW);
digitalWrite(Y0, LOW);
digitalWrite(Y1, LOW);
digitalWrite(Y2, LOW);
digitalWrite(chip, LOW);
}

It’s a pretty simple function, and you can see the rest of the program in my bitbucket repository.

I’ll be posting more soon about the device I’m building – it’s called pucktronix.snake.corral. I hope this helps decipher the datasheet, and saves some possible head-scratching.

https://bitbucket.org/pucktronix/pucktronix.golgi.apparatus/

Right now, there’s an OS X Standalone App, a Max Collective, and all of the source code.

If anyone is running Max on windows and can compile a standalone for me, that’d be great.

Also, please retweet/facebook/blog this as much as you’d like – I’d love to have as many people as possible see this!

https://bitbucket.org/pucktronix

I hope to use eventually use the bitbucket site as the landing page for my code and electronics work.

The Octomod was funded through word-of-mouth, Twitter, Facebook, and various online forums.

This had the advantage of allowing me to interact with almost everyone who decided to buy a circuit board. I really like the forum method, because I received a lot of valuable feedback and many great suggestions on the designs. On the other hand, these methods forced me to buy the materials up front. I also had to deal with taking orders and collecting money, which can get complicated – making a free, functional storefront through WordPress also seems to be nearly impossible.

For the tabulaRasa, in addition to the social networks and forums, I decided to apply to Kickstarter.

Kickstarter is a way to raise funds for a project, by allowing people to commit a certain amount of money in exchange for a “reward” if the full funding amount is met. If full funding isn’t reached, no money exchanges hands. This has two advantages – 1) the project owner doesn’t have to invest money in the project upfront (although I did, and I’m sure many others do as well), and 2) the people who are funding only end up paying if the project is fully funded.

A couple of things I’ve learned after the Kickstarter experience:

I’m not sure that the video Kickstarter requires really made a difference in my case – but it can’t hurt.

Make sure to set a good financial goal – not too high and not too low.

Likewise, I realized I allowed for too many different funding tiers – this complicated things when it came time to provide the rewards. In the future, I’d go with only 3 or 4 funding levels, and minimize the number of different reward types.

You definitely want to be responsive to questions and comments – both on Kickstarter and on email.

Also, I found it important to remain flexible and willing to change the project. The music I make with my electronics doesn’t require a volt per octave tuning scale, so I designed the tabulaRasa without any sort of calibrated tuning. Many people contacted me asking about v/octave capabilities, so I spent some time doing the math and implementing a tuning algorithm. I made a video demonstrating it working, and had a bunch of people kick-in funding.

The last step of the process was ordering and assembling the boards, which I’ll cover in the next post.

Here are some things I’ve observed while developing the tabulaRasa and the USB-Octomod. Both projects are open-source hardware/software packages for use in modular synthesizers.

For me, the process divides up into three stages: design, funding, and production. I’ll cover each stage in a separate post.

Design

Make sure to spend plenty of time brainstorming, prototyping, scrapping, and remaking your project.

You want to explore as many angles as possible. Often a redesign or code rewrite will make implementing new features easier, or allow you to optimize some aspect of the design. Both the Octomod and the tabulaRasa went through multiple stages of sketching, prototyping, pcb design (and fabrication) before I decided they were done.

Aim to use common, versatile components.

You don’t want to use a single-supplier component in a design, unless there is no other option. The Octomod uses a Teensy 2.0 microcontroller unit which is available from only one source. Within a few days of announcing the availability of PCBs, the Teensy 2.0 went out of stock, and stayed that way for months. Besides limiting the usefulness of the PCBs, this left me fielding questions about the availability of a product over which I had no control. Some people are experiencing a similar issue with the SD card socket used in the tabulaRasa. Since the part is available from Sparkfun, I assumed it would be relatively simple for people to get. However, I didn’t consider that shipping to European countries from Sparkfun is either expensive or impossible. (Not sure which it is, I just know I got some questions about alternate sources.)

Using a minimal amount of components is also an advantage.

My initial designs for the tabulaRasa used a separate DAC chip, interfaced to the mcu through SPI. Although this theoretically provides for much higher bit resolution, most DACs require 16 or more bits to be transmitted per sample. The additional chip also added significant cost to the project. I instead used a simple PWM DAC, using an RC lowpass filter to smooth out the built-in PWM output of the ATmega. Simple, cheap, and still of a high-enough quality for my needs.

Open-source is an asset.

Many of the technical questions I received (usually related to compilation or misunderstanding of OSC) were easily solved because users could send me the exact error messages or line numbers they received. (On the other hand, asking users to compile their own code also led to confusion. I had a few people try to compile Arduino code in Processing, and vice-versa.)

More to come on how I raised money for construction on Kickstarter, and my thoughts on the manufacturing process.