Legatos: “Legos” for Sound

Physical Modular Sound Blocks for sound and music

I created a set of physical blocks, each with a special property for manipulating sound. The physical blocks are then mapped to virtual blocks in an open-source software synthesizer called PD. My set of blocks is just barely large enough to illustrate the idea of being able to mold sound physically and interact with sound musically.

In my implementation, I designed 2 ultrasonic sensor blocks, 1 LED block and 5 sound manipulation blocks. All blocks use the Atmel Tiny15. The blocks do not themselves manipulate sound. They only poll each other using a Depth First Search so to discover their relationships. I did a simplified version of the protocol I described in earlier pages on this website.

Some of my motivation for this project came from my desire to make a sound environment similar to Legos, where people can communicate powerful idea and at the same time play, learn, explore and design creatively. Ideally, I imagine my sound blocks as an extension to Lego’s or a similar environment. Therefore, I designed a shell for the blocks which fits with Legos. Here is a block resting on its shell, which is attached to a real Lego:

To illustrate my idea, I set up a very simple PD environment to model. Here’s a picture of the virtual world from PD which I wanted to recreate by modeling physically and then constructing virtually:

The comments written to the right of each virtual block is the name of the physical block I created to implement it. The ‘Cool 1’ blocks correspond to the ultrasonic sensor blocks. The ‘Fun 3.1’ blocks are the sound manipulation blocks. The Rock1 blocks convert between the 1-wire pseudo-UART I hacked up and standard RS232.

Here are the specifics of each block.

This example is a silly demonstration of pitch shifting and delay, all in real time. All virtual objects are macros of PD primitives which I created to closely model my concept of the physical blocks. In this example, there are 3 parameters, Delay, pitch shift 1, and pitch shift 2. As the user talks into the microphone, the signal is delayed by the block which is commented LED. Then it is played back with pitch shift given by the Cool 1 slider to the left. The signal is then delayed again by the same amount and a pitch shift is given by the Cool 1 slider on the right. By mapping these sliders to the ultrasonic sensors on the microphone, it makes it possible for a user to express themselves with their voice and then further alter there voice by moving their hands around the sensors. I set up the sensors, one to the left of the microphone and one to the right so the user could use one hand for the 1^st delay and another for the 2^nd.

Here’s are two pictures of the ultrasonic sensors on the microphone:

Although it is hard to see in these pictures, there is another identical sensor on the opposite side of the microphone.

The Cool 1 blocks use Devantech SRF1- Ultrasonic sensors. The sensors communicate using I2C. Implementation of I2C is made relatively painless as Atmel provides code on their website, and it needs only very minor modiciations. Note: Atmel calls I2C TWI as in Two-Wire-Interface. When a Cool 1 block gets polled, it sends the last value it got from the sensor. It then Pings the sensor so it will have updated information when it next gets polled.

Besides getting input from ultrasonic sensors, I created a block in which you can dial in any value you want from –999 to 999 with 3 range settings i.e. you can move the decimal place of the readout. Here are 3 pics of the LED block. The 2 switches are for adjusting the range and toggling the negative sign:

And Here’s a video of the LED block in action:

LED video.avi

Here’s a video of my officemate Victor trying out the complete system:

victor legatos.avi

Some things I learned from doing this:

It is not necessary to guess b values to calibrate the timing of the Tiny15s. All you have to do is read the calibration bit with the UISP: read-fuses command. The recipe is:

1. get everything ready to program as usual. (clip, rx.py, etc.)

2. type the usual UISP string but DON'T type --erase and --upload

if=<filename>. Replace those with --rd_fuses.

3. You should get something that looks like this:

Atmel AVR ATtiny15 is found.

Fuse Low Byte = 0x5c

Fuse High Byte = 0xff

Fuse Extended Byte = 0xff

Calibration Byte = 0x71 -- Read Only

Lock Bits = 0xff

BLB12 -> 1

BLB11 -> 1

BLB02 -> 1

BLB01 -> 1

LB2 -> 1

LB1 -> 1

4. Change the line in your code which currently sets your RC clock speed to

max so that instead loads in the calibration value. In my case I changed :

ldi temp, 0xFF ; maximum RC clock

to read

ldi temp, 0x71 ; calibrated RC clock

5. Set the b value in your code to 24.

Programming clips are not a good idea when doing multiple interations of debugging programming. The clip works great the 1^st few times, then gradually the clip and the connections to the chip deteriorate. If you must use a clip, take out the spring and use both hands to line up the clip with the pins. Then hit the <ENTER> key for UISP with your pinky, your nose, or whatever might be handy that isn’t your hands.

More pics of the project: