The ATSAM conforms to a bewildering selection of MIDI specifications: as well as responding to core MIDI messages, it supports General MIDI, The Roland MT-32 sound set, Roland’s GS MIDI extensions, a bunch of additional NRPN and SysEx controls and its own “DREAM” command set. There are at least three completely different ways to control the device’s master volume, and three more to control per-channel part volumes. Having skimmed the manual a few times, we embarked on a near total rewrite of the Fluxamasynth support library to layer out the various classes of parameter and SysEx change.

The ATSAM’s sound, and voice architecture, are pretty similar to the MT-32: there are some rather wimpy voice-specific low-pass resonant filters, rudimentary LFO and envelope controls, a dual effects processor, built-in parametric EQ and (apparently) sound spatialisation. The sound quality is probably not something you’d want to commit to an album (despite the fact that the MT-32 was a hot studio item in 1987), but it’s pretty impressive from something the size of a lentil.

For testing, we have the Fluxamasynth – essentially the ATSAM chip on a bare-bones Arduino – connected via I2C to an Arduino Mega as “host”, with the Mega running a protocol layer for talking to a MacBook. The Mac side of the link is implemented in Python within MaxMSP, which means we’ve been able to drop the entire thing into Max for Live and play bits of Beethoven and Mozart from General MIDI files directly through to the ATSAM. The tracks sound… acceptable. (The onboard EQ will help a lot.)

Next task: code up some sequences that will work on the music box’s playback disc: 64 steps, 13 pitch rings. That’s not very much Mozart, so quite a bit of manual quantising will be necessary to shoe-horn pieces into a playable form which will last more than four or five seconds.

The audio hardware is a Rev. 1 Fluxamasynth, a bare-bones Arduino board hosting an Atmel ATSAM2195 General MIDI chip with rudimentary onboard effects. The chip interfaces to the Arduino via the standard serial-port library, which makes communication between the board and a host computer a bit of a problem: loading up Arduino sketches works fine, but the serial link is then used for MIDI. (The example code even brings up the link at the MIDI speed of 31.25 Kbaud, which might just be an in-joke; I very much doubt that the synth chip is opto-isolated!)

While it’s probably possible to get USB serial and MIDI serial communications running independently, that seemed like too much fiddling around. Since the Music Box relies on I2C for communication between its components, it made sense to bring up an I2C link between the Fluxamasynth and an Arduino Mega which I happened to have lying around. This was pretty much just a case of loading the Fluxamasynth with a basic sketch which passes all I2C bytes verbatim to the synth chip (I2C is 8-bit clean, so no armouring or wrapping is needed). The Mega uses a modified version of the Fluxamasynth “library” – in reality just a collection of MIDI message formatters – to put completed MIDI messages onto the I2C bus rather than serial. The breadboarding looks rather like this:

Yes, the power, ground and I2C lines to the Fluxamasynth are held in place by miniature G-clamps since I’m in no mood to try and solder up pin strips right now.

The remaining little chunk of work was to knock up a test environment for programming the Atmel and composing some sequences. That was a case of linking some libraries to for the Mega to talk to the MacBook running MaxMSP (reusing bits of code from PEAL and Bobby Sands) and then plugging in a Novation keyboard in order to play notes directly – or rather, slightly indirectly, tunnelling MIDI notes through formatting code in Python, sending them into the Mega, and having it put the MIDI messages on the I2C wire for the Fluxamasynth to pick up and send to the synth chip.

It’s not clear at this stage what the sequence playback engine will do – apart from anything else, the synth chip is multitimbral, suggesting some interesting compositional directions – but we can breadboard that in MaxMSP (or, more sensibly, MaxMSP plus Python). Since we haven’t yet assembled the disc playback hardware, we might port the Max code into Max for Live, and then compose and run sequences from Ableton Live. (These won’t be “real” MIDI note sequences, but virtual sequences where each pitch row is an on/off signalling trace for a specific hall effect sensor.)

This particular application aside, I am still somewhat astonished that the Arduino IDE supports a sizeable chunk of C++ (including inheritance and virtual methods), making the message formatting code pretty clean – I’m sure it’ll do the same for the sequencing engine, once we start to port that from MaxMSP.

I supply..

The acrylic top plate with 12 orange 3mm LEDs and a rotary encoder glued in and wired up (all but the encoder button are soldered) – the one quirk being that I got the blue and purple strands of the ribbon cable out of order… so with the panel face up and micro usb breakout board etching at the bottom the LED configuration is:

12 o’clock – white – anode – MAX7221 22 SegDP/white – common cathode – MAX7221 2 Dig0
1 o’clock – grey – anode – MAX7221 14 SegA/white – common cathode – MAX7221 2 Dig0
2 o’clock – blue – anode – MAX7221 16 SegB/white – common cathode – MAX7221 2 Dig0
3 o’clock – purple – anode – MAX7221 20 SegC/white – common cathode – MAX7221 2 Dig0
4 o’clock – green – anode – MAX7221 23 SegD/white – common cathode – MAX7221 2 Dig0
5 o’clock – yellow – anode – MAX7221 21 SegE/white – common cathode – MAX7221 2 Dig0
6 o’clock – orange – anode – MAX7221 15 SegF/white – common cathode – MAX7221 2 Dig0
7 o’clock – red – anode – MAX7221 17 SegG/white – common cathode – MAX7221 2 Dig0
8 o’clock – white extension – anode – MAX7221 22 SegDP/grey – common cathode – MAX7221 11 Dig1
9 o’clock – grey extension – anode – MAX7221 14 SegA/grey – common cathode – MAX7221 11 Dig1
10 o’clock – blue extension – anode – MAX7221 16 SegB/grey – common cathode – MAX7221 11 Dig1
11 o’clock – purple extension – anode – MAX7221 20 SegC/grey – common cathode – MAX7221 11 Dig1

Last time I had these powered up all the LEDs worked… but I’ve included a bag of spares just in case… I managed to ‘break’ several in the process (I’ve also included these in case it was just me and you can ‘resurrect’ them…).

There’s also a bag with a MAX7221 IC, 10mF and 100nF capacitors and white, flat-top LED – LTW-815C4 – for the power indicator.

I don’t have a TLC5940 at home – but the top plate LEDs would have to be rewired to use it – though I’m not against this in principle if it were to work with I2C… please do advise.

For you to do…

I’m assuming you can provide all the required resistors…

Can you confirm if a TLC5940 can be used with I2C? I’d like to switch back to this if it can…

Ideally I’d like for you to wire this unit up – but in such a way that I can take the top and bottom panels apart later (I reckon I’ll have to separate the Arduino and protoshield?) since I still need to make some adjustments to the mounting of the micro USB breakout boards.

I’ve included my last attempted (but defunct) protoboard to wire up the MAX7221. At least it shows the pins I was trying to use and the positioning of the IC that made the 25mm internal height just about workable for me.

If you can think of ways to reduce the height of this protoshield even more – perhaps to loose the DIP socket and to solder the right angle headers on the ends of the LED directly onto the veroboard I’m sure that’ll help.

The white, flat-top LED – LTW-815C4 – for the power indicator needs to be wired in and should be on when the power bus is attached – there’s a hole in the Alupanel side plate for it.

As for the two micro USB sockets they’re intended for use in either the ‘daisy-chain’ or ‘star’ configuration of the various boxes… though I’m struggling to work out the best way to realise this and would like to discuss my plans with you in more depth.

But I don’t think the winder is the problematic component here so I reckon it’s safe to wire it up with as follows…

for the top (star configuration)

VCC – 5V – direct to board
D- – I2C SDA
D+ – I2C SCL
GND – GND – direct to board

and bottom (daisy chain configuration)

VCC – 5V – from board
D- – I2C SDA
D+ – I2C SCL
GND – GND – from board

In addition…

I’ve also bundled in an Altec Lansing iM237 InMotion speaker – intended as amplification and audio output for the sound module. It runs off 4 x AAA batteries – I measured the collective output of a newly recharged set as 3.80V 3.25A – but have no idea how much current the circuit actually draws.

Will this need to be powered separately by 3 AAA batteries – or can it be powered via the 5V power bus – with a step-down voltage regulator? I’ve included an Adafruit adjustable power supply kit (still to be made up) that could be used for this… and one of the Modular Music Box battery packs, charger and 2 x micro USB B cables for testing…

Can you please look at the iM237 I dismantled in order to mount it inside the sound module but in the process managed to damage by breaking the on-off button. Since it only ever needs to be on is there any chance you can circumnavigate this damaged component and hardwire it to on when power is connected? And can you add a securely attached 3.5mm stereo-jack instead of the mess of a job I made cutting the audio cable and using union connectors…

I don’t mind you dismantling the complete one for reference… so long as it goes back together again

Optimisation? …

For later on once it’s all built and working… but I flag it up now…

I came across this useful hackaday.com article on saving battery life – Sleepy Arduino saves batteries and alternatively how to put the Arduino to sleep to save power… so could we conserve battery life by putting:
- Arduinos in sleep mode?
- MAX7221 in sleep mode?

[UPDATE] Mike responds…

I have built the winder circuit and done a bit of software. In the end I built a new board, schematic attached. I had to use all but 2 of the LEDs as some wouldn’t strip down.

I have also wired up the speaker with a small flying lead and permanently on “switch”. It works fine off 5V.

• rotary sequencer – Arduino Mega 2010 + Adafruit Motor shield – I2C master
• sound module – Fluxamasynth rev1.0 – I2C slave (this to check)
• winder – Arduino Duemilanove – I2C slave
• ballerina praxinoscope – via Adafruit Motor shield
• battery

I’ll start with the ‘Winder’

Three main elements here for integration into a protoshield to sit on a DFRobot.com Arduino Duemilanove clone… :

1. driving 12 orange 3mm LEDs – MV7744 – via a MAX7221 and the LedControl-library – or ideally a TLC5940 if you can get it to work with an I2C bus
2. rotary encoder
3. I2C

Arduino pins

Digi 2 – Encoder – button (interrupt)
Digi 8 – Encoder
Digi 9 – Encoder
Digi 12 – MAX7221 DIN
Digi 11 – MAX7221 CLK
Digi 10 – MAX7221 LOADCS
Analog 4 (SDA) – I2C
Analog 5 (SCL) – I2C
5V
(GND) COMMON GND

1. I referred to the Arduino: Playground The MAX7219 and MAX7221 Led drivers page and used that ‘Wiring and schematics’ diagram…

I calculated the RSet resistor value at ~17k – though it should probably have been 28k according to the table on the page (the MV7744 data sheet list Vf = 2.1V and If = 20mA) – but that’s for an LED matrix not individual LEDs – happy for you to work out what this should be….

2. From details at – http://tronixstuff.wordpress.com/?s=rotary+encoder – used their simple circuit diagram

Used Keith Neufeld’s Arduino Quadrature Encoder Library available here to download – and though initially it didn’t compile… reading further in the post I came across instructions to add:

#undef int
#undef abs
#undef double
#undef float
#undef round

after all the #include statements in the Arduino sketch – and bingo!

Does the rotary encoder need a capacitor? – 0.1uF – suitable for stabilising output – double check this

Also intending to use quistoph’s DebounceButton Arduino library – http://download.bleq.nl/DebounceButton_0.3.zip (link currently not working)⁃ to provide onPress(), onRelease, onHold(), onClick() functionality – which combined with the push button of the encoder could be useful as a ‘hidden’ control system – should we need it…

3. I2C

My colleague Nick discovered the requirements for a common ground for the I2C bus – so we’ll need to plan this into the circuitry of one of the boxes – probably the rotary sequencer?

I’ve attached a zipped folder of component datasheets, arduino library and Nick’s arduino sketches -

‘mmb_winder’ – includes my commented out code after an unsuccessful test with a TLC5940…

‘mmb_12cmaster’ – polls the I2C slave and runs a timer…

Nick’s localised the libraries to make moving files around a bit easier… and he’s added some commenting…

[UPDATE] – Mike responds…

1) Common ground for I2C is provided automatically as you have a common power supply for all modules, so no need to do anything extra.

2) I would strongly recommend that you use this circuit for the rotary encoder:-

The problem is first that they have a lot of contact bounce and trying to suppress this in software and determine the direction of rotation at the same time is a bit of a big ask and normally it won’t work. I don’t know if you noticed but some times the Project sketch would go in the wrong direction at times.

While the Auduino project provides plenty of code tweaks and hardware hacks to make an easy to use but versatile monophonic synth the Modular Music Box requires polyphony…

So I’ve been on a mission to try and find a suitable solution…

A while back I came across and subsequently ordered a Smapler v2 from Arduino-meister David Cuartielles at blushingboy.org – twice in fact – and though I received an email response while he was in Mexico in August my orders have never been processed. The website and shop are still online but his attention must be elsewhere – so I’ve given up trying to get hold of a kit. Shame.

I’ve since contacted the makers of other relevant projects I’ve come across asking if they might be willing to share some resources, insights – and perhaps even some code – including:

• John Gifford’s Arduino based three note polyphonic music box at techroadie – http://www.techroadie.com/myo-make-your-own-roundup-for-september-2009/;
• Seb Tomczack a.k.a. Little Scale – who generally seems to be way out ahead of the pack and single-handedly responsible for most of the ‘must check out’ youtube demos I came across while searching online for making sound and music using an Arduino;
• and Pablo Gian Villamil – Generating polyphonic sound with Arduino – “I have developed a method, using simple voltage-controlled oscillators and the AD5206 digital pot, that allows generation of very nice-sounding musical tones from an Arduino, using a very small number of digital outputs, and requiring very little CPU overhead.”

and Pablo responded and kindly sent me on a link to his notes and code gathered as part of a class on Arduino audio he taught at NYC Resistor.

Independently, I also came across Nicolas Collins’ excellent book Handmade Electronic Music: The Art of Hardware Hacking and Chapter 18 THE WORLD’S SIMPLEST OSCILLATOR: SIX OSCILLATORS ON A TWENTY-CENT CHIP, GUARANTEED TO WORK introduces the 74C14 Hex Schmitt Trigger IC – which turns out to be the sound source for Pablo’s circuitry too.

I’ve had success with Pablo’s examples – though it took me a little while to work out that Serial Peripheral Interface (SPI) on an Arduino Mega uses different pins (SPI: 50 (MISO), 51 (MOSI), 52 (SCK), 53 (SS) – as opposed to 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK) on a Duemilanove/Uno – doh!) – and now have the circuit working with Pablo’s test code to create a 3 voice “microcontroller-based implementation of Steven Reich’s Piano Phase piece, as interpreted by ASDF”. There’s plenty more to explore here too… he developed a series of practical implementations using this technique with lots of interesting functionality.

For more info on SPI there’s Arduino Tutorials on Interfacing a Serial EEPROM Using SPI & Controlling a Digital Potentiometer Using SPI (the basis of Pablo’s project – using an AD5206 Digital Potentiometer to control the 74C14 Hex Schmitt Trigger) and Arduino Reference on the SPI Library.

In the Indices to Pablo’s class notes there’s a series of relevant and intriguing links from uchobby.com. A quick scan of these led me to Paul Badger’s Synth Code and so to Modern Device and so to the Fluxamasynth rev.1 – “a robust synthesizer that can be completely controlled by the on-board Arduino-compatible microcontroller”.

This really does look like it’s exactly what we need – “based on Atmel’s ATSAM2195 single-chip MIDI sound system… has a built-in wavetable with 128 general MIDI sounds and an additional set of 128 variations and dozens of percussion sounds. It can play music in 64-voice polyphony without effects or 38 voices with effects.”

I’ve ordered one and it’s on it way…

I wanted to test the hall effect sensors I’d bought to see if they could be used for my idea of a rotary magnetic sequencer for the Modular Music Box.

There’s a link to the data sheet and a handy Hall_ Applications_Guide.PDF as well as some useful advice on the Sparkfun Hall Effect Sensor page and in the comments… and the Arduino:Playground provided a bit of code to test the sensor in action…

“You’ve got 3 pins from the front (the triangle edge). Left to right, power, ground, output.
Stick a 10k pull up between 5v and output. Then it’ll latch on/off depending on the poll you use.”

Arduino playground – Hall Effect

These are latching sensors i.e. they switch and then stay in that position until the polarity of the magnetic field is reversed and is of sufficient Gauss…

and hey… it works… and with a little additional code I’m now able to turn on and off an LED by moving alternating N & S magnetic poles in front of the sensor (I stuck four in a line onto a piece of Selotape alternating the polarity of each)

Now to find smaller magnets – possibly encoder magnets?

DONE – from http://e-magnetsuk.com/ – 3mm dia x 1mmA, Grade N42 – NiCuNi plated with a Pull (Kg) of 0.2kg

tested and work – at least as a single…but will need to order more – 12 x 64 spoked per disks = 768 – not that it’ll need to play all the notes all the time…

- and design and fabricate a prototype rotary sequencer

started on this… sourced prototyping components/materials at least… and designed layout of various acrylic elements…

but now need to rationalise the circuitry and component layout…

and play head…

The LED calculator helped me to work out the resistor values required for the orange MV7744 LEDs I bought from Mouser – with a forward voltage of 2.1V and diode forward current of 30mA according to the details found at datasheetcatalog.com – is a 1/4W or greater 100 ohm.

I tried to code for an array of 12 hall effect sensors and LEDs – though as Nick suggests we actually need 13 for a full octave – and managed with a couple of online tutorials in arrays in C++ and Arduino ‘for statements’ to develop something that worked – which Nick subsequently shook his head at and then reduced by a half…

But 13 hall effect sensors exhausts the 12 analog ins on the Arduino Mega – so I need to find a way to increase the number of input pins – and I’ve found a number of possible solutions:

[UPDATE] Not true – Arduino Mega has 16 analog ins – so this isn’t required – but still interesting…

• example of using one analog pin to read 5 switches using a series resistor circuit
• Arduino: Playground 4501 – analog multiplexer/demultiplexer – with schematics and code
• Mayhew Labs Mux Shield – which uses three Texas Instruments CD74HC4067 Analog Multiplexers- and is also available at SparkFun for $24.95 – but with an additional 48 analog/digital inputs or digital outputs may well be overkill… though it does have some Analog input example code… so I may just buy the IC

As far as the physical dimensions of the various boxes go I realised quite early on that it’s probably not possible to fit all the components within an internal height of 26mm – so I’m going to use the Golden ratio to help me work out various heights of boxes in the hope these proportions will fit all the components and also be aesthetically pleasing.

The ‘Winder’ in the MMB has a ‘clock face’ of 12 orange LEDs in a circle used to give visual feedback on which way and how much to wind the key… as well as display the ‘winding down’ of the mechanism.

While I could have managed this by using an LED per digital output on the Arduino Duemilanove clone – I thought I’d use it as an opportunity to work with and learn more about LED drivers.

74HC595 Shift Register

I’ve been playing with the 74HC595 Shift Register – which can control 8 LEDs per chip so I’d need two chips – but because the 74HC595 doesn’t current sink I’d also need 12 x 1KOhm 1/4 resistors and 12 BC548 NPN transistors…(or 2 x ULN2003A Darlington Transistors Seven NPN Arrays) which seems a bit too much of an effort. I haven’t managed to get any of the 74HC595 libraries working either (though I haven’t tried adding the code mentioned in the Modular Music Box – Quadrature Rotary Encoder post).

TLC5940

The Texas Instruments TLC5940 is“a 16 channel PWM unit with 12 bit duty cycle control (0 – 4095), 6 bit current limit control (0 – 63), and a daisy chain-able serial interface”. There’s also an Arduino library that makes coding with the TLC5940 very straightforward. – but when I tried to use it in the circuit I had no luck – possibly because it’s for use with common anode LED matrix types? UPDATE – Mike Cook suspects it may be a driver conflict with I2C.

MAX7219 and MAX7221

So looking for alternatives I came across the MAX7219 and MAX7221 LED drivers – “for driving either 64 individual Led’s, or up to 8 digits of 7-segment displays. The drivers implement a SPI compatible slave interface that can be controlled from the Arduino using only 3 of the digital output pins.”

The info is clear and thorough – albeit oriented towards 8×8 LED matrices and 7-Segment displays – but by treating my 12 lead as if they were the first row and a half of an 8×8 LED matrix I was able to control it easily enough.

Controlling a Led matrix or 7-segment displays with the MAX7219 or the MAX7221 outlines “different solutions for driving this popular piece of hardware from the Arduino.”

Since I can foresee using more sophisticated LED, matrices and 7-segment display configurations in the future I chose to use the LedControl-library which “can drive multiple devices and has a specific command-set for 7-segment displays”.

My experience was that there’s a fair amount of configuration involved to get this library to behave consistently… and I frequently found my test blinking sequences ended up with all the LEDs on…

Searching the Arduino Forums and other blog posts helped me piece together a sketch that worked… so I’m posting it in below for reference. I’m not sure if this is just my impatience in not reading the instructions properly – or a lack of clarity in the instructions – probably the former.

I do miss the PWM per channel of the TLC5940 – brightness is global on the MAX722 – but at least it works with the rest of the electronics!

The MAX7221 isn’t cheap either ~£10 from Mouser. An alternative – and cheaper solution – may well be the AS1107 LED Driver IC by austriamicrosystems “compact display drivers for 7-segment numeric displays of up to 8 digits… programmed via SPI…” which apparently works with the existing library.

#include "LedControl.h"

#undef int
#undef abs
#undef double
#undef float
#undef round

/* we have to including the library */
#include "LedControl.h"

/*
* Create a new controler
* Params :
* int dataPin    The pin on the Arduino where data gets shifted out
* int clockPin   The pin for the clock
* int csPin      The pin for selecting the device when data is to be sent
* int numDevices The maximum number of devices that can be controled
*/
//LedControl(int dataPin, int clkPin, int csPin, int numDevices);

/*
* Create a new LedControl.
* We use pins 12,11 and 10 for the SPI interface
* With our hardware we have connected pin 12 to the DATA IN-pin (1) of the first MAX7221
* pin 11 is connected to the CLK-pin(13) of the first MAX7221
* pin 10 is connected to the LOAD-pin(12) of the first MAX7221
* We will only have a single MAX7221 attached to the arduino
*/
//LedControl lc1=LedControl(12,11,10,1);

int DIN = 12;
int CLK = 11;
int LOADCS = 10;
// define the LedControl instance - add more if >8 required
LedControl lc1=LedControl(DIN,CLK,LOADCS,1);    // DIN, CLK, Load/CS, 1 = only one chip MAX chip attached.

int flashDelay = 100;  // delay in MS (1000=1 second)
int ledBrightness = 15;  // range is 0-15.  0=lowest, 15 = full power

void setup()                    // run once, when the sketch starts
{
// mark the three pins for the MAX signals as outputs
pinMode(DIN, OUTPUT);
pinMode(CLK, OUTPUT);
pinMode(LOADCS, OUTPUT);

// take pins out of power save mode.  No updates otherwise.
for(int index=0;index<lc1.getDeviceCount();index++) {
lc1.shutdown(index,false);
}

/*
* Set the brightness of the display.
* Params:
* int addr      the address of the display to control
* int intensity the brightness of the display.
*               Only values between 0(darkest) and 15(brightest) are valid.
*/
//void setIntensity(int addr, int intensity);
lc1.setIntensity(0,ledBrightness  );
/*
* Set the number of digits (or rows) to be displayed.
* See datasheet for sideeffects of the scanlimit on the brightness
* of the display.
* Params :
* int addr  The address of the display to control
* int limit The number of digits to be displayed
* Only values between 0 (only 1 digit) and 7 (all digits) are valid.
*/
lc1.setScanLimit(0, 1);

/*
* Switch all Leds on the display off.
* Params:
* int addr The address of the display to control
*/
//void clearDisplay(int addr);
lc1.clearDisplay(0);
}

void loop()                     // run over and over again
{
//int row = 0;
int chipId = 0;
// for this test I only wired up one row attached to PIN 2 (row 0)
// this is why row is defined as loop scoped and initialised to 0
// you could easily wrap row in another for (int row...) construct
// LED's share +5v/cathode with Anodes on each LED connected
//to pins SegA - SegG

//    for (int row=0; row<=7; row++) {
//  for (int col=0; col<=7; col++) {
//
//      lc1.setLed(chipId, row, col,true);
//      delay(flashDelay);
//      lc1.setLed(chipId, row, col, false);
//      delay(flashDelay);
//    }
//  }

lc1.setLed(chipId, 0, 0, true);
delay(flashDelay);
lc1.setLed(chipId, 0, 0, false);
lc1.setLed(chipId, 0, 1, true);
delay(flashDelay);
lc1.setLed(chipId, 0, 1, false);
lc1.setLed(chipId, 0, 2, true);
delay(flashDelay);
lc1.setLed(chipId, 0, 2, false);
lc1.setLed(chipId, 0, 3, true);
delay(flashDelay);
lc1.setLed(chipId, 0, 3, false);
lc1.setLed(chipId, 0, 4, true);
delay(flashDelay);
lc1.setLed(chipId, 0, 4, false);
lc1.setLed(chipId, 0, 5, true);
delay(flashDelay);
lc1.setLed(chipId, 0, 5, false);
lc1.setLed(chipId, 0, 6, true);
delay(flashDelay);
lc1.setLed(chipId, 0, 6, false);
lc1.setLed(chipId, 0, 7, true);
delay(flashDelay);
lc1.setLed(chipId, 0, 7, false);
lc1.setLed(chipId, 1, 0, true);
delay(flashDelay);
lc1.setLed(chipId, 1, 0, false);
lc1.setLed(chipId, 1, 1, true);
delay(flashDelay);
lc1.setLed(chipId, 1, 1, false);
lc1.setLed(chipId, 1, 2, true);
delay(flashDelay);
lc1.setLed(chipId, 1, 2, false);
lc1.setLed(chipId, 1, 3, true);
delay(flashDelay);
lc1.setLed(chipId, 1, 3, false);

//lc1.setLed(chipId, 0, 0, true);
//delay(500);
//lc1.setLed(chipId, 0, 0, false);

The Rotary Encoder page at SparkFun has a datasheet, tutorials and additional info and advice in the comments:

• though medecau’s QuadEncoder Arduino library doesn’t compile…
• tronixstuff’s Chapter 11 section on the rotary encoder – and the code works well enough – though there’s a fair amount of ‘bouncing’…
• but with a little additional research I managed to get the Reading rotary encoder on Arduino example code to work – and it does seem to provide the most consistent and ultimately useful response to encoder input for my needs.

I had to find out more about Port Registers – “Port registers allow for lower-level and faster manipulation of the i/o pins of the microcontroller on an Arduino board” – with it’s associated pros and cons – and then find the necessary implementation for the Arduino Mega – and the Arduino: Forum Pinout for Port Registers on Arduino Mega?? post provided useful links to an online spreadsheet, mega schematic and PIN MAPPING ARDUINO MEGA.jpg as well as the DIYdrones.com Mega internal registers map post which helped me work out that the code on a vintage Atmega168-based Arduino Pro :

]
/* Rotary encoder read example */
#define ENC_A 14
#define ENC_B 15
#define ENC_PORT PINC


becomes – on an Arduino Mega

/* Rotary encoder readRotary encoder read example */
#define ENC_A 97
#define ENC_B 96
#define ENC_PORT PINF


though seemingly it only works on these pins – so I have more to find out here??

There’s further development of this code within the comments – but it’ll take more than a cursory cut and paste to get it working… though I definitely need to work more thoroughly on the various posts tagged ‘Encoder’ at Arduinoos to make the most of this approach and the code examples…

These issues aside I did manage to integrate this code with the 7-segment display example I was working on earlier to create a dual display which displays entries from the charset_7seg.h array when turning the encoder – at least when the Serial Monitor is open – albeit that it behaves a little idiosyncratically…

The Arduino: Playground has a Reading Rotary Encoders page with info and various coding examples – including using interrupts which I’ve implemented before in my Auduino switch – but I can’t seem to get any of the example code to work with my encoder… and likewise an Arduino + rotary encoder post on the SparkFun forum… and likewise code found at the Hifiduino Arduino Code for Rotary Encoder post and in the Comments… hmmm… (a simple analogRead() of a pot on Analog In 2 & 3 shows they are working)…

…but it turns out my total der brain isn’t!… I tried SunboX’s RotaryEncoder v0.9 library posted in the Arduino: Forum max with a rotary encoder post on the Mega PWM – NOT Analog – pins 2,3, & 4 and it works… and later in the post came across Keith Neufeld’s Arduino Quadrature Encoder Library available here to download – and though initially it didn’t compile… reading further in the post I came across instructions to add:

#undef int
#undef abs
#undef double
#undef float
#undef round


after all the #include statements in the Arduino sketch – and bingo!

My Rotary Encoder now works perfectly for my needs using this library – in conjunction with the DebounceButton library for the button press…

I may now revisit some of the code examples above and try them on the PWM pins

Things have changed since this early list and I’m sure I haven’t taken everything into account – the LVBoost now in the battery pack is probably only running at ~60% efficiency for a start – but here’s my initial working out for the record…
Power Requirements

Battery

• Standard Discharge Current 0.2C5A Max Discharge Current 2.0C5A

1 x LVBoost

• typical Quiescent current .4mA max 1.310mA
• input 3.7v – max output 800mA ??

Animation Turntable - total 72mA – 600mA motor

1 x 3.6V KH39EM2-851 stepper motor – 60rpm – use microstepping?

• 0.6A/phase – 2 phase

1 x white LED

• nominal 20mA max 30mA
• Voltage forward typical 3.3 max 3.8

1 x 120 Ohm resistor

• 42mA

Winder – total 1039mA

• if 10mA less per MV7744 = 10mA x 12 = 120mA
• but actually because of multiplexing – PeakCurrent=(8 x LedCurrent) + MAX72XX-Supply = ~170mA

so adjusted total – 240mA

1 x Arduino Duemilanove clone

• DC Current per I/O Pin – 40mA

1 x rotary encoder

• Rating: 1mA/10VDC
• Push-on Switch Rating: 10mA/5VDC

2 x 74HC595 shift register OR 1 x Max7221

• 74HC595 quiescent supply current min 5.5μA max 160μA
• Max7221Operating Supply Current – 330mA

12 x orange LED MV7744

• DC forward current – 30mA peak forward current – 160mA
• Forward voltage typical 2.1V max 2.8V

12 x 220 Ohm resistors

• 23mA (x 12)

1 x white LED

• nominal 20mA max 30mA
• Voltage forward typical 3.3 max 3.8

1 x 120 Ohm resistor

• 42mA

Sound Module - 72mA

1 x Arduino Mega clone OR 1 x Arduino Duemilanove clone

• DC Current per I/O Pin – 40mA

1 x white LED

• nominal 20mA max 30mA
• Voltage forward typical 3.3 max 3.8

1 x 120 Ohm resistor

• 42mA

2 x AD5206 digital pot

• Positive Supply Current Typ 12μA Max 60μA

1 x MM74C14 Hex Schmitt Trigger

• Output Sink Current 3.6mA

capacitors?

Rotary Sequencer - 1246mA – 600mA motor

⁃if 10mA less per MV7744 = 10mA x 12 = 120mA

• but actually because of multiplexing – PeakCurrent=(8 x LedCurrent) + MAX72XX-Supply = ~170mA

so adjusted total – 727mA

1 x Arduino Mega clone

• DC Current per I/O Pin – 40mA

1 x AF Motor Shield

• ?
• L293D Total Quiescent Supply Current (pin 10) Typ. 16mA Max. 24mA
• L293D Total Quiescent Logic Supply Current (pin 20) Typ. 44mA Max. 64mA

1 x 3.6V KH39EM2-851 stepper motor – 2 rpm

• 0.6A/phase – 2 phase

13 hall effect sensor

• Supply Current 50mA

13 x 3mm Orange LED MV7744

• DC forward current – 30mA peak forward current – 160mA
• Forward voltage typical 2.1V max 2.8V

13 x 220 Ohm resistors

• 23mA (x 12)

I2C Bus

?

1 x LVBoost

• .4mA

1 x Adafruit Breadboard Power Supply

• ?
• MIC2941 regulator has guaranteed 1.25A output

1 x white LED

• nominal 20mA max 30mA
• Voltage forward typical 3.3 max 3.8

1 x 120 Ohm resistor

• 42mA

Total Amperage

1111mA @ 5V = 5.56W

+ 2 x motors at .6A @ 3.7 = 4.44W

(Ah) = Device’s Wattage (W) x Time to run ( Hours) / Battery Voltage (V)

So assuming the Modular Music Box is fully operational for 2 hours per day (and idle/in sleep mode otherwise)

(Ah) = 10 x 2/ 3.7 = 5.4

While for testing purposes the Polymer Lithium Ion Battery – 2000mAh sku: PRT-08483 and LiPoly Charger – Single Cell 3.7-7V Input sku: PRT-00726 may do… further reading of Comments and datasheets suggests they may not be a final choice.

Cons

• ~6hrs charging a 2000mAh battery at 280mA max
• JST connectors can be *extremely* difficult to remove!

Pros:

• Battery includes built-in protection against over voltage, over current, and minimum voltage.
• useful 3 connectors – one to battery, one to circuit, third for 5V that powers the charger – so can charge the battery and power device at the same time.
• through holes in the PCB for remote LED

So looks like we’ll need something more like:

• LiPoly Fast Charger – 5-12V Input – sku: PRT-08293 – $19.95
• Polymer Lithium Ion Battery – 6Ah – sku: PRT-08484 – $39.95
• Wall Adapter Power Supply – 5VDC 1A – $5.95 – a 5V regulated power supply – although it has a US plug.
• Jumper Wire – JST Black Red – $0.95

which seems a bit expensive all in… particularly since we’ll require two battery packs – one in use and one on charge…

One answer to an Instructables post Where to find a small form factor 12v Battery? led me to US based BatterySpace.com who have a bewildering range of batteries and chargers and useful information on How to estimate  battery pack’s running time… Units such as their Polymer Li-Ion Battery: 3.7 V 5Ah ( 18.5Wh, 6.0A rate) – UN Approved (NDGR) at $32.95 with a Smart Charger (1.8A) for 3.7V Li-ion/Polymer Rechargeable Battery Pack–UL listed at $16.95 – to recharge the battery pack in about 4.1hours seems like a more affordable and effective solution.

I couldn’t find a UK or European supplier for Polymer Li-Ion batteries of this spec and size – PMBL Limited supply OEM batteries and not singles and www.all-battery.com – a French company with UK office – had a helpful Customer Service but nothing like the range of BatterySpace.com.

Now to work out the Modular Music Box’s power consumption and running time using a 3.7v 5Ah battery using the AA Portable Power Corp.’s guide…

and buy suitable step-up and step down voltage regulators to test – such as:

• LVBoost – £16.20
• DE-SWADJ Switching Variable Regulator 1A – ~£15
• Adafruit Adjustable breadboard power supply – $15

While worth buying to test the Adafruit Motor/Stepper/Servo shield and get some hands-on experiments done I suspected the Solarbotics GM17 might not be the best motor for the job(s) in the Modular Music Box – requiring +9V, having little torque at low speed and being quite noisy – though it is quite compact and did just manage to fit centrally in the monome size casing alongside an Arduino Duemilanove clone…

Further research suggested that a stepper motor would be the best choice to drive the sequencer and animation turntables. In the interim I tested a stepper motor from Fab Lab Manchester – the six wire PF35T-48L4 – a 7V (though it will supposedly run as low as 5V) 20ohms UNIPOLAR, S/A 3.6deg stepper motor. The makingthings.com Stepper Motor How-tos helped me identify the yellow and orange as one pair, the black and brown as the other and the red and green wires as the center taps.

A search for potential UK suppliers led me to EMS (Electro Mechanical Systems) Ltd whose thorough online documentation and helpful sales team enabled me to select a Nidec Servo Corporation KH39EM2-851 bipolar phase stepper motor – which at 39mm square and just 20.8mm thick and a 3.6V operating voltage seemed to be the optimal model – and it was in stock and £36 + VAT with free postage – result. It certainly seems a solid, quality piece of kit…

Issues to resolve are whether with a 3.6V rating it will actually run with the Adafruit Motor/Stepper/Servo shield – designed for motors 4.5V and upwards… and how to power this with a consistent 3.6V supply – perhaps directly off a LiPo 2000mAh 3.7V battery?

The Adafruit FAQ is non-committal:
“Can this shield control small 3Vmotors?
Not really, its meant for larger, 6V+ motors. In theory you should be able to get it working with 3V motors but I have no information on how to do so or whether it will work.”

Searching for alternative shields/boards that might work with 3.6V motors offers limited options:

• possibly the Arduino Motor Shield (Kit)
• a non Arduino based – Basic 2 Channel 2A Motor Controller Board

A more in-depth search through the RobotShop Stepper Motor Controllers page might be called for…

• CMOS Hex Schmitt Trigger Inverter Integrated Circuit (74C14) or CMOS Quad NAND Gate Schmitt Trigger Integrated Circuit (CD4093) (on the board but not using it 4093 – 4093B Quad 2-input Schmitt trigger NAND gate – http://www.doctronics.co.uk/4093.htm)
• CMOS Binary Counter/Divider (CD4040)
• AD5206 – 6-Channel Digital Potentiometer – Controlling a Digital Potentiometer Using SPI
• various capacitors – 4–10uf. .1uf, 10uf
• 1MOhm pot
• LDRs

Google searches on theme uncovered several things of interest…

heuristicmusic’s posterous – 74C14 Square Wave Oscillator – “This weekend, I started working with Nicolas Collins‘ excellent book Handmade Electronic Music (Routledge ISBN: 978-0-415-99873-4). One of the more intriguing projects in the book is an amazingly simple, inexpensive square wave oscillator based on a $0.75 74C14 CMOS Hex Inverter chip.”

Nicolas Collins – Handmade Electronic Music – The Art of Hardware Hacking
http://www.amazon.com/Handmade-Electronic-Music-Hardware-Hacking/dp/0415998735/ref=sr_1_1?ie=UTF8&s=books&qid=1257730334&sr=8-1

PROJECT CIRCUIT DESIGN – Square Wave Generator Using CMOS 74C14 Single Integrated Circuit Chip (popup window hell!)

Moray McLaren – We Got Time
http://www.youtube.com/watch?v=j9e38cuhnaU&feature=related

Moray McLaren – We Got Time – Behind the Scenes
http://www.youtube.com/watch?v=hrBnH6LIGtA&feature=related

I bought a small 3-4.5V DC motor to start testing for the rotary magnetic sequencer I’m planning as part of the Modular Music Box for the Analogue is the new Digital exhibition as part of AND Festival…

Todbot’s Bionic Arduino: Introduction to Microcontrollers with Arduino: Class 3 has a section on Controlling a Motor using a 1N4001 ‘kickback’ diode and TIP120 transistor to “control speed of motor with analogWrite() just like controlling brightness of LED” which I still need to try out.

Then there’s a fairly thorough post at Lucky Larry’s ARDUINO, MAINLY ARDUINO PROJECTS, TUTORIALS… AND A FEW OTHER THINGS blog – Control a DC motor with Arduino and L293D chip… but (sigh)… I think I’ll just buy a shield kit.
Most immediately useful and affordable via freeduino.org and Arduino: Playground: Interfacing with Hardware: Physical/Mechanical: Motor Control are the:

• Adafruit Motor/Stepper/Servo Shield for Arduino kit – v1.0 – $19.50 – with instructions, examples, and other documentation.
• Also came across the ‘official’ Arduino Motor Shield (Kit) – $25.00 – at FunGizmos
• and the Ardumoto – Motor Driver Shield – $24.95 at SparkFun
• though I may well try the SensorAktor-Shield which will give me the functionality I need and more… although it doesn’t seem to be available to buy… hmmm… perhaps I’ll contact Martin Nawrath, nawrath@khm.de as advised – and maybe I can buy the PCB at least.

In the end I plumped for the Adafruit Motor Shield which seemed most full-featured and best value for money per number of motors/steppers/servos it can actually drive simultaneously:

• 2 connections for 5V ‘hobby’ servos connected to the Arduino’s high-resolution dedicated timer – no jitter!
• Up to 4 bi-directional DC motors with individual 8-bit speed selection (so, about 0.5% resolution)

• Up to 2 stepper motors (unipolar or bipolar) with single coil, double coil, interleaved or micro-stepping.

Though I had a fairly cursory look over the specs and admit to a bit of a ‘suck it and see’ approach… Adafruit’s documentation, FAQs, make it guides and forums turned out to be thorough and a really useful resource…

It came as a kit which I managed to solder up easily enough… though I wish I’d incorporated at least some shield stacking headers instead of just the standard male headers so I can get access to those pins not used by the shield – all 6 analog input pins (can also be used as digital pins – #14 thru 19) and digital pins 2 and 13 (+ more if motors/steppers aren’t being driven). While my Screwshield makes these available for testing it does make it all a bit too bulky for the Modular Music Box so I reckon I’ll have a go at replacing some of the headers – which means I can try out my new ‘solder sucker’ tool too

I installed the library and got the Solarbotics GM17 motor I’d bought working easily enough – and with 38mA unloaded current and 738mA stall current at 9V it’s well within the L293D chipset’s 0.6A per bridge (1.2A peak) 4.5V to 36V specs. Initially I powered both the Arduino and shield from a single 9V 300ma PSU… though subsequently from various power combinations including the shield from an external 9V 1100ma PSU and the Arduino from USB or a 4AA NiM-H battery pack… all with relative success…

And the GM17 behaves as expected – approx 45RPM at 9V – and down to about 12% speed (30 out of a 255 scale) before it failed to turn – though at this power it has very little torque… I’ve since discovered from the FAQs that the shield is meant for 6V+ motors – and the GM17 operates between 3-9V – so I’m not really surprised…

While the Solarbotics site also lists a useful looking Motor Bracket, Encoder – incorporating driver and 51:1 and 104:1 Rome Gears for the GM17 I now suspect it will not actually be the motor for the rotary sequencer though it may well do the job for the praxinoscope style animation.

And I hadn’t considered the amount of noise it makes – an issue Elliot Woods of Kimchi & Chips raised…

I’m now also wondering whether it’s going to be possible to deliver sufficient power to the motor(s) without using an external power supply – having conceived this project as modular but ‘self-contained’…

Next step is to fabricate a simple mount and develop the control code – perhaps using a hall effect sensor and a couple of magnets, the 12 step rotary encoder I bought and a couple of the seven-segment LED displays to display the RPM?

And test alternative DC and stepper motors from Fab Lab Manchester…

And look for alternatives online…

Rotary Magnetic Sequencer

mounting

• walnut box – sides + base – (same dimensions as monome?)
• subtle Art Nouvea/William Morris style laser etching embellishment?
• top panel – Alupanel® aluminium composite (can this be cut on the Fablab laser cutter? – NO)/translucent acrylic
• playback head – to hold 12 x hall effect sensors, 12 x 10k(?) resistors, 12 x 3mm orange LEDs, 12 x 150 Ohm resistors – double check resistor value for multiple LEDs in parallel – cabling
• melody disks – 64 step – 12 x 3mm x 1mm disk magnets per step – 3 layers of 1mm clear acrylic – edge clips to fold three layers together? have Illustrator prototype template

electrical components

• 2 x SchmartBoard 201-0001-01 T.H. 0.1″ SPACING WITH 0.05″ OFFSET, 2″ X 2″ GRID – needs to be cut to size
• Headers & Wire Housings 16 CON LOW PROFILE STR BRDMNT SKT
• Arduino Mega (12 x analog in for hall effect sensors)
• 140 piece hook-up wire set/6 or 12 strand ribbon cable
• 12 x 3mm orange LED
• 12 x 10k resistor
• 12 x 100 Ohm resistors – double check for value for multiple LEDs in parallel
• 1 x TLC5940
• stepper motor (to source)
• Adafruit Motor/Stepper/Servo shield (have)
• 1mm translucent acrylic/2mm clear acrylic
• 3mm x 1mm disk magnets (have 100 – need to buy more)
• 9V PSU – amperage? what’s best for motor control/limits of shield – higher voltage?

software

• Adafruit Motor/Stepper/Servo shield library
• TLC5940 library

notes

• Unit height? Monome is 37mm tall outside edge wooden box – has a 5-6mm aluminium top plate and I suspect 3mm wooden baseplate – so I reckon internal height is ~28mm – so with a 3mm top and base plate we could manage 31mm internal height – if we can fit it all in… 2 x 3mm acrylic internal top and base plate, 25mm spacers with recessed screws should be OK
• cabling in – power, 2 cables from encoder in Winder
• cabling out – 2-4 cables to motor in Ballerina Praxinoscope, 5V + GND to encoder in Winder
• input from hall effect sensors – is the synth run on this Arduino Mega? Or is data sent to second Arduino? If so how to communicate between Arduinos – I2C?

Sound Module

mounting

• walnut box – sides + base – (same dimensions as monome?) – Art Nouvea/William Morris style laser etching embellishment?
• top panel – Alupanel® aluminium composite (can this be cut on the Fablab laser cutter?)/translucent acrylic – design of speaker holes to match rotary magnetic disks
• aluminium knobs ?

electrical components

• deconstructed Lava iPod Travel Speaker
• PSU or batteries for Lava iPod Travel Speaker
• power switch(es) (DIP switch?)
• Arduino Duemilanove or clone?
• 4 x 4.7k linear rotary pots
• audio out socket
• short stereo mini-jack to mini-jack cable

software

• Auduino – though this isn’t polyphonic

notes

• **need to pursue research on polyphonic audio from Arduino – don’t have a suitable solution yet

Ballerina Praxinoscope

mounting

• walnut box – sides + base – (same dimensions as monome?) – Art Nouvea/William Morris style laser etching embellishment?
• top panel – Alupanel® aluminium composite (can this be cut on the Fablab laser cutter? – NO)/translucent acrylic
• 10” acrylic disk
• animation sequence printed out on adhesive backed vinyl?
• praxinoscope mirror – make

electrical components

• Solarbotics GM17 motor (have)
• Adafruit Motor/Stepper/Servo shield (have) – in Rotary Magnetic Sequencer

software

• Adafruit Motor/Stepper/Servo shield library

notes

• test software for Olly Venning – take an image sequence in a folder and display as a virtual praxinoscope?
• will need to stretch/distort Olly’s animation frames to the slices on the praxinoscope disk

Winder

mounting

• walnut box – sides + base – (1/4 dimensions of monome?)
• top panel – Alupanel® aluminium composite (can this be cut on the Fablab laser cutter?)/translucent acrylic
• disk – translucent/clear acrylic/aluminium – glued to custom-cut push fit 6mm acrylic rotary encoder shaft mount
• handle – free rotating (not quite sure how to realise this?)
• display – 12-bar orange bar led display/12 x 3mm orange LEDs

electrical components

• rotary encoder – have a 12 step with button unit
• capacitors – 0.1uF – suitable for stabilising output from rotary encoder – double check this
• resistors – 12 x 150 Ohm – double check for value for multiple LEDs
• 2 x 74HC595 Shift Registers or 1 x TLC5940

software

• Quadrature library
• DebounceButton library

notes

• The push button combined with the DebounceButton library provides onPress(), onRelease, onHold(), onClick() functionality – which could be useful for a ‘hidden’ control system – should we need it…

We’ve been invited to contribute to the ‘Analogue is the new Digital’ exhibition as part of the AND Festival in Manchester in October ’10. It’s a modest fee of £400 and Nick and I are still deciding what work we could produce.

We’ve proposed a couple of ideas i response to the brief… attached as a PDF - analogue-digital

1. The Underwhelming Zoetrope

We propose building a traditional zoetrope – or perhaps its successor the praxinoscope (which improved on the zoetrope by replacing its narrow viewing slits with an inner circle of mirrors).

The physical device will be hand wound, traditionally styled and embellished with Victoriana design elements and features – an essentially faithful reproduction of the popular parlour toy of its era.

But instead of producing content traditionally associated with the zoetrope – such as the chronophotographic sequences of animal locomotion captured by Eadweard Muybridge – we intend to make a series of subtle and downbeat animations that “reflect the omnipresence of computers and digital devices within society” e.g. the blinking of LEDs on a wireless router, the flashing screen and vibration of a mobile phone responding to an incoming call.

We’ll print a series of these animation strips and spread them on the table top next to the zoetrope so users can swap and view them in the device and also take them away as souvenirs.

We think the piece will establish a thought-provoking internal dialogue by disengaging the delivery system from the content, separating them temporally and then contrasting the traditional analogue “device of wonder” with contemporary design evoking digital ubiquitousness and mundanity.

We’re also thinking about providing some blank templates – so users can hand draw their own contribution – and perhaps developing a simple desktop or online application that will enable motivated users to contribute personal animation strips from their own sequence of images.

2. The Modular Musical Box

We propose building a modular version of the traditional musical box – possibly including a representation of a dancing ballerina automaton – inspired by the minimalist controller design of monome.org. The piece will consist of several interconnected, “plug’n’play” boxes which will collectively reproduce the functionality of the decorative 19th century clockwork musical instrument.

At the centre of the piece will be an electro-magnetic rotary sequencer – with a ‘playhead’ made up of a line of hall effect sensors and a revolving spindle on which is placed a clear acrylic disk embedded with small magnets arranged in a regular circular grid – replacing the set of pins on the revolving cylinder that plucks the tuned teeth of a steel comb in the traditional device.

We’ll also build additional units: a self contained and ‘tweakable’ sound source (to hear the musical output); a clockwork-like winder (to spin the disk and “play” the melody);  and time-allowing – a persistence of vision (POV) display (to display the ballerina).

These modular components  will draw on monome’s minimalist design aesthetic and utilise the same restricted material palette of walnut, brushed aluminium, translucent silicon and orange LEDs. All the necessary power, electronic components, Arduinos and shields will be hidden within the various boxes which will be ‘daisy-chained’ to each other via single USB cables.

We’ll make a series of interchangeable disks which will each play a different melody – probably of populist TV show themes and adverts for ubiquitous brands.

The work raises issues of the commodification of music as branded sonic indent while attempting to recapture something of the sense of craft and workmanship, refined aesthetics and genteel appreciation of the iPods of their day – refocussed through the minimalist design aesthetic and tactile ergonomics of the monome.

We consider that the work explores exhibition themes such as the “materialisation of data”, “the tactile digital” and the “invisibility of technology” but we do acknowledge we’re proposing essentially digital devices – albeit styled as analogue ones – and this is not strictly in the spirit of the brief. So we suppose we’re proposing our own counterpoint to the theme – “Digital is the new Analogue!”

Development for  the Modular Music Box should really have been posted from May ’10… and for PEAL @ Kinetica Art Fair 10 from Jan ’10…

Better late than never…

One particular area of concern has been the design and construction of the eight ‘bell posts’… and with budget tightening and schedule contracting we were keen to make sure this was one aspect of the project that didn’t get squeezed too far. The bell posts are the main physical manifestation of PEAL – the sculptural and physical elements of the piece that the audience interact with ‘up close and personal’ – and so we want to make sure they have the design aesthetic and quality of build we’re aiming for with the project overall.

Nick and I approached several designers and fabricators through out mutual networks and have now engaged with Duncan Fitzsimons - a graduate of the MA. Industrial Design Engineering, Royal College of Art and a member of Vitamins design – a multi-disciplinary design collaborative based in London.

Duncan has since produced a “Proposal for tower designs” and Nick and I have been discussing the various options… general agreement so far being:

• we like the aluminium extrusion most – ideally with the vertical pole a circular Cleanroom Profile and thicker than the horizontal spines (possibly made from Series 25 square profile cut to length and machined at each end to a radius to fit the pole and acrylic pot);
• definitely want two contact points per tube;
• the Muji clear acrylic pots at the ends for component mount seem OK;
• looking for a design in kit form – so that we can have something which bolts together easily;
• we’re going to prioritise building the frames and mounting the electronics – the choice of material and construction for the diffuser can wait since whatever the solution it’ll be mounted somehow between the acrylic pots;
• diffusers – budget allowing we prefer the acrylic tube - not very keen on the Muji translucent cups or the fabric – and specifically the spinnaker nylon – but perhaps lycra under tension might create the clean line effect we’re looking for;
• the details of how the electronics are fitted within the acrylic pots is important for the final visual aesthetic… choosing to ‘reveal’ the electronics… an idea we still like…  means they have to look good too.

Malcolm Garrett, RDI – Creative Director at Applied Information Group (AIG) has been developing the PEAL branding and graphic design for the ‘monitor’ output – and though still in development we think its circularity and clean, minimal vector aesthetic and historical font are right on tip. There are a series of variations for each of the installation modes: idle (above); self play, guided play, performance and timepiece.

L: I’m pretty certain that the bells increase regularly in size clockwise – and if we’re going to use these graphic circles as placing for the ‘bell posts’ which actually represent the rope for a specific bell – and the same bell no matter what mode – then I wonder if the circles shouldn’t just increase regularly in size clockwise? I appreciate this might not look graphically so great? Also we might in certain modes switch the letters for Arabic numbers – the bells are numbered 1- treble (smallest bell) to 8 – tenor (largest bell)…”

M: I’ll revise.  Randomness looks good, but isn’t strictly accurate I realise.  Using numbers as well is no problem.

L: …and there’ll be some text to display too… though not on screen all the time… one example for ‘self play’ might well be:

“In the year 1742 the old Peal of Six Bells in the Parish Church of Leeds was augmented to Eight by Mr Harrison of Barrow in Lincolnshire and on June 30th in the same year was Rung on those Bells 5040 Grandsire Tripples in 3 hours and 8 minutes by the following persons:

1    Thomas Wormald
2    Joseph Heaton
3    Richard Grayson
4    William Forrest
5    William Robinson
6    William Smith
7    John Smith
8    Robert Hague Tenor

Conducted by Wm Smith

The first Peal ever Rung in Leeds.”

M: Thanks for sample text, I’ll work this into layouts.

L: Re colours… wood and stone with ultramarine/purple combo sounds good… but I do think each bell should be a different colour – or a different tint/hue of a strong but limited palette – remembering that we want to match them with the colours of the RGB LEDs in the bell posts… which can’t reproduce subtle differences that well…

M: Strong alternating colours might help too?

UK-based artist, designer and programmer Daniel Jones has agreed to help us build the ‘mode’ by ‘mode’ visualisation based on Malcolm’s design – initially conceived for display on a plasma screen but now planned for projection from overhead onto a circular screen on the floor in between the bell posts. It makes sense to us to programme this in Processing and build on some of the development work we started with MonoScape.

Lets start from the ground up… you and Nick need to chat to make sure you’ve got the basic architecture and communication protocols sorted between you so that you can start to code something from a solid base. Lets take an approach where you and Nick develop functionally working versions which you and I can then skin and refine?

I think some Processing research – looking into alternative libraries and renderers for importing and displaying SVG – would definitely be a good idea… and I need to show you where Nick and I have got to here with our own development. I do think the OCD (Obsessive Camera Direction) library would be a good solution for shifting viewpoints within the sketch – moving the camera/cutting to a different camera feed rather than actually rotating the graphic?… and again Nick and I have done some development work here to show.

We need to build eight “towers”, seven feet or so in height, with some kind of cut-out at a natural hand-height (we probably need to work out what that is, for a mixed visitor base of children and adults). In this version, the top part of the tower is held on a rod which has been extruded backwards, in order to allow people to insert their hands without hitting the rod. (There may be much better ways of doing this – we’re open to suggestion.) We’ve also not been at all specific about the diameter of the tubing: with this kind of extrusion – or some other – the tube doesn’t have to have a large diameter, although it needs to be wide enough to hold the electronics, and for the lighting effects to work. For practical reasons it also makes sense that each tower can be disassembled at the centre point, for ease of transport.

Towards the centre of the device, spanning the gap, we have the laser assembly (upper, pointing downwards) and the photodiode (lower, facing upwards). Unlike my earlier design ideas, the laser doesn’t run the entire length of the device – unless we can guarantee beam visibility along the full length, there isn’t much point – and having laser and sensor this close should hopefully minimise issues of alignment and vibration. We do want the beam to be visible on people’s hands – if we use the Odic 70mW units that is definitely going to happen – and I guess there are options for some kind of cover on the photodiode and/or the top of the lower tubing section to do something interesting
with the laser light when the beam is “open”. (We might also need to put some kind of weak diffusion cover over the LED clusters.)

This is an example of a piece we’ve been thinking about for visual design:

Herwig Weiser: Death before Disko

The machinery is all pretty much exposed, as opposed to everything being behind milky, 1970′s opacity. One task is to agree on some kind of material for the tubes which works well with the proposed lighting.

Ah, the lighting: in our current design only the top half of the device uses programmable RGB lighting (I’ve sketched an LED cluster sitting on top of the laser, pointing upwards). We’ve not decided what happens at the very top of the tube: whether there is some kind of covering, and/or some kind of gobo which scatters the light upwards. (We need to do a proper site visit to see how that will work in the space.) In the lower part of the tube I’ve indicated some kind of passive, neutral fill lighting, non-switchable. (I have in my mind some kind of deep blue/UV colouring here, but am open to persuasion.)

The digital stuff: the trade-off decision is whether to go for the BlinkM I2C units, at the extra cost, in order to cut down on required Arduino channels and discrete cables for all the RGB feeds. (As in Cyfnod, we also want to be able to gate the lasers.) My feeling is that we should go I2C for reasons of construction time and simplicity, although we then have the task of making sure the I2C actually works. (We need to think about how to run the I2C cables around the towers, especially as the MaxM units are half way up each tower.) We’re not totally opposed to going the fully analogue/PWM route for RGB, but there would have to be a clear benefit, especially as that approach would require multiple communicating boards. (More thoughts at http://blog.monomatic.net/?p=106.)

Interesting possibilities emerging for triggering and synchronising video via the in-house Alpine McBride Video Binloop 16 track video player which uses Compact Flash cards…

Steady progress… still some things outstanding according to my reQall list… but hoping to catch up this week.

1. Confirming Church participation and dates for visits and filming.

a) I’ve already visited St Peters Church aka Leeds Parish Church (LPC)

St Peter’s Church (Leeds Parish Church), Kirkgate, LS2 7DJ
12 bells
Practice: Thurs 7:30
Visit: Thursday, 9th July, 7.30-9pm
Filming: either Sunday, 9th or Sunday 16th August, 1-6pm

b) Through Steve Ollerton, Tower captain at St Peters (Leeds Parish Church) I’ve now made contact and arranged a visit and reconnoiter with a further three churches:

St Chads Church, Otley Road, Far Headingley, Leeds LS16 5JT
8 bells
Practice: Thurs
Visit: Thursday, 30th July, 7.30-9pm
Filming: Thursday 13th August

St Matthias Church, St Matthias’ St, Burley, Leeds LS4 2EL
8 bells
Practice: Mon 7:30
Visit: Monday, 20th July, 7.30pm
Filming: Sunday, 16th August (tbc)

St Matthews Church, Wood Lane, Chapel Allerton, Leeds LS7 3QF
6 bells
Practice: Fri
Visit: Friday, 24th July. 7.30-9pm
Filming: either Friday, 7th or 14th August

c) As yet I’ve had no response from:

St Annes Cathedral (Leeds Cathedral), Cathedral House, Great George Street, LEEDS LS2 8BE
8 bells
Practice: Thurs

which is actually the closest Church to Leeds City Museum – but I am going to keep trying and ask Sue Ball to make approaches on our behalf too.

d) Steve Ollerton has also passed on contact details for:

St Michael & All Angels Parish Church, St. Michael’s Road, Headingley, Leeds LS6 3AW
8 bells
Practice: Tues

which I’ll approach as a possible backup.

Looking like Thursday, 14th – Tuesday 18th August is the window for filming and recording.

2. Graphic Design

Malcolm Garrett, Creative Director of Applied Information Group and London based design guru has agreed to help with graphics for PEAL. In a recent email I’ve suggested: “I think a good starting point would be the logo/typography/colour scheme? I think we wan’t to try and somehow capture the contemporary and minimalist aesthetic of the proposed light columns counterpointed against the very traditional representations and physical construction of the bells…  if that helps get you thinking cap on?”

I’ve emailed Antony Rowe, squidsoup about the possibility of adapting and porting the Freq2 visualisation to visually represent ‘method ringing’ – but haven’t heard back yet (I know he’s with family in Norway for a few weeks)…

3. Technical

I started to look into the specs of the in-house Alpine McBride Video Binloop 16 track video player which uses Compact Flash cards which outputs: MPEG2 Video at 8Mbps (15 Mbps max) and 16-Bit PCM Stereo or Mono Audio (44.1KHz, 48KHz). All Compact Flash sizes supported. Manual as PDF (right click etc.) HERE.

8Mbits/s MPEG2 video gives 1 hour of video on a 4 GB Flash card, 15Mbits/s gives ~30 mins – which I think would be more than sufficient. The manufacturers recommend SanDisk Ultra II – and a quick ebay.co.uk search prices them at ~£17/each.

Interestingly the Video Binloop manual has an extensive section on ‘Controlling the Binloop’ – via the AMI/Pioneer Control Protocol – an ASCII based series of commands – sent to its Ethernet port…

“This protocol inherits its name from the fact that it closely resembles the popular Pioneer protocol used throughout the A/V industry.

The AMI/Pioneer protocol commands listed… are available for use on both the RS-232 Show Control port and the Ethernet port of the Binloop.

The protocol is ASCII-based. Upper or lower case characters can be used interchangeably. All commands and responses are terminated with the Carriage Return character. This character is represented by the hexadecimal value 0x0D.”

…which actually opens up all sort of possibilities for the synchronisation of video on each and all of the video via our laser triggers. We should schedule some testing shortly to see if theory can be translated into practice…

(Serving suggestion.)

Some initial thoughts about the hardware construction of the campanile.

We are thinking about an eight-bell setup, with eight ringing posts, one for each bell. Each post has to be able to sense a ringing gesture, and to display the state of the bell (in other words, its position). Although physical bells are completely independent (I assume: is there any kind of physical interaction between them as they ring?), PEAL requires a central processing unit in order to display and animate ringing patterns. So: how independent are the ringing posts? How much of a brain does each one have?

It makes sense to base the design on the work for a project that is already in progress: Cyfnod by Eddie Ladd. (The design ideas in Cyfnod were a partial influence on PEAL.) Cyfnod makes use of laser-photodiode units in pairs – each pair forms a triggering beam – and each physical unit is equipped with a tri-colour super-bright LED cluster. (Hence, each beam system has two LED clusters.) The entire system is interfaced to an Arduino Mega processor board and controlled by MaxMSP via a custom serial protocol.

The lasers are 70-100mW red modules from OdicForce – they have a 3B safety rating, meaning that we have to take some precautions from a health-and-safety perspective, but they aren’t going to burn skin or set anything alight. (I know: I tried.) The LED clusters are microprocessor-controlled BlinkM units with onboard firmware to interface with I2C systems and/or run local autonomous colour animations. For the purposes of PEAL, we would be looking at something like the high intensity MaxM units – compatible with the basic BlinkMs but bigger and much brighter. (And, obviously, more expensive.)

The laser assemblies have onboard TTL pins for power switching – we use these because we want to be able to turn the beams on and off during the piece – and it’s obviously necessary to connect the photodiodes into the Arduino for sensing. In addition, there are potentially three channels into each LED cluster if we want full RGB control. This all adds up to a lot of channels.

The Arduino Mega provides sixteen analogue inputs – we only need eight, one per photodiode. The smaller Duemilanove board only has six analogue inputs. We could possibly treat (some of) the photodiodes as digital inputs with a bit of discrete logic – we only care about nominal “on” and “off” states – but that would imply calibration in hardware (not necessarily an issue, but perhaps tricky to do compared to software-based calibration and display).

The bigger problem is output. The BlinkM units talk I2C, which only needs two digital pins (plus power and ground), but the range of I2C is strictly limited – a figure of 20 metres has been quoted, and in practice we managed about 30 metres for two units on independent cables before failure. The range can be extended using buffering ICs, but we didn’t try this for Cyfnod – in fact, our “Plan Z” approach was to not use I2C at all in performance, but to preload a boot-up animation into each unit and simply gate the power to fire the animation. For PEAL, it’s possible that we could route an I2C bus between the posts and come in under 20 metres. Or, we could spring for the buffering ICs.

It’s also worth noting that the BlinkM MaxM units are quite expensive: £30 for a complete unit. (Most of that is the I2C microprocessor; the actual LED board is £8.)

If we drop I2C, then we need 24 analogue channels: RGB times eight. An Arduino Mega only has 14 PWM output pins (the Duemilanove has six.) Dropping the MaxM’s controller board (with onboard TTL power regulation) would involve replacing it with more discrete logic for power control.

So, what to do? Let’s look at some rough prices:

• Arduino Mega: £50
• Arduino Duemilanove: £20
• BlinkM MaxM with microcontroller: £30
• BlinkM MaxM LED board only: £8

(We’re assuming that the basic MaxM board is the best way to get a collection of three super-bright LEDs.) The Duemilanove doesn’t have enough analogue inputs for the photodiodes (assuming we want to keep them analogue), which suggests we want a Mega or a pair of Dues.

So, sufficient Arduino pinage and MaxM I2C everywhere: somewhere in the £250-300 region.

Go for the MaxM LEDs only – that’s £64 – and we’d need four Dues (add £80) or two Megas (add £100). So, PWM output to the LEDs saves about £100, at the expense of much more wiring (RGB to every post independently, rather than a shared two-wire bus) and extra circuitry for the LEDs’ power supply.

(As an aside, we’ve found the BlinkMs to be delicate: out of a batch of 15 or so, three had a sporadic or totally nonfunctional colour channel, and we managed to blow two completely – and we also killed a MaxM processor we bought for evaluation – so we should budget for some predicted attrition with any I2C hardware.)

The remaining question: how to run two (or more!) Arduinos in the same installation? I assume the answer is pretty simple. Presumably it’s possible to hang them off a Mac’s USB port as multiple virtual serial devices – and, at worst, add some auto-ident sequence so that the host software can work out which is which in case the port allocation is dynamic. Alternatively, we could network them via Ethernet (the Ethernet shields are £30 a pop)… or perhaps just link two boards together via I2C?

I like the idea of a tool used for a specific project – and with reQall its easy to add notes, To-Dos and shopping list items via text, voice, email and IM – and share these with others – which seems ideal for a creative and collective project like PEAL – and a good way to document our development too.

What’s more you can publish your Reqall items through an RSS feed – here’s Lewis’s Reqall items for example.

Posting to the Monomatic blog via Flickr email…, originally uploaded by Monomatic-flickr.

Leeds City Museum – shot with my iPhone

This is a test to see how a rich text formatted email actually looks
on the Monomatic blog… and whether it’s possible to include photos
and add attachments – such as this audio recording of the bell ringing
practice session at St Peter’s Church made using Voice Notes on my
iPhone…

Conclusions:
Well the photo loads OK – bar the black border – which must be configurable in the Flickr settings (but which I actually quite like) – though (unsurprisingly) the Rich Text formatting in the email doesn’t translate and the audio file hasn’t materialised… but as a ‘quick and dirty’ way to post it could be useful.

1. Visit the Leeds City Museum and discuss technicalities with Tom Pace, Senior AV Technician
2. Meet with Sue Ball from MAAP
3. Visit Leeds Parish Church for a practice bell ringing session and meet with Steve Ollerton, Tower Captain and the group
4. Visit other possible churches – time permitting…

Resulting in the following notes (they’re quite extensive – sorry):

1. Leeds City Museum is a grand old building and the Leeds Arena is as impressive in real life as it is in the photos… but they were preparing for a significant externally produced evening event and there wasn’t the opportunity to spec out the space thoroughly.

What I did manage to find out from Tom (who seems nice enough) is:

1. The five in-house projectors are Panasonic PT-D5600E – not a current model and no details on the Panasonic website but details here <http://www.ivojo.co.uk/panasonic-pt-d5600e.htm> – and they’re XGA – 1024×768 – so we’ll not be showing HD video!
2. They’re wired using component cabling – Y, Pb/Cb and Pr/Cr – but Tom also uses the Pr/Cr cable to display composite only – odd but true.
3. Re video playback:
   1. there’s one in-house Windows 98 PC that can drive video to all screens…
   2. or we can send a discreet video to each screen using the in-house Acorn McBride Video Binloop 16 track video player which uses Compact Flash cards – up to 20 minutes of video per card. Tom says that formating the cards and encoding the video appropriately is a bit tricky – but he’s happy to offer advice here. Whether we can actually get more control out the device than just playing the loops might be worth investigating – Rowan would you download the user manual and have a look?
   3. or we can provide our own video playing PCs ??
4. Re audio – there’s an in-house rig of 8 speakers at balcony level (I think there might also be a ring at floor level – but I can’t see any in the photo) which are wired up to a stereo output – either top left and bottom right or 4 left and 4 right I vaguely remember…
5. The circular lighting rig is accessible to us and can be used to mount additional lighting and slide projectors etc.
6. I now have Tom’s mobile number…

2. Sue Ball of the Media and Arts Partnership (rubbish Flash site that won’t work in Safari for me) is a public art consultant working with Sound and Music on delivering Expo. Sue is lovely, really gets the piece, is happy to help and support us in which ever way she can and I think would be a really useful sounding board as the work progresses and we need to resolve aesthetic and interactive development issues. I’ve said I’d cc Sue in key correspondence and keep her up to date with developments via the Monomatic blog.

3. The visit to a St Peter’s (Leeds Parish) Church bell ringing practice was great – a real ear and eye opener and just as informative as I’d hoped. Steve Ollerton (Tower Captain) is very positive, more than happy to advise and help and keen to support us. I even got a chance to ring a bell myself

I’ve uploaded photos from the visit (using the surprisingly good Flickr Uploadr) into a new Monomatic Flickr account and a very rough edit of video footage on the Monomatic Vimeo account – all taken with my Canon IXUS 860 IS.

a) Confirming churches

Steve thinks we’ll have problems finding five active 8 bell ringing groups in Leeds – he’s confirmed this in an email too:

• The St Peter’s (Leeds Parish Church) group is “by far the leading light  in Leeds bell ringing” – with 20+ members its the largest and most active;
• St Annes Cathedral, LS2 – “is second but there is an awful lot of politics between the 2 towers and we do not mix” – an elderly and traditional group according to Steve though it is very close to Leeds City Museum;
• St Chad’s Church, Far Headingley, LS16 – “have a reasonably good band and may well want to be on board” – and it has a nice mix of elderly and child bell ringers evidently;
• and probably St Michael & All Angels Parish Church, Headingley, LS6.
• Steve also recommends the 6 bell St Matthew’s Church, Chapel Allerton LS7 which has a small but enthusiastic group.
• St Matthias, Burley, LS4 – the base of the Leeds University bell ringing group “have a good and enthusiastic band” – but they’re unlikely to be ringing over the summer break.

Steve confirms my assumptions that we’ll have to deal with local politics and personalities in engaging these churches – but he’s agreed to help make connections for us – and confirmed that the St Peter’s group will support us by supplying bell ringers for sessions at other churches if required.

He’s also keen for the St Peter’s group to perform at Expo using our virtual campanile – though interestingly the general consensus is that the bell should sound directly on breaking the beam – and not have any kind of delay as we’ve mooted in the proposal to try and model the natural cycle of the rising and falling rope as in a real bell tower.

b. Accessing St Peter’s

We’ve agreed either Sunday 9th August or Sunday 16th August, 1-6pm as the best diary opportunities for us to film. We can be let in from 1pm to set up equipment and they’ll then start a practice session from 4pm.

Although we can get access to the bells themselves we’ll definitely need lighting (it’s dark and dingy up there) – but access is awkward and cramped and so we should definitely be looking for the most compact solutions at all times…

c. Ringing the changes

I was quite surprised at how hard sonically it was for me to separate the individual bells and hear when they were actually ringing in the cycle of pulling their rope. In the end I just concentrated on the tenor (lowest tone bell) and managed to work out that it rang at the top apex of the sally (the tufted handgrip on the rope) rise and also a little after the start of the rise from the lowest apex of the sally fall (watch the Vimeo video to confirm this). One ringer said it was “as your hands pass your face”.

My difficulty may have been partly due to the fact that the cycle of the smaller bells is actually faster than that of the larger ones – as Steve explains: “You may not be aware that when a ringer pulls the rope the bell rings between 0.5 and 1 second later depending on how big it is and how long it takes to swing round its full circle i.e. at Leeds if you pull 1 and 12 at exactly the same time 1 will ring after 0.5 secs and 12 after 1sec – ping dong. They will not ring together! Your laser beams may not take that into consideration! Tricky tricky.”

From our research to date I understand the principle of following the “blue line” in method ringing with calls from the Captain to interject shorter sections to shift the order of the bells – but in practice the methodolgy of the ringing was totally opaque to me and I really could not make any sense of what was actually going on. As Steve says “you have an awful lot to do and learn about bellringing in a very short time”… how true!

Steve mentioned the definitive bell ringing simulation software – AbelSim – available for OS X as Mabel – which I’ve now bought (£20) and am starting to explore…

I also noted the method ringing book ‘Diagrams’, Jasper Snowdon Change Ringing Series, published by Christopher Groome, printed by MPG Books Ltd – which might be useful to get a copy of…

and the fact that the group noted attendees and the details of played pieces – which each last about 10 minutes – in a log book…

d. Things of note…

The whole experience – from the cramped stone spiral staircase access from the base of the bell ringing tower; the climb up metal ladders to the bells themselves and their sheer size, volume and patently significant inertias; the movement of the ropes and physicality of the ringers; the small details I noticed in the decor and furnishings of the space – was incredibly rich and evocative… its hard to know what NOT to note…

• although larger than most at 12 bells the diameter of the “full circle” of ropes is actually quite big – at least 12ft;
• when playing a simple round – bell 1-12 – the sallys move in a way very akin to a ‘Mexican Wave’… which made me think about the control and effects of the LEDs in our virtual campanile…;
• though not actually much used from what I saw there were carpet circles on the floor for each rope… a lovely mushroom colour ;
• as well as standing boxes for the larger bells – hand made and worn through years of use;
• benches on two sides for people to sit on;
• a table in the centre with a couple of chairs… overflowing with bits of paper, magazines, old drink cartons etc.;
• spare bells (?) half stored under the table;
• spare ropes wound and hung on the wall;
• two really bright halogen floods in the ceiling that cast hard shadows of the bell ringers movements on the floor;
• the leaded and ornate window;
• the fading boards of special events and people on every wall.

I was also touched by the little things… the small details in the space which might be really nice to capture and reflect in some way in our virtual campanile – perhaps by slide projection onto the floor of the space…

• a stopped clock;
• a first aid kit on the bookshelf;
• a trophy on top of the bookcase next to a game of Twister;
• a baby chair and playpen;
• the central table and chairs with the clutter and detritus of many a bell-ringing session;
• the little nick cut out from the standing box from the largest bell so that it could accommodate the lowest step of the circular staircase.

4. I was a bit too late to visit St Anne’s Cathedral… it closes at 6pm – but took some photos of the outside… and ran out of time to visit any of the other churches Steve Ollerton had suggested.

My camera can’t quite capture all the button flashes – but you get the idea…

There’s an initial schematic of the button layout and functionality as PDF… though this was just a starting point and has since been superseded.

Nick used shado – his own open-source compositing and sprite library – to enable the monome to trigger up to eight individual sounds (via MIDI note-on on separate MIDI channels), set their volume  (controller #7) and allow each to be positioned both within the x-y plane (controllers #2 & #3) and z plane (controller #4) of the sound field (3D-AudioScape is unique in that it also has a z-axis positional component due to its two rings of speakers – one on the ground and one in the air). The app also has a mode for calibrating the output of the monome64 accelerometer to allow the position of a sound in the x-y plane to be controlled via tilt.

We also co-developed a Processing sketch to provide an on-screen display of  monome activity – an 8×8 grid of graphic buttons which mirror the actual LED state of the monome64 – as well as showing tilt and orientation by rotating the grid in 3D space.

We ended up exploring and implementing a range of Processing functionality – which has moved on our combined understanding of Processing considerably… key areas being:

• SVG – using ID tags in the XML and the getchild() function to access and setVisible() different elements of a graphic as required;
• lights – implementing Processing’s quite impressive range of lighting options – and using the ControlP5 library to create a secondary sketch window with sliders that control the colour, positon and direction of lights in the main sketch – and save this set-up to XML;
• second monitor full screen mode – Nick’s implementation of the Java AWT is truly awesome – and essential for performance and installation;
• accessing monome button press, led state and tilt data as OSC from shado using the Processing monomic iibrary.

We developed this for a presentation at the Future Of Sound show at The Sage, Gateshead on the evening of Saturday, 23rd May. It was all a bit last minute and there’s still a fair amount of code refining to do… as well as some additional functionality to implement for next iterations… but it did the job on the night.

Monomatic – Future Of Sound, The Sage, 23rd May 2009 from Monomatic on Vimeo.

Lewis got caught up with work for Martyn Ware’s Illustrious Company from May 08 – producing and coordinating a range of sonically themed projects…

Ant started a new job at at the Oslo School of Architecture & Design in Jan 09…

“So many ideas. So little time.”

But we do want to move things forward – even in modest ways – and so have resolved to work together on our earliest idea - discome. Now if Ant can only get a version of Director installed on his new Oslo School laptop

We also plan to invite others to join us under the monomatic umbrella to work on specific projects:

• So Nick Rothwell (perhaps with a bit of input from Jules Rawlinson) is going to co-develop the Monome meets 3D-AudioScape;
• and possibly Daniel Jones is going to help realise the idea of a a collaborative, networked,  multi-monome type thing  – which seems not to have much mention in this blog other than as occasional references to our first-step ‘get the networking working’ idea of Battleships – which subsequently morphed into squidsoup’s Stealth Project…

More news soon…

7 May – Anthony:

And Monomes….  I’m planning a Summer of fun.  Battleships, discome and the 3D-AudioScape interface on the agenda at the mo – hopefully in Processing or OpenFrameworks – are these still all live ideas?

15 May – Lewis:

Yes I’d like to move these forward too… 

3D-AudioScape interface seems the most solid in terms of agreed funding… and I’m still keen to develop an application schematic for phase 1 based on the blog.monomatic.net post as a starting point…

discome… I’m working on the audio again… just back up and running on my Boot Camp reinstall – an act of sheer desperation – I just couldn’t work out what was going wrong but now realise it was only a fault  with a new plug-in… grrr. I’ll email sensomatic for the graphics and cc you in… I’m not sure what is happening with funding from BSkyB for this though… I’ve heard nothing from Eva recently – will try and speak with her soon. Also my ACE application for the monome open practice project was unsuccessful…  and though I’ve reapplied its all looking a bit shaky. Ho hum…

Battleships… yes please… everyone I mention this to loves the idea… I’ll start to work on audio as agreed – hunting out a suitable source movie now.

And I think Processing as a prototyping tool would be good… there’s the monomic library – now updated (in part) by my new monome friend Daniel – so communication via the device is ready to go. And it means I can contribute too since I’ve worked a bit with Processing – so I can look into working with audio a bit. Then perhaps we could port it over to Open Frameworks later…

15 May – Lewis:

Here’s what we’re thinking about…

discome will be an interactive installation – a monome on a plinth in front of a screen or white wall with stereo speakers

In ‘idle’ mode the installation will make a few small disco noises and show the discomatic robot at rest – or ‘fidgeting’.  Occasionally the monomatic version of ‘I Feel Love’ will play through the speakers and the discomatic robot will dance on the screen (rather like the existing discomatic shockwave piece but without the key stroke interactivity) – although we’re planning to put him (?) in a 3D environment. We may also, depending on time, make this a bit more ‘pop promo’ like – fast edits, big close ups, camera pans and tilts etc. the audio track may also get some treatment and filtering to make it more varied. 

The monome itself will display variously in this mode – an arrow pointing to a flashing button to start the interaction… or as a disco-dance-floor during the ‘pop promo’ for example. The really nice thing about the monome is that it doubles as input and display… and although the 8×8 1-bit grid is restrictive we were hoping you would be interested in working within its limitations to develop some graphics and animations that could be displayed on the device… it certainly fits with your minimalist pixelated aesthetic

In ‘interaction’ mode viewers will be able to use the monome as an input device to construct/reconstruct their own version of the track – either as a simple 8 track 8 step sequencer triggering different sounds within the mix – and simultaneously the dance moves of the discomatic robot – or possibly as something a bit more abstract – a looper allowing different audio tracks within the mix to be set to different loop lengths creating polyrhythmic disco! Haven’t quite worked this out yet – but you get the idea.

The monome also sends tilt data – it has an accelerometer built in – so picking up the device and tilting it could affect the sound – or most obviously, control movement through the 3D environment… wicked.

That’s about it in terms of what we’ve thought of… and even some of this I’ve just made up so will be new to Ant… but happy to hear your feedback and ideas too of course.

So what we’d like from you are:

1. Director files of the current Shockwave piece… or any other relevant animation or graphic files.  Ant works with Director so should have no problem extracting the sprites and moving them into a 3D environment… sooner the better too.
2. Animations for the ‘pop promo’ – perhaps this is actually something you could develop alongside the audio and then we integrate later?
3. Graphics and animations developed specifically for a the 8×8 1-bit grid.  In fact we may shortly be able to get per led intensity with a firmware hack - so we can have 16 levels of brightness on any led on the device which will allow for 8×8 pixel anti-aliasing and grayscale images and video – we’ll let you know if this works out.
4. Any other ideas and elements you guys would like to suggest…

16 May – Anthony:

This all sounds good to me.  I like the idea of using the Monome to interactively jumpcut a pop-promo style discome video – closeups etc controled by button presses.  And tilting affecting his/her position in a 3D space but only visible if no buttons are pressed.

Bit of work there though….  let me know what Florian says

On the other things, I finally had a peak at Antoine Schmitt’s site – as I said before I have worked with him (he built us a VoIP xtra) and although that project wasn’t a huge success his work is good.  He has xtras (Wintel Mac compatible) for UDP and multichannel audio, which makes me think that maybe I could do the whole thing, including audio control, in Director.  That would be good.  Although I’m keen to port myself over to other platforms, I know Director best and if it can do the job then I think I’ll stick with it.  I’ll try the xtras out in the coming days and let you know what works…

16 May – Lewis:

Hopefully we’ll hear back from Sensomatic shortly and can plan from there…

I think that you should do the 3D-AudioScape controller in Director - if Antoinne’s xtras work. It’s what you know and it’ll be fast and efficient. Also I know Director reasonably well and can help with things like design, gui, help info etc…

And perhaps we could develop Battleships in Processing? It communicates with the monome, has all the OSC and audio functionally we need – and is a stepping stone to Open Frameworks, Java, C++ and beyond… which will allow you to port over to other platforms in a strategic but relatively relaxed way… Sound like a plan?

The Illustrious Company’s 3D-AudioScape surround-sound system                      

Built by Paul Gillieron Acoustic Design and refined by Illustrious, the 3D-AudioScape surround-sound system comes closer than any other to the holy grail of ultra-realistic sound. It achieves this through two rings of speakers, one high and one at ground level to create a three-dimensional (X,Y and Z) virtual sound space. Illustrious’s unique visualisation/spatialization software positions up to sixteen separate sound channels within this virtual space which are then are able move in any direction, including up and down, in real-time. 

(Ant Lewis)

As discussed (with a couple of slight changes) the basic procedures are:

• Left column selects a sound – OK
• right column sets volume - hold left button for specific sound – OK
• any button not in far left or far right starts the sound or re-positions the sound at that coordinate (overhead view of the floor) – by limiting this to a central 6×6 square excluding not just the far left and right columns but also the top and bottom rows you not only maintain the square grid but release 6 buttons both top and bottom for additional functionality – I don’t actually think from working with the system that loosing the 8×8 resolution will actually make a difference to what you hear – it needs to be quite coarse…
• press and hold a left hand column button and tilt to control horizontal plane movement – OK but still within the 6×6 grid
• press and hold a right hand column button and tilt to rise/drop a sound - OK but still within the 6×6 grid – and does it at least indicate the X (L-R) position of the sound in the grid while doing this?
• (this way you can hold down multiple buttons simultaneously and make several/all sounds move around together) - I can see this – a bit like bends 0.1 – though the problem is you loose ‘sight’ of sounds once they align on the same point on the grid.

There may also need to be a calibration thing. I agree – and Tehn’s bends 0.1 calibration set-up seems pretty considered and solid as an example to draw from…

It’s going to be PC only – hope that’s OK? Actually no – Martyn, Asa and the 3D-AudioScape software are all OS X. Is this a problem? What software are you planning to use – MaxMSP or Director?

This all good… but I have a few additional thoughts… mostly just thinking about extending functionality… I understand thse might not be possible to implement within the resources… but thought it best to expand ideas at this conceptual stage…

- can there be a mode where you can see all 8 sounds simultaneously? how can you differentiate between them? by flashing once for sound 1, twice for sound 2 etc? by flashing in order sound 1 – sound 8? by flashing at different speeds – sound 1 slowest – sound 8 fastest?

- how do you represent Z axis position in this mode? by per led intensity? (requires the per led intensity hack to work – though this is somewhat doubtful) can a second button press flash all sounds on the same Z axis position from lowest to highest in turn? as above?

- how do you mute a sound – or all sounds? or reset position/s?

- can a button depress arrange all or some of the sounds in a pre-determined spacial arrangement? – corners of a cube, apices of a cross etc… or switch between these arrangements? can a particularly pleasing arrangement of spatialised sounds be saved to a preset?

- can a button depress (top row perhaps) have a built in sequence that triggers sounds 1-8 in a set order/pattern – and can the 6 top buttons each have a different pattern – or at least tempo?

- can the app only load one bank of 8 sounds – or can you have more than one bank (either in a different ‘bank’ folder in the ‘data’ folder – or by numbering each sound file 01-08, 09-16 etc… can a button depress switch banks? 

OSC into Director on a Mac – Web research

emailed Garry Kling re the much cited
OSCar (dead link)

alternatively
Director Xtra – OSC-communicator

possibly
asUDP xtra by Antoine Schmitt

on a tangent
FLOSC

17 March – Anthony:

Finally got to your thread on the blog.  Here’s my thoughts:

Using the Monome to control sound on Martyn’s 3D-AudioScape should be technically fairly straight forward, as would the visualisation grid.  MIDI to OSC is no problem.  I don’t know much about DMX, but I think I did a student project a couple of years ago that used DMX…  or there are hardware solutions to convert between MIDI/DMX (e.g. http://www.lanbox.com/products/LCDataSheet.html - about GBP350 – no idea how good they are).  I’ll have a think…

I’m interested in that hack that allows you to control per LED brightness – that would rock; have you got it to work? It might make my camera thing make sense for a start.  I’ll fiddle with the accelerometer thing too – it wasn’t incorporated into the download when I first installed the Monome, so I haven’t used it yet

As for discome – getting the Monome to trigger discrete animations onscreen is fine, but doing any kind of animation on the Monome itself is doable but won’t look any good – as you found out yourself, 8×8 is very small to make meaningful graphics…

20 March – Anthony:

this is interesting :  http://monolake.de/installations/cyclone.html

i’m warming to the 3D sound interface idea

20 March – Lewis:

Do you know of Ray Lee’s Siren piece? <http://www.invisible-forces.com>

I’d thought about recreating a virtual version of it… both visually and sonically…

I know Ray and think he’d be amenable to the idea…

20 March – Anthony:

I know the piece – I’ve got the DVD – though I haven’t seen it physically.  I think it’s wonderful, but it’s the physicality that’s so nice.

I’d like to use the Monome to control a physical installation of some kind.  A grid of Ray Lee’s sirens, or air raid sirens perhaps that are wound up by pressing the monome keys…  you might be able to control pitch/speed by how long you hold down the key…  i like it.  dunno what Sky would think of being subjected to 64 sirens though.  maybe a virtual version of that would be nice?  i guess that’s similar to what you are talking about, if you use the monome to wind up ray’s sirens…

yeah.  It’s a possibility.  I would like to work with Ray Lee too.

Tilty Snake from squidie on Vimeo.

My 9 year old son got so involved he nearly threw the thing across the floor in frustration when the snake finally bit it.

Update (17th May):

After posting to the monome.org community forum this video was featured on the main News section and has since received over 8,250 views… wow!

The monome.org site has lots of useful information, tutorials, apps and patches… but is, typically of open source communities (though better than most), messy and a bit difficult to find your way round if you’re new to it. The best place to start is the new monome docs and in particular the setup section…

To get the monome up and running you’ll need the following essential (E) and recommended (R) drivers & software:

1. (E) Install the ftdi virtual com port (vcp) driver.
2. (R) I use Hardware Growler “This is a little app hidden in the extras folder of the growl disk image. It notifies you of any hardware events, like when you plug in your mouse” which shows that the monome has been plugged in and is recognised by OS X. But you need to install Growl which actually gives notification of much more system activity – you can configure how much in the Growl preferences pane…
3. (E) monomeserial is an osc and midi router. “it’s needed to interface with our other applications and to make your monome device accessible via midi to other types of software.” This will show ‘no device detected’ if the driver isn’t installed properly.
4. (E) Most monome apps are written in MaxMSP (and Chuck to a lesser degree) – you’ll only need to download the Runtime version of MaxMSP – I personally wouldn’t bother with Chuck initially.
5. (R) the monome_base_4.4.zip file contains a collection of useful MaxMSP patches that can be used to test and configure the monome – there’s additional info on the how to use monome devices section.

If you get to here and are able to see lights on the device and button presses in the ‘monome_midi_64.mxb’ patch (for example) then everything is installed and configured properly… Now to move on…

6. (R) I think it’s worth deciding on a simple data structure to store and access files – I shared my setup on a thread on file management on the monome forum.
7. (E) You’ll need soft-synths and/or soft-samplers to receive MIDI and make sound… running Logic and some of its in-built instruments or as a VST/Audio Units host will do this obviously… but standalones are probably less demanding of system resources. I use Native Instruments’ Massive, Kontakt & Battery and (on Windows at least) the M1 from the Korg Legacy Digital Collection – up to you obviously. A good range of drum kits, piano, plucked strings and mallet/bell sounds are particularly useful…
8. (R) I use various MIDI utilities to monitor MIDI data, set up additional virtual MIDI ports, rig more complex MIDI routings etc… including the freeware MIDI Monitor and Midi Pipe – download it here. STEIM’s JunXion could be really useful here too… since it also reads OSC over USB.
9. (R) Here’s an application list of some of the most popular apps and patches. I’d recommend clear, mabalhabla, boiingg and flin for starters… also bends for tilt data…

Hope these notes help get you up and running… that Dave Hunt works with MaxMSP could be really useful I think – once you get more idea of what you could really use the monome for…

I wanted to update my profile at monome.org with a photo and some info – now that I’m starting to post regularly. I was thinking about suitable 1 bit 8×8 pixel graphics – and thought of Space Invaders (obviously)… and tracked down (with surprising difficulty) a set of characters in this Invader from Space font. It turns out most of them aren’t actually 8×8 pixels – but there are a few that are and I’ve chosen my favourite

We haven’t had a chance to meet and really talk in the past few weeks – since getting the devices in fact – so I thought that a bit of critical reflection might help Ant understand my perspectives – and let me highlight some illustrative examples – and that might help him… possibly…

So to put this all in context…. I first became aware of monome in July ’07. It’s taken me 8 months to get my hands on one – an unusually long wait and feeling of expectancy for me for any piece of kit. I’ve been so genuinely taken with the project that – my own practice aside – I’ve also been developing a proposal for a Cybersonica project based around it – and I’m just at the point of submitting the Arts Council application. I’m a bit saturated in monome at the moment… and I’m not sure this is a wholly good thing…

My thoughts, in the order they came, below (I qualify these comments as my attempt to be cooly objective not glibly critical – I genuinely admire the project)…

1. I’ve worked out what it is overall I like about monome so much – its refinement as a beautiful, hand-crafted, inspirationally designed, limited edition, tactile ‘objet d’art’ (in my opinion, a very rare but actually very important model of open source development) – juxtaposed against its schizophrenic counter personality of being technologically ‘transparent’ and adrift in a tumultuous sea of alpha and beta software… plum crazy.

2. The monome community seems well established with a significant archive – rich and interesting but unsurprisingly messy all the same – and so seemingly ‘bustling’ with new developments that it’s taking quite some time to get to grips with it… but I am getting there. I’m becoming more familiar with ‘key players’ and some of the ‘significant’ software they’ve contributed – tehn (obviously) – monoserial on os x, mlr, muon, flip, bends… stretta – mabalhabla, TR-256, press cafe… kid_sputnik – mononme serial on Windows… steve_duda – Molar & Monochrome. I consider these ‘influential’ personalities and significant ‘currents’ within the alpha/beta sea. They kind of ‘pilot’ the community which has a definite ‘list’ about it… you can almost taste the ‘free radicals’ – am I taking this analogy too far?

3. The community forum features a diverse almost whimsical agenda and range of interests – but actually I think it’s more limited than first appears and with some distinct ‘blind spots’. Its definitely more musical than visual – I’ve found almost no interest in processing software for example; more hobbyist than artistic – I posted this thread about The Sancho Plan & Jason Bruges Studio collaboration which I thought would have been of interest but which received absolute and stony silence… not a single response (I accept I might just smell and nobody likes me!); more GEEKY cool than geeky COOL – this thread a good case in point – New App/Toy: Boiingg (MaxMSP) – a lovely little app/toy with a thread that’s been bubbling away since it was posted in November but that got totally sidetracked (to my mind) with discussions about the physics of bouncing balls rather than the musicality of its functionality (this may be being a bit unfair…)

4. Although I have been spending a lot of time playing with my m64 I have been quite systematic and thoughtful – as I set out to do.

• I’ve invested a fair amount of time just setting up a solid and efficient working environment on my Mac – and I’ve got there – almost – just a new USB 2.0 soundcard to get. For example I’ve found some macro/automation software that I think will let me automate opening an entire project – I really can’t stand separately launching 4 pieces of software, opening 4 patches, positioning them all on screen, loading setting files etc. etc. before I even start :-[]
• I’ve been interested in finding out the m64s limitations and I’ve wanted to push at its boundaries – so I’ve been following and contributing to this thread about hacking the firmware to give per led intensity for example. I’ve also been exploring the accelerometer in this thread. For me this my natural musicians approach (twist it ’til it squeals) but also a reaction against points 2 & 3 above… I’m actually not that interested in what I suspect the monome is mostly used for – I don’t want make noodling, generative music or jam with rough & ready audio loops.
• I do have some personal favourites amongst the community software – flin – bit traffic music box, boiing – bouncing midi pattern generator – both very soundtoy like – simple but appealing and with hidden complexity. I’m particularly interested in linking the monome with ableton live and drumwreck, liveio, livestep – ableton routers – are interesting – drumwreck’s particularly good – if a bit tricky to set up. But absolutely heads and shoulders above everything else for me is steve_duda’s Molar – sample recutting sequencer VST Audio/plugin. I’ve been slow getting to it – it’s complicated but poorly documented – despite or probably because it has such a detailed and opaque thread on the board. But I finally sat down with it earlier in the week and it is absolutely stunning – and I know my music software. I’ve barely started to get to grips with it – let alone use it as a creative tool. This is one very good example of what the monome is really capable of inspiring…
• I do believe that this is a device worth getting to know slowly… it’s an instrument – a very accessible and immediate one on one level (which I really like) – but also requiring real application and practice on another (which I also really like). Both aspects challenge me – but in different ways – and I’m actually quite enjoying trying to work out how I best use it to really engage others and myself…

5. I think that unlike you, I’m less worried about being ‘inspired’. I accept this may be my bias for objective, conceptual thinking – as opposed to subjective, emotional thinking. This Meyer-Briggs ‘psychological modelling’ aside – and I’m not suggesting you’re a subjective, emotional thinker either, just that you do think differently – and so need to work out a stratrgy that works for you… For me it’s all modeled in my head at a distance – I’m not overly concerned about how I feel about it up close. It’ll dawn on me… slowly.

So I still think the best approach (for me at least) is to ‘play with intent’ – to work on a series of small, realisable challenges. Nothing too ambitious but concerted and more than just demos – I want to produce some small things that are nonetheless artistic and refined. I’m still working systematically on the discome music… and I have it in mind as a next stage, more significant project, but I’m only just beginning to think about how to possibly implement the monome within it… and these excercises are helping me to do that… hence I’ve got a few things in progress that I think will keep me busy for a little while…

• as a prototype for The Sancho Plan/Jason Bruges Studio collaboration – using the monome as a way to develop and test triggering lights/leds live and from a sequencer – and this may well involve the firmware hack I mention above to get per led brightness once I can afford the programmer I need;
• monome and Processing – I’m working on a little monome ‘visual haiku’ based on the Image Explode example I extended and developed as a little ‘Intermission’ for The Sancho Plan performance at The FOS Late at British Library event last November (though it was actually a bit of a disaster on the night) – driven by boinngg… it’s coming on and is sweet. Can’t get OSC to work but I’m using MIDI;
• really getting to grips with and working up something with intent in Molar;
• exploring the tilt functionality – implementing it more thoroughly to drive synths, effects units, draw in processing, control The Sancho Plan visuals in Flash etc. This also puts the monome right ‘in my hands’ – which is important I think. I want to become comfortable and practiced with it – but that will take time…

6. As far as ideas for you are concerned – I think a surround sound mixer sounds great, as does connecting our devices over a network, or controlling lights in a building – all of which you’ve mentioned.

If I were to throw in some ideas or my requests to apply your skills and expertise…

• 3D joystick – could you cajole the monome into sending MIDI controller data over 3 axis? This would integrate directly into Martyn Ware’s 3D-AudioScape facility for instance…
• 2D to 3D visualisation grid – could you make the monome show a 2D representation of a 3D space? Say a cube 8x8x8 little cubes big (like the 3D LED grid you’ve mentioned) – each of the 512 little cubes can be on or off – or a scale of brightness once the firmware hack is implemented. By variably orientating the monome in space you’re able to see (and/or draw in) a ‘slice’ of the 3D grid.
• MIDI to DMX512 – or MIDI to OSC to DMX512 – do you have the protocol and hardware knowledge to translate from one to the other – The Sancho Plan needs this…
• discomatic – If I get the working files from Florian – I’m pretty certain it’s Director – would you be up for adapting/reconfiguring it to trigger discreet animation loops via the monome? I’d like to see if my original idea has legs…

Hope this helps…

Ant responds:

Lewis, I take your comments on board.

Using the Monome to control sound on Martyn’s 3D-AudioScape should be technically quite straight forward, as would the visualisation grid.  MIDI to OSC is no problem.  I don’t know much about DMX, but I think I did a student project a couple of years ago that used DMX…  or there are hardware solutions to convert between MIDI/DMX (e.g. here - about GBP350 – no idea how good they are)

The Monome is easy to communicate with and fast, and it’s really nice to have a computer interface that looks and feels right.

Made a 1 bit 8×8 webcam display out of it as a test. It’s quite fast too.

Here’s an interesting Wikipedia article on the track… which says that this is the first disco-style song recorded with an entirely synthesized backing track!

In attempting to de/reconstruct it in Ableton Live I’ve come to realise what a groundbreaking production Giorgio Moroder and Pete Bellotte actually created for its time. There is so much complexity and subtlety within what initially seems to be the fairly straightforward instrumentation and arrangement – which is why I suppose it’s such a classic and timeless track – der! So I’ve resolved to do my upmost to create a worthy monomatic version to reflect this… something I’ve just not found in those few remixes and reworkings I’ve actually listened to – of which there are very, very many…

Here’s the orginal… and my working rough…

[display_podcast]

(this is just a first draft instrumentation and arrangement and is far from finished… but it’s coming along well I think)

Next I’ll be attempting to create robotic renditions of the main and harmony vocal lines using Repeat After Me 1.3 – Apple’s phonetic Text To Speech app bundled in the OS X Leopard Developer Tools.

these are the two old 1bit video patches. they need jitter, and my auth
ran out, so i haven't tested them. i updated the osc objects to 4.6.

Stupid sprite generator for the 40h:
http://post.monome.org/comments.php?DiscussionID=665&page=1#Item_0

Just put my 40h kit in a box, and am starting to get a grasp on how to talk
to it, so to test things out i whipped up an incredibly stupid sprite generator.
Might be worth a few laughs, probably not more.

Per led intensity, video [modified firmware]:
http://post.monome.org/comments.php?DiscussionID=913&page=1#Item_23

I wanted per led intensity, so I hacked a bit in the firmware and voilà.
I can now adjust the intensity from 0 to 15 on each diode.

aacd : Atari ASCII Character Display:
http://post.monome.org/comments.php?DiscussionID=141&page=1#Item_0

...silly little app that I wrote to display the old Atari ASCII variant
character set

Disco dancefloor application:
http://post.monome.org/comments.php?DiscussionID=312&page=1#Item_0

Some of you might have seen the Daft Punk LED table made by Habitat.
It has a music input that makes the table look like a old school dancefloor.
look here http://youtube.com/watch?v=zCA79Du-WqY

The momome is a beautifully designed, hand-crafted, minimalist interactive interface for controlling and monitoring pretty much anything audio, visual and beyond… a reconfigurable grid of backlit keypads which connects to a computer. Interaction between the keys and lights is determined by the application running on the computer – there is no hard-wired functionality.

discomatic is a graphic design project which aims to build an entire dancing robot army for world domination and flood the world with disco!

discome brings them together – using the interactive interface of the monome to control and respond to 21st century disco music and the funky dancing of the discomatic robot – for endless hours of realtime disco fun!