The following problem is considered by Bjorklund, in connection with the operation of certain components (such as high voltage power supplies) of spallation neutron source (SNS) accelerators used in nuclear physics.

Construct a binary sequence of n bits with k one’s, such that the k one’s are distributed as evenly as possible among the zero’s. For example, if n = 16 and k = 4, the solution is [1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0]. The problem of primary interest is when k and n are relatively prime numbers, i.e., when k and n are evenly divisible only by 1.

This is an excerpt from the somewhat melodramatically titled paper, The Euclidean Algorithm Generates Traditional Musical Rhythms. In short, sequences generated by the equal spacing algorithm described resemble various traditional rhythms, or otherwise sound pretty good. Create Digital Music did a post on various musical applications of it recently, like this neat little sequencer in flash.

Being a SuperCollider chauvinist I was happy to see Fredrik Olofsson had already written a pattern class to generate these sequences. It didn’t support embedding of patterns within it (which is what I really wanted to play with) but after a quick email to the list he patched it. Thanks Fredrik.

Anyway, here is a quick demo, with code after the jump.

What follows is a very simple example an algorithmically generated piece with some constrained randomness. This isn’t meant to be a tutorial really, but should give you an idea of SC’s general character, and convince you that it’s worth the trouble to work through the documentation.

First, the synthdef code, which is executed by the language interpreter to create instructions for the server specifying a series of unit generators and their interconnections. In other words, this code defines an instrument the later pattern code will “conduct”. There could be many of these, but here we’ll be using just one. If you come from an Ableton/Reason/Softsynth/Moog Modular background you can think of these as a bit like patches, except that you can run as many copies of them as memory and CPU resources allow, and route signals between them arbitrarily. The extreme freedom of which, while cool, makes for an initially somewhat steep learning curve.

Synths created from this synthdef take as arguments an output channel to write to, buffer number (more on this in a moment), frequency (in no particular units, because I was lazy), a gate signal, and duration. Essentially all they’ll do is play the buffer back at varying rates (to get different pitches) and sweep a filter from one frequency to another over the course of each note. These points are controlled by the X and Y (left to right, top to bottom) position of the mouse on screen. The mouse button controls the resonance of the filter, which I should mention is a very nice Moog Ladder emulation available as part of the sc3-plugins package. By wiggling the mouse around I get those acid-housey sweeps to either snap up or downward or plateau over the course of each note. Line 7 takes the mono signal from the playback of the buffer and duplicates it create a stereo signal, adding a bit of random delay to each channel to simulate the movement of the sound in space by precedence effect.

Before starting, the buffer needs to have a sample loaded into it. I used a snippet from this Imogen Heap performance, because I happened to have it around. It would sound much better (or, more positively, better still) with a higher-fidelity sample.

Each buffer loaded by the server has a number, and the variable b will hold the number this sample is assigned. Now the interesting part…

This creates a Pbind object and calls it’s play method (we create a variable, syncopate, to hold it, but we didn’t have to). The words beginning with slashes are key names, which get bundled into events, which are parts of streams which… well, it’s best that you just read the Practical Guide to Patterns if you really want to understand. For the glossed explanation I’m giving here, all you really need to know is that the \instrument parameter specifies which synthdef to use and the rest are passed to the resulting synth. So here we see \bufnum is always set to reference the lone buffer we loaded, scale is passed a major scale from the convenient Scale class’ method, the octave is set to 7, and so on.

The interesting keys are the last three, which define the amplitude (loudness), scale degree (which note, which really means which frequency, which really means which buffer playback speed), and duration for which the synth should run. What sets these apart from the others is that they’re passed Pattern objects, which can return different values each time.

The amplitude is meant to be loudest at the beginning of each beat, with each subsequent note being 90% as loud (the way an echo might decay). This is pretty subtle, and on the demo run above I (unthinkingly) used some compression, so the effect is even less noticeable. Unlike the echo-style decay you can get in most DAWs, we could do things like vary the pitch of every repetition, or have more complicated dynamic (loudness) variations. The outermost pattern, Pstep, is passed two arguments: another object (Pseq) to generate the amplitude values, and a duration. Every time a duration’s worth of time goes by (here, 1/16 of a beat), the next value will be requested from the Pseq pattern. The Pseq has only one element in it’s sequence, a Pgeom, which itself generates a series of values, each of which is a multiple (0.9) of the one before, 16 times (and since we’re moving to the next value every 1/16 of a beat, that means this pattern repeats every beat). This ability to nest patterns within one another is what makes them so flexible and expressive. The Pseq’s second parameter is the number of times it should repeat it’s sequence – here, an infinite number of times.

The degree pattern is very similar – every 4 beats, we transition to the next value from the Pseq (note also that I’m arbitrarily adding 30 to all the results – this is because of my hackish frequency scaling). So we cycle through 4 notes (spelling out a very simple melody), with 4 beats to each note. While the duration pattern described below skitters around, this gives us a bit of structure.

The interesting bit here is the pattern for duration. Duration is a bit of a special case, because while it’s passed to the synths (so they “know” how long they run), it also controls how much time should elapse before the next round of synth creation. While the other two patterns are fixed, and loop through values predictably, this pattern has a random element. The first argument to PdurStutter is a duration, the second is a factor to divide that duration by. If we passed it one and sixteen, we’d get sixteen events lasting a sixteenth of a beat each. Here I’ve used a simple Pseq for the first parameter and a Pwrand for the second. The basical metrical pattern of eight beats – two of two beats and one of four ([2,2,4]) – is set by the first (Pseq) pattern. These time segments are divided by the values from the second (Pwrand) pattern, which chooses randomly from it’s first list ([1/4,1/2,1.5,1,1/3]). The second argument to Pwrand ([10, 15, 1, 1, 1/2].normalizeSum) is a list of weights – so 1/4 is 10 times more likely to be drawn than 1.5 and 20 times more likely than 1/3.

Anyway, when the Pdef starts running PdurStutter first calls the Pseq, gets a duration of 2, and then calls Pwrand and gets, lets say, one half. It would then play four half notes (thus filling the two beats) before moving on to the next element of the pattern, which would have it’s own division factor drawn from the list. Because both the 2 and 4 beat segments are divided up from the same pool of possibilities, you get regular alternation between faster and slower repetitions. Repeat ad Ad infinitum.

All that in two lines of code. Keep in mind that we could have had much more complex patterns for the pitch and amplitude, to say nothing of the possibilities for a more interesting synthdef (you can use patterns compose for every parameter of your synths, and for effects you route them through). For more pattern examples check out the aforementioned Practical Guide to Patterns.

In my spare time I worked on some code to generate animations, which I plan to post over the next few weeks.

This first “sketch” (script, application, etc.) is pretty simple, but I spent a long time tweaking it to get the effect I was after. I took the basic idea from the SomethingAwful-born Blue Ball Machine GIFs (see wikipedia for a bit on the tradition).

Here is a representative output gif, generated with the code below and the very helpful gifsicle utility.

It works like this: The script assigns locations to each circle on each letter’s curve in turn with the Geomerative library, then generates random bezier curve paths between those locations for them to follow. To make things interesting, the algorithm allows coordinates to wrap around from left to right and top to bottom – a toroidal topology, if you prefer math argot. To put that yet another way, adding any integer multiple of the gif tile’s dimension (height/width) to a circle’s target coordinate will make no difference in it’s rendered location, but could make a difference in the direction it goes to get there. So a circle’s target coordinates are generated by taking those produced by Geomerative and adding a random multiple of the tile size (with a random sign) to it’s x and y coordinates. This means a circle can pass through several adjacent tiles in it’s journey between letter forms.

This sample was generated from the code above, which uses Demand UGens to sequence notes/wobble rates on lines 5 and 9. Line 6 adds a bit of slew to the pitch signal, so it glissandos (slides) from note to note, faster up than down for heightened drama.

The signal path for the sound runs: initial synthesis, distortion, filtering, a simple spatialization effect and amplitude enveloping.

The tone is initially made up of a VarSaw oscillator whose width parameter (0 = downward sawtooth, 0.5 = triangle, 1 = upward sawtooth) is “wobbled” by the LFO (line 11). A pure sine wave an octave lower is added to this (line 12). The Decimator UGen distorts this signal by rounding values to an arbitrary degree of precision (i.e. 8-bit, 2-bit, 3.2-bit) as modulated by the LFO. This produces the higher-frequency content of the signal for the filter to do it’s magic on.

The result is a bit like that seething “filthy” sound that’s so popular these days. I’ll probably do a dedicated post on it later, but the trick seems to be several square wave oscillators frequency modulating one another in turn, all through a band-pass filter.

Now that everything is sufficiently noisy it’s run through a nice emulation of the Moog ladder lowpass filter on line 14.

Line 16 splits what has until now been a monophonic signal in to two channels, each of which has a separate delay on it, the values for which are LFO-modulated out of phase with one another (so when one maximally delayed, the other has no delay). This gives the sound some (subtle?) “width” when played with stereo separation, but if you were to play this on a real rig (in mono), there would be destructive and likely undesirable interference muddying up the low end. To dodge this, you could split the signal around 65Hz and only apply delays to the high end before reconstituting it.

The triggered LFO is specified on lines 7-10. Worth noting are the phase angle bounds the Phasor UGen is sweeping through: pi to 2pi – only half of a full sine wave before resetting. Playing with these bounds can produce some interesting variations on the standard wobble.

I’ve really exaggerated the distortion to highlight the character of the sound on headphones or monitors. If you were to produce a track for dance floor use, you’d want to either generate sub-bass separately, possibly raising the line synthesized with decimation an octave or two, or ease up on the distortion; as it stands, this would be kind of weak. Try commenting out line 14 (the filter) before tweaking any parameters.

I wired up a simple astable multivibrator 555 timer circuit (which outputs a series of 5 volt pulses) whose frequency I could control with a potentiometer. I got a 6ft lamp extension cord, cleaved the two wires in two and cut one to put the relay in line.

The primary reason to do the test was to see how much latency the 100 watt incandescent bulbs display at various rates. The bulbs take a little while to get to full brightness after current starts to flow and even longer to become totally dark after it stops. A little bit of this is okay, and the trailing edge will actually produce a neat ghosting effect as the meter falls off. Too much latency though, especially in reaching brightness, will mean a dim top edge to the meter and a disappointing disconnect between sound and visual.

By playing around with rapid pulsing and watching it closely I don’t think it will be a problem. It’s difficult to tell without seeing several of these in a row though, so I’m going to try to measure the brightness curve from the following video and see if I can write a quick simulation (using processing?) of what the completed meter would look like with these bulbs. The camera’s auto-exposure function sensor latency will skew the data a bit, but it should be enough for a rough idea. Alternatively, when I get an oscilloscope (what can’t they do!), I could use a photoresistor to measure the brightness curve more precisely.

I’ve started a photoset for this project here.

This is Patterson Office Tower (POT) on The University of Kentucky campus. It’s home to a small cafe/mezzanine, an obscure mathematics library, and the offices of all the professors and bureaucrats who don’t fit in the endearingly inefficient buildings elsewhere on campus. If, as civil engineers like to say, architecture is the art of wasting space, it’s oft-scorned brutalist style seems to be a good example of what would happen if we eschewed the discipline altogether.

On top of this mercilessly orthogonal concrete form is the broadcast tower of Radio Free Lexington. Despite it’s “dim bulb” 250 watt transmission power, the station currently reaches most of Lexington’s 275,000 or so residents via terrestrial broadcast thanks to the height of the tower and the hill it sits on. The FCC has approved WRFL for an upgrade to 7900 watts, which will let us reach a much larger swath of the central bluegrass.

So I have this idea for an installation I think would work well to draw attention to the station either in celebration of the upgrade or as a means to gather support for it. Following in the steps of the green building hack at MIT and the Blinkenlights Project I’d like to turn POT in to a giant real time volume display of the station’s broadcast.

To be more specific, I want to take a row of windows (or more, as money allows) in the building and place lamps in them to form a vertical bar VU meter. The overall effect will look like the video below, but 16 stories tall and visible from miles away. You could tune in to the station during the evening and watch this huge column of light on the face of POT leap up and down in synchrony with the music. I’m grinning just thinking about it.

How could that be done? Well the Blinkenlights and Green Building projects were both able to run significant amounts of cabling from large power supplies to relays across several stories/rooms. POT is in constant use so cost and difficulty considerations aside we can rule out any scheme involving huge cable lays.

Happily, the signal we want to represent is already available as radio broadcast on every floor. So instead of switching a huge number of lights from a central system, we can put a radio on each floor and have each set of lights switched autonomously in response to the signal it receives.

So the basic plan is to have a simple lamp with, lets say, three 100 watt bulbs in each window. You have a relay (actually, this relay) that can switch the bulbs on and off quickly in response to a low voltage signal. This signal is provided by a simple circuit that detects how loud the signal coming from the radio is, and while it’s above a certain threshold, activates the relay to turn on the lamps. By setting that threshold slightly higher on each successive floor, you’ll get that VU meter effect.

That circuit to sit between the radio and the relay will be an envelope follower and a comparator (probably an LM339). The envelope follower may be as simple as a diode to rectify the signal and a RC low pass filter. The whole apparatus (lamps included) should cost less than $40 (that’s a high estimate) per floor. Assuming we do 16 floors, and a few red ones on the top floor for a cool peaking effect, that’s around $800. Probably less. But let’s say $1000.

I’m currently working on a prototype of a single unit. I’ve already got one of the relays to play around with. The problems remaining are…

• Finding some radios that can run off a wall power supply, yet are cheap and can be had by the dozen
• Designing and testing the envelope follower with an oscilloscope. The big question here is what kind of time constant should be used to prevent flickering but not take too long to fall off.
• Finding good potentiometers for adjusting the threshold of the comparator.
• Packaging all of this, wiring everything safely, and in a duplicable way.

Then it’s just a matter of finding funding and convincing the powers that be (who do you even ask? the building super? each individual office holder?) to let us set it up. It could easily be reused or expanded (add some band pass filters for a frequency analyzer), and different locations provide for some interesting opportunities. For live events, you could use a low power FM transmitter to drive them instead.