# data[].attributes.attachment_link.readable_text
Introduction: Make a Musical Bench

The Musical Bench is an exhibit which makes music when people touch, kiss, or hold hands. It uses a micro-controller to detect changes in resistance, via the copper armrests, and plays high or low notes depending on how much current flows through you and a friend. This exhibit is the result of messing around with many different ways of using the human body to complete an electrical circuit.

The original Exploratorium exhibit runs on a prototype board, but for this instructables we've used an Arduino instead. This makes it possible for you to build it into a bench, a drinking fountain, or something that we haven't thought of yet. You can also use this as a personal tool for playfully investigating electricity, conductivity, and capacitance. Have fun and happy tinkering!

Share

Recommendations

Water Contest

Oil Contest

Clocks Contest

Step 1: Materials

Collect these parts:

Soldering iron (we like this one from Weller)

Solder

Wire stripper

Wire cutter

Safety goggles

A computer loaded with arduino software

If you are new to Arduino Programming here are some helpful links: Tools:

How to program an Arduino http://arduino.cc/en/Main/Software

What an Arduino is http://arduino.cc/en/Main/ArduinoBoardUno
If you're familiar with schematics
How to choose an Arduino https://www.sparkfun.com/arduino_guide

Here are two schematics that should help most experienced arduinio/electronics people figure out how we're making. One is a drawing of the connections done with Fritzing, and the other is an electronics schematics of the sensor interface.

Step 2: Solder the Headers

The musical Arduino shield is capable of generating sounds, but first we'll need to set it up so it can take inputs from the physical world and communicate them with the main Arduino board. The first step is to solder on the headers that connect it to the main board.

Step 3: Add Your Resistors

Orient your shield so that you're looking at the side with the components on it, and the text "Sparkfun.com" is right side up.

Place the three resistors next to each other in the center of the prototype area of the Musical Instrument Shield. Place the 39k resistor on the left-we'll call this R1. Place one of the 1k resistors in the middle (R2), and the last 1k resistor (R3) on the right, nearest the audio jack. It helps to spread the legs with two spaces in the middle so that the resistors can lay flat.

Cross over the legs of R1 and R2 on the side closest to the audio jack and solder them together.

Step 4: Add Your Capacitor

Flip the shield over again. Place the capacitor ( C1) above the resistors, just on top of R2 and R3.

Flip the shield to the back, and solder C1 down.

Solder a leg of C1 to the adjacent end of R2.
Solder the other leg of C1 to the adjacent end of R3.

Step 5: Add the Red Wire

Now you will add three wires to the board. To keep them easily identifiable we've used red, white, and black but the color of the wire doesn't matter.

Cut a piece of solid core wire (we used the red one) about 2" long and strip both ends.

Insert one end into board right next to C1 and directly above R1.

Flip over the board and solder that end into place.

Bend down the leg of R1 (the side not connected to R2) and solder it to the red wire.

Step 6: Add the Black Wire

Cut a piece of solid core wire (we use black) about 2" long and strip both ends about 3/8".

Insert one end into the board just above the C1/R3 junction.

Flip the board over and and solder the end into place.

Make a soldered connected to the adjacent C1/R3 junction.

Step 7: Add the White Wire

Cut a piece of solid core wire (we use white) about 3" long and strip both ends about 3/8".

Insert one into the board just above the c1/R2 junction (just to the left of the black wire)

Flip the board over and solder the end of the wire in place.

Make a soldered connection to the adjacent C1/R2 junction.

Flip the board over and Insert the other end of the wire into the header socket labeled "A0" (on the middle right side of the shield).

Step 8: Connect the Wires for the Touch Pads

Cut two pieces of the stranded wire as long as you will need to reach from the shield to where you want the touch pads to go.

Strip back 1/4" on one and insert just below R3.

Flip the board over. Solder the wire in place and make a soldered connection to the leg of R3.

Go back to the front of the board. Strip back 1/4" on the other wire and insert just below R2.

Flip the board over. Solder the wire in place and make a soldered connection to the R1/R2 junction.

Step 9: Connect the Wires to the Touchpads

Now you need to connect the other ends of the wires to your metal touch pads. We soldered them but you can also use bolts, alligator clip leads, or any method you wish. You may want to experiment with different materials and sizes for touchpads using alligator clips before soldering the leads.

Step 10: Check Your Work

Step 11: Mount the Shield on the Arduino

Mount the shield assembly to your Arduino by plugging the stackable header pins into the Arduino's header sockets. There may be more header sockets on the Arduino than on the shield, but it's fine. Those sockets will not be used, and if you look closely, you will see that, due to the gaps between headers, there is only one way to plug it in smoothly without bending any pins.

Check to be sure that the USB connector on the Arduino is not shorting out to the bottom of the shield. If it is, you may need to put some tape in between.

Step 12: Load the Sketch to the Arduino

Plug the USB into your computer and load the SingingSnack sketch on to your Arduino.

If you need help with this go to the guide on the Arduino home page ( http://arduino.cc/en/Guide/HomePage).

Attachments

Step 13: Start Exploring

Plug your headphones, earbuds or powered speakers into the audio jack on the shield.

Touch both pads and start exploring how different types of touch maps to different notes.

If you hold one of the touch pads and a friend holds the other you can make music by touching fingers, shaking hands, or hi-fiving. Experiment with which parts of your body allow more electricity to flow (higher notes equal more conductivity).

Step 14: Tweak the Sketch

If you go into the sketch on the arduino there are a few variables that are fun to play with. We've labeled which variables are the most tinker-able and the ones are probably better left alone (unless you are an arduino master).

#define SIXTEENTH_NOTE_MS (100) - this number changes the fullness and denseness of the arpeggio (a series of notes played in sequence). We've decided to use the arpeggio to make the sound amore "musical"

#define SENSOR_HYSTERESIS (10) - this variable defines how sensitive the device is to changes jn resistance. We dialed this down to 4 to get a more full sound (although it also can produce more 'noise' in the system).

#define LOWEST_NOTE (48)
#define HIGHEST_NOTE (96) - these two variable controls the range in notes that can be played although the highest and lowest notes are usually not used.

#define MY_INSTRUMENT (0) - it's set to the 'grand piano' instrument but it's fun to play around with the numbers (it goes up to 127 to create some interesting sounds and even percussive effects).

You can also change the volume and "strike force" here if your headphones don't have volume control.

If you want to get more in-depth into programming or electronic music feel free to mess around with the sketch and make changes or additions to the code. You may be able to add a digital numerical display to show the levels of resistance, you might try making the music more melodious, or you can add something we haven't thought of yet. Please share your changes and additions with us so we can improve the code.

Step 15: Hack a Bench!

At the exploratorium, we have a prototype cricket computer board running a similar program built in to a normal museum bench. Follow these steps to turn any bench into a fun and social, musical instrument.

Solder a ring terminal to each wire and use it to screw the wire to the covered armrest. If you want you can also solder the wire directly to the copper piece.

Step 16: Keep Playing!

What you've made is really a tool to explore the world around you and create interesting sounds from variations in resistance and conductivity. Keep playing with various materials and household objects, have fun, and let us know what other cool discoveries you make.

# data[].attributes.attachment_link.description
The Musical Bench is an exhibit which makes music when people touch, kiss, or hold hands. It uses a micro-controller to detect changes in resistance, via the copper armrests, and plays high or low notes depending on how much current flows through you and a friend.

# data[].attributes.attachment_link.readable_text
This project is a part of experiments done while doing an artist in residence at Instructables. You can see the other projects here.
You can use bit-shifting as an alternative way of creating "music". This principle enables you to squeeze as much processing power as possible out of the Arduino while creating novel and interesting effects. The challenge lies in composing through bitshifting. This is an example of how such composition could look like:

OCR0A = ((-t&4095)*(255&t*(t&t>>13))>>12)+(127&t*(234&t>>8&t>>3)>>(3&t>>14)); // by tejeez

I have made this box to explore the consequences of changing the different parameters in the pieces. This enables me to see how they effect the overall sound qualities and enables me to prototype new compositions. The different parameters are changed through the 4 potentiometers. One potentiometer to choose the current algoritm and the other potentiometers to change the parameters of it. Although the sounds can be considered crude, it is quite engaging to experiment and play with.

Credits:
This project is based on Duane Banks code. He does a good job on crediting his sources, I want to embed them here for reference: The original tunes were produced by Viznut and by others in response to his original blog post here - The original Arduino port was completed by Arduino Forum user Stimmer. Duane Banks used the synth schematic found in this instructable plus a customized version of the timing functions found in the code. I adopted his code and modified the different algorithms so you can play around with their parameters and get a sense of how it affects the sounds.

# data[].attributes.attachment_link.description
This project is a part of experiments done while doing an artist in residence at Instructables. You can see the other projects here. You can use bit-shifting as an alternative way of creating "music". This principle enables you to squeeze as much processing power as possible out of the Arduino while creating novel and interesting effects.

# data[].attributes.attachment_link.readable_text
The developments since my last post can be summarized by my third video. It still represents the current state of the art quite well and includes a good variety of different types of formulas.

The videos only show off a portion of all the formulas that could be included. To compensate, I've created a text file where I've collected all the "worthy" formulas I've encountered so far. Most of them can be tested in the on-line JavaScript and ActionScript test tools. Some of them don't even work directly in C code, as they depend on JS/AS-specific features.

As I'm sure that many people still find these formulas rather magical and mysterious, I've decided to give you a detailed technical analysis and explanation on the essential techniques. As I'm completely self-educated in music theory, please pardon my notation and terminology that may be unorthodox at times. You should also have a grasp of C-like expression syntax and binary arithmetic to understand most of the things I'm going to talk about.

I've sorted my formula collection by length. By comparing the shortest and longest formulas, it is apparent that the longest formulas show a much more constructivist approach, including musical data stored in constants as well as entire piece-by-piece-constructed softsynths. The shortest formulas, on the other hand, are very often discovered via non-deterministic testing, from educated guesses to pure trial-and-error. One of my aims with this essay is to bring some understanding and determinism to the short side as well.

A class of formulas that is quite prominent among the shortest ones is what I call the 't* class'. The formulas of this type multiply the time counter t with some expression, resulting in a sawtooth wave that changes its pitch according to that expression.

A simple example of a t*-class formula would be t*(t>>10) which outputs a rising and falling sound (accompanied by some aliasing artifacts that create their own sounds). Now, if we introduce an AND operator to this formula, we can restrict the set of pitches and thus create melodies. An example that has been individually discovered by several people, is the so-called "Forty-Two Melody": t*(42&t>>10) or t*2*(21&t>>11).

The numbers that indicate pitches are not semitones or anything like that, but multiplies of a base frequency (sampling rate divided by 256, i.e. 31.25 Hz at the default 8 kHz rate). Here is a table that maps the integer pitches 1..31 to cents and Western note names. The pitches on a gray background don't have good counterparts in the traditional Western system, so I've used quarter-tone flat and sharp symbols to give them approximate names.

By using this table, we can decode the Forty-Two Melody into a human-readable form. The melody is 32 steps long and consists of eight unique pitch multipliers (including zero which gives out silence).

The "Forty-Two Melody" contains some intervals that make it sound a little bit silly, detuned or "Arabic" to Western ears. If we want to avoid this effect, we need to design our formulas so that they only yield pitches that are at familiar intervals from one another. A simple solution is to include a modulo operator to wrap larger numbers to the range where simple integer ratios are more probable. Modifying the Forty-Two Melody into t*((42&t>>10)%14), for example, completely transforms the latter half of the melody into something that sounds a little bit nicer to Western ears. Bitwise AND is also useful for limiting the pitch set to a specific scale; for example t*(5+((t>>11)&5)) produces pitch multipliers of 4, 5, 8 and 9, which correspond to E3, G3, C4 and D4.

Ryg's 44.1 kHz formula presented in the third video contains two different melody generators:

((t*("36364689"[t>>13&7]&15))/12&128)

+(((((t>>12)^(t>>12)-2)%11*t)/4|t>>13)&127)

The first generator, in the first half of the formula, is based on a string constant that contains a straight-forward list of pitches. This list is used for the bass pattern. The other generator, whose core is the subexpression ((t>>12)^(t>>12)-2)%11, is more interesting, as it generates a rather deep self-similar melody structure with just three operators (subtraction, exclusive or, modulo). Rather impressive despite its profound repetitiveness. Here's an analysis of the series it generates:

It is often a good idea to post-process the waveform output of a plain t* formula. The sawtooth wave tends to produce a lot of aliasing artifacts, particularly at low sampling rates. Attaching a '&128' or '&64' in the end of a t* formula switches the output to square wave which usually sounds a little bit cleaner. An example of this would be Niklas Roy's t*(t>>9|t>>13)&16 which sounds a lot noisier without the AND (although most of the noise in this case comes from the unbounded multiplication arithmetic, not from aliasing).

Bitwise waveforms and harmonies

Another class of formulas that is very prominent among the short ones is the bitwise formula. At its purest, such a formula only uses bitwise operations (shifts, negation, AND, OR, XOR) combined with constants and t. A simple example is t&t>>8 -- the "Sierpinski Harmony". Sierpinski triangles appear very often in plotted visualizations of bitwise waveforms, and t&t>>8 represents the simplest type of formula that renders into a nice Sierpinski triangle.

Bitwise formulas often sound surprisingly multitonal for their length. This is based on the fact that an 8-bit sawtooth wave can be thought of consisting of eight square waves, each an octave apart from its neighbor. Usually, these components fuse together in the human brain, forming the harmonics of a single timbre, but if we turn them on and off a couple of times per second or slower, the brain might perceive them as separate tones. For example, t&48 sounds quite monotonal, but in t&48&t>>8, the exactly same waveform sounds bitonal because it abruptly extends the harmonic content of the previous waveform.

The loudest of the eight square-wave components of an 8-bit wave is, naturally, the one represented by the most significant bit (&128). In the sawtooth wave, it is also the longest in wavelength. The second highest bit (&64) represents a square wave that has half the wavelength and amplitude, the third highest halves the parameters once more, and so on. By using this principle, we can analyze the musical structure of the Sierpinski Harmony:

The introduction of ever lower square-wave components can be easily heard. One can also hear quite well that every newly introduced component is considerably lower in pitch than the previous one. However, if we include a prime multiplier in the Sierpinski Harmony, we will encounter an anomaly. In (t*3)&t>>8, the loudest tone actually goes higher at a specific point (and the interval isn't an octave either).

This phenomenon can be explained with aliasing artifacts and how they are processed by the brain. The main wavelength in t*3 is not constant but alternates between two values, 42 and 43, averaging to 42.67 (256/3). The human mind interprets this kind of sound as a waveform of the average length (42.67 samples) accompanied by an extra sound that represents the "error" (or the difference from the ideal wave). In the t*3 example, this extra sound has a period of 256 samples and sounds like a buzzer when listened separately.

The smaller the wavelengths we are dealing with are, the more prominent these aliasing artifacts become, eventually dominating over their parent waveforms. By listening to (t*3)&128, (t*3)&64 and (t*3)&32, we notice an interval of an octave between them. However, when we step over from (t*3)&32 to (t*3)&16, the interval is definitely not an octave. This is the threshold where the artifact wave becomes dominant. This is why t&t>>8, (t*3)&t>>8 and (t*5)&t>>8 sound so different. It is also the reason why high-pitched melodies may sound very detuned.

Variants of the Sierpinski harmony can be combined to produce melodies. Examples of this approach include:

t*5&(t>>7)|t*3&(t*4>>10) (from miiro)

(t*5&t>>7)|(t*3&t>>10) (from viznut)

t*9&t>>4|t*5&t>>7|t*3&t/1024 (from stephth)

Different counters are the driving force of bitwise formulas. At their simplest, counters are just bitshifted versions of the main counter (t). These are implicitly synchronized with each other and work on different temporal levels of the musical piece. However, it has also been fruitful to experiment with counters that don't have a simple common denominator, and even with ones whose speeds are nearly identical. For example, t&t%255 brings a 256-cycle counter and a 255-cycle counter together with an AND operation, resulting in an ambient drone sound that sounds like something achievable with pulse-width modulation. This approach seems to be more useful for loosely structured soundscapes than clear-cut rhythms or melodies.

Some oneliner songs attach a bitwise operation to a melody generator for transposing the output by whole octaves. A simple example is Rrrola's t*(0xCA98>>(t>>9&14)&15)|t>>8 which would just loop a simple series of notes without the trailing '|t>>8'. This part gradually fixes the upper bits of the output to 1s, effectively raising the pitch of the melody and fading its volume out. Also the formulas from Ryg and Kb in my third video use this technique. The most advanced use of it I've seen so far, however, is in Mu6k's song (the last one in the 3rd video) which synthesizes its lead melody (along with some accompanying beeps) by taking the bassline and selectively turning its bits on and off. This takes place within the subexpression (t>>8^t>>10|t>>14|x)&63 where the waveform of the bass is input as x.

Modular wrap-arounds and other synthesis techniques

All the examples presented so far only use counters and bitwise operations to synthesize the actual waveforms. It's therefore necessary to talk a little bit about other operations and their potential as well.

By accompanying a bitwise formula with a simple addition or substraction, it is possible to create modular wrap-around artifacts that produce totally different sounds. Tiny, nearly inaudible sounds may become very dominant. Harmonious sounds often become noisy and percussive. By extending the short Sierpinski harmony t&t>>4 into (t&t>>4)-5, something that sounds like an "8-bit" drum appears on top of it. The same principle can also be applied to more complex Sierpinski harmony derivatives as well as other bitwise formulas:

(t*9&t>>4|t*5&t>>7|t*3&t/1024)-1

I'm not going into a deep analysis of how modular wrap-arounds affect the harmonic structure of a sound, as I guess someone has already done the math before. However, modular addition can be used for something that sounds like oscillator hard-sync in analog synthesizers, although its technical basis is different.

Perhaps the most obvious use for summing in a softsynth, however, is the one where modular wrap-around is not very useful: mixing of several sound sources together. A straight-forward recipe for this is (A&127)+(B&127), which may be a little long-winded when aiming at minimalism. Often, just a simple XOR operation is enough to replace it, although it usually produces artifacts that may sound good or bad depending on the case. XOR can also be used for effects that sound like hard-sync.

Of course, modular wrap-around effects are also achievable with multiplication and division, and on the other hand, even without addition or subtraction. I'll illustrate this with just a couple of interesting-sounding examples:

t>>4|t&((t>>5)/(t>>7-(t>>15)&-t>>7-(t>>15))) (from droid, js/as only)

(int)(t/1e7*t*t+t)%127|t>>4|t>>5|t%127+(t>>16)|t (from bst)

t>>6&1?t>>5:-t>>4 (from droid)

There's a lot in these and other synthesis algorithms that could be discussed, but as they already belong to a zone where traditional sound synthesis lore applies, I choose to go on.

Deterministic composition

When looking at the longest formulas in the collection, it is apparent that there's a lot of intelligent design behind most of them. Long constants and tables, sometimes several of them, containing scales, melodies, basslines and drum patterns. The longest formula in the collection is "Long Line Theory", a cover of the soundtrack of the 64K demo "Chaos Theory" by Conspiracy. The original version by mu6k was over 600 characters long, from which the people on Pouet.net optimized it down to 300 characters, with some arguable quality tradeoffs.

It is, of course, possible to synthesize just about anything with a formula, especially if there's no upper limit for the length. Synthesis and sequencing logic can be built section by section, using rather generic algorithms and proven engineering techniques. There's no magic in it. But on the other hand, there's no magic in pure non-determinism either: it is very difficult to find anything outstanding with totally random experimentation after the initial discovery phase is over.

Many of the more sophisticated formulas seem to have a good balance between random experimentation and deterministic composition. It is often apparent in their structure that some elements are results of random discoveries while others have been built with an engineer's mindset. Let's look at Mu6k's song (presented in the end of the 3rd video, 32 kHz):

(((int)(3e3/(y=t&16383))&1)*35) +

(x=t*("6689"[t>>16&3]&15)/24&127)*y/4e4 +

((t>>8^t>>10|t>>14|x)&63)

I've split the formula on three lines according to the three instruments therein: drum, bass and lead.

My assumption is that the song has been built around the lead formula that was discovered first, probably in the form of t>>6^t>>8|t>>12|t&63 or something (the original version of this formula ran at 8 kHz). As usual with pure bitwise formulas, all the intervals are octaves, but in this case, the musical structure is very nice.

As it is possible to transpose a bit-masking melody simply by transposing the carrier wave, it's a good idea to generate a bassline and reuse it as the carrier. Unlike the lead generator, the bassline generator is very straight-forward in appearance, consisting of four pitch values stored in a string constant. A sawtooth wave is generated, stored to a variable (so that it can be reused by the lead melody generator) and amplitude-modulated.

Finally, there's a simple drum beat that is generated by a combination of division and bit extraction. The extracted bit is scaled to the amplitude of 35. Simple drums are often synthesized by using fast downward pitch-slides and the division approach does this very well.

In the case of Ryg's formula I discussed some sections earlier, I might also guess that the melody generator, the most chaotic element of the system, was the central piece which was later coupled with a bassline generator whose pitches were deliberately chosen to harmonize with the generated melody.

I have been contacted by quite many people who have brought up different ideas of future development. We should, for example, have a social website where anyone could enter new formulas, listen to the in a playlist-like manner and rate them. Another branch of ideas is about the production of new rateable formulas by random generation or by breeding old ones together with genetic algorithms.

All of these ideas are definitely interesting, but I don't think the time is yet right for them. I have been developing my audiovisual virtual machine, which is the main reason why I did these experiments in the first place. I regard the current concept of "oneliner music" as a mere placeholder for the system that is yet to be released. There are too many problems with the C-like infix syntax and other aspects of the concept, so I think it's wiser to first develop a better toy and then think about a community mechanism. However, these are just my own priorities. If someone feels like building the kind of on-line community I described, I'll support the idea.

I've mentioned this toy before. It was previously called EDAM, but now I've chosen to name it IBNIZ (Ideally Bare Numeric Impression giZmo). One of the I letters could also stand for "immediate" or "interactive", as I'm going to emphasize an immediate, hands-on modifiability of the code. IBNIZ will hopefully be relevant as a demoscene platform for extreme size classes, as a test bed for esoteric algorithmic trickery, as an appealing introduction to hard-core minimalist programming, and also as a fun toy to just jam around with. Here's a little screenshot of the current state:

In my previous post, I mentioned the possibility of opening a door for 256-byte demos that are interesting both graphically and musically. The oneliner music project and IBNIZ will provide valuable research for the high-level, algorithmic aspects of this project, but I've also made some

hands-on tests on the platform-level feasability of the idea. It is now apparent that a stand-alone MS-DOS program that generates PCM sound and synchronized real-time graphics can easily fit in less then 96 bytes, so there's a lot of room left for both music and graphics in the 256-byte size

class. I'll probably release a 128- or 256-byte demo as a proof-of-concept, utilizing something derived from a nice oneliner music formula as the soundtrack.

I would like to thank everyone who has been interested in the oneliner music project, as all the hype made me very determined to continue my quests for unleashing the potential of the bit and the byte. My next post regarding this quest will probably appear once there's a version of IBNIZ worth releasing to the public.

# data[].attributes.attachment_link.title
Some deep analysis of one-line music programs.

# data[].attributes.attachment_link.description
The developments since my last post can be summarized by my third video. It still represents the current state of the art quite well and includes a good variety of different types of formulas. The videos only show off a portion of all the formulas that could be included.

# data[].attributes.attachment_link.readable_text
Lately, there has been a lot of experimentation with very short programs that synthesize something that sounds like music. I now want to share some information and thoughts about these experiments.

First, some background. On 2011-09-26, I released the following video on Youtube, presenting seven programs and their musical output:

This video gathered a lot of interest, inspiring many programmers to experiment on their own and share their findings. This was further boosted by non-programmers, I guess) to jump in the bandwagon. In just a couple of Bemmu's on-line Javascript utility that made it easy for anyone (even days, people had found so many new formulas that I just had to release another video to show them off.

It all started a couple of months ago, when I encountered a 23-byte C-64 demo , my mind. My earlier blog post, " Wallflower by 4mat of Ate Bit , that was like nothing I had ever seen on that size class on any platform. Glitchy, yes, but it had a musical structure that vastly outgrew its size. I started to experiment on my own and came up with a 16-byte VIC-20 program whose musical output totally blew findings and speculates why they work. The 16-byte frontier ", reports these

Some time later, I resumed the experimentation with a slightly more scientific mindset. In order to better understand what was going on, I needed a simpler and "purer" environment. Something that lacked the arbitrary quirks and hidden complexities of 8-bit soundchips and processors. I chose to experiment with short C programs that dump raw PCM audio data. I had written tiny "/dev/dsp softsynths" before, and I had even had one in my email/usenet signature in the late 1990s. However, the programs I would now be experimenting with would be shorter and less planned than my previous

I chose to replicate the essentials of my earlier 8-bit experiments: a wave generator whose pitch is controlled by a function consisting of shifts and logical operators. The simplest waveform for /dev/dsp programs is sawtooth. A simple of 256 bytes, resulting in a frequency of 31.25 Hz when using the the default sample rate of 8000 Hz. The pitch can be changed with for(;;)putchar(t++) generates a sawtooth wave with a cycle length produces a rising sound. After a couple of trials, I came up with something that I wanted to share on an IRC channel:
main(t){for(t=0;;t++)putchar(t*(((t>>12)|(t>>8))&(63&(t>>4))));}
In just over an hour, Visy and Tejeez had contributed six more programs on the channel, mostly varying the constants and changing some parts of the function. On the following day, Visy shared our discoveries on Google+. I reshared them. A surprising flood of interested comments came up. Some people wanted to hear an MP3 rendering, so I produced one. All these reactions eventually led me to release the MP3 rendering on Youtube with some accompanying text screens. (In case you are wondering, I generated the screens with an old piece of code that simulates a non-existing text mode device, so it's just as "fakebit" as the sounds are).

When the first video was released, I was still unsure whether it would be possible for one line of C code to reach the sophistication of the earlier 8-bit experiments. Simultaneities, percussions, where are they? It would also have been great to find nice basslines and progressions as well, as those would be useful for tiny demoscene productions.

At some point of time, some people noticed that by getting rid of the part altogether and just applying logical operators on shifted time values one could get percussion patterns as well as some harmonies. Even a formula as simple as interesting harmonic properties. Some small features can be made loud by adding a constant to the output. A simple logical operator is enough for t&t>>8, an aural corollary of "munching squares", has combining two good-sounding formulas together (often with interesting artifacts that add to the richness of the sound). All this provided material for the "second iteration" video.

If the experimentation continues at this pace, it won't take many weeks until we have found the grail: a very short program, maybe even shorter than a Spotify link, that synthesizes all the elements commonly associated with a pop song: rhythm, melody, bassline, harmonic progression, macrostructure. Perhaps even something that sounds a little bit like vocals? We'll see.

Hasn't this been done before?

We've had the technology for all this for decades. People have been building musical circuits that operate on digital logic, creating short pieces of software that output music, experimenting with chaotic audiovisual programs and trying out various algorithms for musical composition. Mathematical theory of music has a history of over two millennia. Based on this, I find it quite mind-boggling that I have never before encountered anything similar to our discoveries despite my very long interest in computing and algorithmic sound synthesis. I've made some Google Scholar searches for related papers but haven't find anything. Still, I'm quite sure that at many individuals have come up with these formulas before, but, for some reason, their discoveries remained in obscurity.

Maybe it's just about technological mismatch: to builders of digital musical circuits, things like LFSRs may have been more appealing than very wide sequential counters. In the early days of the microcomputer, there was already enough RAM available to hold some musical structure, so there was never a real urge to simulate it with simple logic. Or maybe it's about the problems of an avant-garde mindset: if you're someone who likes to experiment with random circuit configurations or strange bit-shifting formulas, you're likely someone who has learned to appreciate the glitch esthetics and never really wants to go far beyond that.

Demoscene is in a special position here, as technological mismatch is irrelevant there. In the era of gigabytes and terabytes, demoscene coders are exploring the potential of ever shorter program sizes. And despite this, the sense of esthetics is more traditional than with circuit-benders and avant-garde artists. The hack value of a tiny softsynth depends on how much its output resembles "real, big music" such as Italo disco.

The softsynths used in the 4-kilobyte size class are still quite engineered. They often use tight code to simulate the construction of an analog synthesizer controlled by a stored sequence of musical events. However, as 256 bytes is becoming the new 4K, there has been ever more need to play decent music in the 256-byte size class. It is still possible to follow the constructivist approach in this size class -- for example, I've coded some simple 128-byte players for the VIC-20 when I had very little memory left. However, since the recent findings suggest that an approach with a lot of random experimentation may give better results than deterministic hacking, people have been competing in finding more and more impressive musical formulas. Perhaps all this was something that just had to come out of the demoscene and nowhere else.

Something I particularly like in this "movement" is its immediate, hands-on collaborative nature, with people sharing the source code of their findings and basing their own experimentation on other people's efforts. Anyone can participate in it and discover new, mind-boggling stuff, even with very little programming expertise. I don't know how long this exploration phase is going to last, but things like this might be useful for a " Pan-Hacker movement" that advocates hands-on hard-core hacking to greater masses. I definitely want to see more projects like this.

How profound is this?

Apart from some deterministic efforts that quickly bloat the code up to hundreds of source-code characters, the exploration process so far has been mostly trial-and-error. Some trial-and-error experimenters, however, seem to have been gradually developing an intuitive sense of what kind of formulas can serve as ingredients for something greater. Perhaps, at some time in the future, someone will release some enlightening mathematical and music-theoretical analysis that will explain why and how our algorithms work.

It already seems apparent, however, that stuff like this stuff works in contexts far beyond PCM audio. The earlier 8-bit experiments, such as the C-64 Wallflower, quite blindly write values to sound and video chip registers and still manage to produce interesting output. Media artist Kyle McDonald has rendered the first bunch of sounds into monochrome bitmaps that show an interesting, "glitchy" structure. Usually, music looks quite bad when rendered as bitmaps -- and this applies even to small chiptunes that sound a lot like our experiments, so it was interesting to notice the visual potential as well.

I envision that, in the context of generative audiovisual works, simple bitwise formulas could generate source data not only for the musical output but also drive various visual parameters as a function of time. This would make it possible, for example, for a 256-byte demoscene production to have an interesting and varying audiovisual structure with a strong, inherent synchronization between the effects and the music. As the formulas we've been experimenting with can produce both microstructure and macrostructure, we might assume that they can be used to drive low-level and high-level parameters equally well. From wave amplitudes and pixel colors to layer selection, camera paths, and 3D scene construction. But so far, this is mere speculation, until someone extends the experimentation to these parameters.

I can't really tell if there's anything very profound in this stuff -- after all, we already have fractals and chaos theory. But at least it's great for the kind of art I'm involved with, and that's what matters to me. I'll probably be exploring and embracing the audiovisual potential for some time, and you can expect me to blog about it as well.

# data[].attributes.attachment_link.title
Algorithmic symphonies from one line of code -- how and why?

# data[].attributes.attachment_link.description
Lately, there has been a lot of experimentation with very short programs that synthesize something that sounds like music. I now want to share some information and thoughts about these experiments. First, some background.

# data[].attributes.attachment_link.readable_text
This is an interesting little project that can be built in minutes. It plays 13 different tunes all of which are generated from a single line of C code, the tunes are selected through four push buttons which have 16 possible combinations, including silence and two free slots for your own music.

The project also includes an 8 LED visualizer that is driven by the same line of code as the music.

About Algorithmic Music

The original tunes were produced by Viznut and by others in response to his original blog post here -

http://countercomplex.blogspot.com/2011/10/algorithmic-symphonies-from-one-line-of.html

The original Arduino port was completed by Arduino Forum user Stimmer and can be found in this post -

http://arduino.cc/forum/index.php/topic,74123.msg558213.html#msg558213

Arduino Forum user Zeni also has an interesting variation which allows the user to enter new algorithms at runtime, this can be seen in action in the forum topic above.

The RCArduino Version adds the ability to select the current algorithm and the 8 LED Visualiser.

The RCArduino Version code and schematic can be found below, if your interested in the theory behind the music or demoscene in general ( http://en.wikipedia.org/wiki/Demoscene ) you can pick up the trail from Viznuts original video linked at the start of this post.

An application in Grain Synthesis ?

One area that would be interesting to apply these techniques is grain synthesis. Grain synthesis is based on repeating a simple grain of sound while adding additional grains, envelopes, oscillators or filters to make the sound more interesting. These operations can be computationally expensive and do not always produce interesting sound. The techniques used to generate the algorithmic music from a simple counter demonstrated by Viznut could also be applied to generating more interesting synthesis grains.

The best known example of an Arduino Grain Synthesizer is the Auduino, its incredible to see that all of the sound generated by an auduino is the result of overlaying just two triangle waveforms. In one of the videos linked below you will see the triangle waveforms interacting together with the rich sound that results.

Examples of built Auduino Synths can be found at the end of this post -
http://rcarduino.blogspot.com/2012/08/adding-audio-to-arduino-projects.html

An interesting development of the grain synthesis would be to combine it with the realtime code upload work of Zeni, it should be possible to create grains that modulate and transform themselves to create a more interesting sound palette.

RCArduino Version - Based on original work of Viznut and original Arduino port of stimmer

// one-line algorithmic music break; break;
// see viznut's blog http://countercomplex.blogspot.com/2011/10/algorithmic-symphonies-from-one-line-of.html
// and http://www.youtube.com/watch?v=GtQdIYUtAHg&feature=related
case 5:
OCR0A = ((t*(t>>8|t>>9)&46&t>>8))^(t&t>>13|t>>6); // by xpansive
case 9:
OCR0A = (t|(t>>9|t>>7))*t&(t>>11|t>>9); // by red
break;
case 10:
long v;
OCR0A = v=(v>>1)+(v>>4)+t*(((t>>16)|(t>>6))&(69&(t>>9))); // by pyryp
break;
case 11:
OCR0A = (t>>6|t|t>>(t>>16))*10+((t>>11)&7); //by viznut
break;
case 12:
OCR0A = (t*(4|7&t>>13)>>((~t>>11)&1)&128) + ((t)*(t>>11&t>>13)*((~t>>9)&3)&127); // by stimmer
break;
case 6:
OCR0A = ((t&4096)?((t*(t^t%255)|(t>>4))>>1):(t>>3)|((t&8192)?t<<2:t)); // by skurk (raer's version)
break;
case 7:
OCR0A = (t>>7|t|t>>6)*10+4*(t&t>>13|t>>6); // by viznut, xpansive, varjohukka
break;
case 8:
OCR0A = t*5&(t>>7)|t*3&(t*4>>10); // by miiro

// ported to arduino by stimmer
// Audio out on pin 10

// Further ported to Interrupt based music generation with 4 button selection of upto 16 algorithms (or 15 + silence on no buttons pressed)
// by Duane B aka RCArduino
//
// Buttons are digital 8,9,10,11, music output is on digital 6
//
// Also added a four LED Visualiser on digital pins 2,3,4,5
//
// Update - LED Visalizer is now 8 bit using digital pins 2,3,4,5 and analog pins 0,1,2,3

#define SAMPLE_MAX (65535.0)
#define SAMPLE_FREQUENCY (8000.0)
#define TIMER1_FREQUENCY 2000000
#define UPDATE_RATE 8000

// by keeping t global we can use it to drive the visualiser as well
long t;

// iterate the grains and LFO
SIGNAL (TIMER1_COMPA_vect)
{
OCR1A += (TIMER1_FREQUENCY/UPDATE_RATE);

t++;

switch(PINB&15)
{
default:
case 0:
OCR0A = 0;
break;
case 1:
OCR0A = ((-t&4095)*(255&t*(t&t>>13))>>12)+(127&t*(234&t>>8&t>>3)>>(3&t>>14)); // by tejeez
break;
case 2:
OCR0A = t*(t>>11&t>>8&123&t>>3); // by tejeez
break;
case 3:
OCR0A = t*((t>>9|t>>13)&25&t>>6); // by visy
break;
case 4:
OCR0A = (t*(t>>5|t>>8))>>(t>>16); // by tejeez

For a simple amplifier circuit to use with Arduino projects see here -

http://rcarduino.blogspot.com/2012/08/adding-audio-to-arduino-projects.html

I am currently working on an Arduino based modular synthesizer with a very different sound, stay tuned

Duane B.

# data[].attributes.attachment_link.description
This is an interesting little project that can be built in minutes. It plays 13 different tunes all of which are generated from a single line of C code, the tunes are selected through four push buttons which have 16 possible combinations, including silence and two free slots for your own music.

# data[].attributes.attachment_link.description
Mads Hobye - interaction design, interactive artist.