Archive for the 'Construction' Category


The Chessboard Keyboard

The purpose of The Chessboard was two-fold: firstly, to continue my experiments with alternative keyboards, and secondly to use the ability of the Bigfoot to control a Stylophone (or other sound-producing devices, but so far the only ones I have which are adapted for this purpose are the SoftPot Stylophone and the StyloSound) by means of binary input.

The idea for the Chessboard was that it would have 64 keys, one for each of the black and white squares.  These would not be arranged according to the Janko, Wicki-Hayden or other alternative keyboard layout, as the principle of the Bigfoot is not to provide all the notes in the octave, but just the notes in a particular scale.  So the 64 keys would cover 15 notes over 2 octaves, like the sequencers in the Bigfoot, and note information would be passed to Bigfoot in 4-bit binary form.

I managed to get 64 buttons – tactile switches – for  a few pence each, and glued one to each square on the board.  One side of each button was connected to +V, and diagonal rows of buttons were connected in parallel to produce a pattern of notes in the 2 octave scale, like this:

Chessboard keys 5a

‘1’ means ‘root note’, ‘2’ means 2nd interval, ‘3’ means 3rd interval, etc.  Switches on the Bigfoot determine whether the intervals 2nd, 3rd, 5th, 6th and 7th are major or minor (natural, or lowered by a semitone).  [Note 8 is an octave above the root, note 15 is two octaves above; the 9th, 10th, 12th, 13th and 14th intervals follow the 2nd, 3rd, 5th, 6th and 7th ; the 4th and 11th are not changeable].

The circuitry to encode the 15 individual notes into binary form was exactly the same as I had recently used in the StyloSound, utilising two 4532 chips and a 4071.  The four binary outputs were buffered by a 4050 before being sent to a 5-pin DIN output socket.

Chessboard keys 5b

LEDs were wired to the  A B C D outputs, to give a visual indication of the binary signal being sent out.  This was also helpful as work progressed in checking the correctness of the output and the smooth operation of each of the 64 buttons.

In fact, I added them into the circuit between the 4532s/4071 and the 4050.  This was an old design from a few years ago, which I’d just got round to finishing: if I was to redesign it now I’d put in a duplicate 4050 – one for the LEDs, one for the output, just to make sure the circuit would operate reliably.  I’ll keep an eye on it and make sure I get the output I’m expecting at all times.

As can be seen from the photographs, the particular chessboard I used was a small travelling set, which would normally be folded in half, with the pieces kept safe inside.   I arranged it so the board could still be folded and the circuitry – including the battery and the inline DIN socket – retained within.  In the end I replaced the battery with a 3.5mm socket – in common with many of my instruments – as this was a more versatile method of powering the circuit.

The only problem remaining at the end was that the circuit board was not quite thin enough to enable the board to be opened up and laid flat to be played, so some inserts need to be added to raise the base a little higher.  I’ll add a picture when I’ve worked out the best way to do this.


The MIDI CPU Project – 1. The Hardware

I should have done this project 5 years or more ago!  However, illness, retirement and moving house all conspired to delay my progress.

When I finally came to put into action the plans I had drawn up in 2010, when I bought the module I’m about to describe, I found the device had been discontinued and support was about to cease – a great shame, because Highly Liquid, the company that made the MIDI CPU, were second to none in their support of every type of hobbyist and constructor who used their products (they made some other great devices, too), and their forum was – well, still is, until the end of this year (2017) – a mine of information.

So, my description of my endeavours is unlikely to help anyone embarking on the same project, but it might, on the other hand, be of interest to someone attempting something similar.

[Edit: also, see below for further information on the possible continued existence of the MIDI CPU and other Highly Liquid products (including the MIDI widget, which is the opposite of the MIDI CPU, i.e. a MIDI decoder).  There is a connection with, which is run by the same guy, John Staskevitch, and which is home to his current projects].

First of all, then, the MIDI CPU – what is it?

This is what it looks like:

It’s a small board, about  7 or 8cm long by 3 or 4cm wide with sufficient components to function as a MIDI controller.  Exactly what kind of MIDI controller depends on you: each of the 24 control terminals along the top edge of the board in the picture above can be programmed via SysEx to perform various logic or analog functions – i.e. they can be configured as switches for notes, switches for MIDI control messages, inputs from potentiometers, pitch and mod wheels, and so forth, whatever your application requires.

The 8 connections on the right-hand side are jumpers to set the MIDI channel, if you don’t want to have to set this as part of the programming.  The 4 pairs of connections are marked 1, 2, 4,and 8, so connecting them to +v or 0v like a binary number will set the channel.  Leaving them disconnected is effectively 0000, binary zero, or channel 1; connecting all of them is 1111, binary 15 (8+4+2+1), or channel 16, and so on.

The 5 connections at the bottom right are MIDI in and out, so the MIDI CPU can be connected to a computer and other MIDI equipment via conventional 5-pin MIDI sockets.

As I say, it’s sadly not being marketed any longer by Highly Liquid, although I see the boards, firmware and detailed information do now appear on and, so it might be possible to obtain one after all, even if you have to solder it together yourself.  It seemed to me at the time an ideal purchase, due to its simplicity and versatility.  The cost was reasonable, around £40, as I recall.  I elected to make it a little more complicated than it needed to be, but you could, with minimal external wiring, create quite a complex MIDI instrument with it – 24 control terminals is plenty for a switch matrix, mod wheels and various other controls.


So, what did I do with it?  Well, I had alluded before, in my post on ‘A new use for USB keyboards‘, to a MIDI project which was going to fill up the rest of the enclosure which then included – amongst other things – the PCB out of an old Apple keyboard, and the MIDI CPU was this project.

Some buttons and modulation wheels would be built into the box, but essentially the MIDI CPU board would be accessed via a 25-way socket on the back of the enclosure, so any one of a number of different devices could be attached, and the MIDI CPU could when necessary be reprogrammed to allow for different uses of its control terminals.


This is what the enclosure looked like when I left it, and I now set about filling the top half with the MIDI CPU board and associated circuitry.

The first thing I wanted to do was to add pitch and mod wheels, buttons and potentiometers.

For the potentiometers I used the type with an integral press switch – if the external unit plugged into the 25-way socket had its own, I wanted these to be able to be taken out of the circuit.

For the pitch and mod wheels I bought a set off eBay which originally came from a DX7 or some such.  These were pre-wired and ideal for the purpose – the pitch wheel was properly sprung to return to centre – and were only about £10.

Conscious of the space problem, I decided on an unusual solution for the buttons: a 16-button keypad.  Although this looked like any keypad, internally it was rather untypical.

Keypads are normally arranged in a matrix pattern, so the output leads are ‘Column 1’, ‘Row 1’,  ‘Column 2’, ‘Row 2’ etc., and each button is in a unique position at the junction of a particular row and column; but this was a special design where each of the 16 buttons, when pressed, was simply connected to a common input.  I connected the common input to 0v, so that a button, when pressed, would be able to ground one of the MIDI CPU’s control terminals.  This is the signal the terminals need to be activated.

As far as momentary button presses were concerned, this was ideal, but to create latching switches – switches that stayed on until pressed again – extra circuitry was necessary.  What I used was a system with 4 ‘flip-flops’, plus a few signal inverters to make sure the flip-flop would be activated by a positive pulse, but the MIDI CPU control terminal would be activated by a negative pulse.  There were to be 4 latching switches, so 4 circuits like this were needed:

Each of the circuits uses half a 4013 flip-flop chip, and half a 40106, which has 6 inverting gates altogether.  The input to the inverter on the left is kept high, so the output of the 4013 is kept low; the inverter in the middle keeps the MIDI CPU control terminal high, and the inverter on the right keeps the anode of the LED low.  In this way the MIDI CPU control terminal and the LED are both off until the switch on the left is pressed; when the switch is pressed the 4013 output changes state, the MIDI CPU control terminal and the LED are both switched on, and stay on until the switch is pressed again and the 4013 changes state again.

I added a 4-way switch so that all the latching buttons could be taken out of circuit if the external unit plugged into the 25-way socket had its own, or didn’t need them.

Finally, I wanted to add a MIDI channel selector switch, rather than rely on  programming to provide the channel, or hard-wire the jumpers on the MIDI CPU board (described above) to fix the channel permanently.

I got this idea from the Highly Liquid Forum.  The selector switch I used was a type of rotary encoder – specifically a hex encoder, which had 16 positions, and 4 outputs, which could output a binary number in each of these 16 positions, going from zero (0000) to 15 (1111).  (I had used one of these before, in creating the Bigfoot automatic stylophone controller).

The beauty of using this particular type of encoder – and they aren’t all the same, by any means – is that each of the 4 outputs is connected to a common terminal when it’s set at 1, but not connected when it’s at 0.  At the beginning (0000), none of the 4 outputs are connected to the common terminal; at the end (1111), all of them are; and in between (e.g. 0101) some of them are and some of them aren’t.  If the common terminal is connected to +v, then the 4 outputs can all be inputs to electronic switches, turning on when set at 1, turning off when set at 0.

A suitable electronic switch is the 4066, which has 4 switches in one chip, just right for the 4 connections which need to be made on the MIDI CPU board to change the MIDI Channel anywhere from 0 to 15, which represents the full number of MIDI Channels 1 to 16.

I also wanted to add an indicator of what MIDI channel was currently set.  To do this I used a chip which you’ve seen me use before, the 4067.  As luck would have it, this chip also requires a binary number from 0000 to 1111 as its input, and for each of these 16 different inputs it connects one of its 16 different outputs to a common terminal.  So, in this case I made the common terminal +v – via a small resistor – and connected 16 LEDS from the outputs to 0v.  In this way, as the MIDI channel changes, a different LED is lit up – no need for them all to have their own LED, as only one of them will ever be lit at one time.

The simple, but effective circuit, looked like this:


I then needed to connect everything together, and the quantity of components and wires in the  enclosure – as so often with my projects – began to increase rapidly.

The keypad with the white buttons is the keypad I was describing above; in the first configuration I made of the MIDI CPU’s control terminals, the keys with letters play the appropriate notes of the scale: A, B, C, D, E and F; O plays A#/Bb, and 9 plays G; the other 8 numbered keys are divided between latching and momentary switches.

The keypad with the black buttons is not part of the MIDI CPU project: it’s connected to the USB keyboard PCB shown in the first picture of the inside of the enclosure above.  The numbers and letters it produces are useful in applications created with, for example, PureData, where the input can be interpreted in many different ways, as required.

The pitch and mod wheels can be seen on the left and the 16 MIDI channel indicator LEDs on the right.


In this view of the partially complete project, you can see 1. the MIDI channel circuit; 2. the MIDI CPU board; 3. the pitch  and mod wheels; and 4. the latching switch circuit.

The MIDI CPU board needs at this point to be connected to the MIDI in and out sockets and the 25-way socket for the control terminals, and the two keypads need to be connected to the USB keyboard PCB (upper keypad) and the MIDI CPU board (lower keypad).


I finished all the remaining interior connections, and the inside now looked like this:

I removed the excess wiring from the MIDI to USB board (removed from a commercial product, as described in the earlier post linked to above), which is now tucked under the long Apple keyboard PCB on the left-hand side; but the extra wiring from the MIDI CPU board to the internal switches and potentiometers and the external 25-way socket had still over-filled the enclosure!  This view from the outside makes it even more apparent that the box wasn’t going to close:

So I was going to have to do something to make the interior larger before the unit could be used!

Nevertheless, every part of the circuit was now connected up, and it was going to be possible to test it.  I gingerly connected power and switched on.  Lights appeared – a blue light for power, indicator lights where potentiometers were pressed down for on; very bright lights in the centre where latching switches were on; the ‘MOD’ light, to indicate that the ‘Select’ switch for the ‘spare’ control terminal was turned to the modulation wheel position; a light in the MIDI Channel indicator column on the right, and – most crucially – the ‘Activity’ light (not yet labelled, but above the ‘power’ LED), connected directly to the MIDI CPU board, flickered on power up to indicate that it was ready for action.

There was no instrument connected to the 25-way socket – I haven’t yet made any! – but there were enough controls on the box to test a good deal of functionality, including note on and off information from some of the keypad buttons.

Part 2 of this series describes the software, programming and testing of the MIDI CPU box.


The Superstylonanophone 2 – Foot Controller

[Note: this post was originally a comment on the post ‘The Superstylonanophone‘, but it was hard to find there and the images disappeared when I changed my website. where they were stored.  So I’ve trashed the comment and transferred the text and images here].

I mentioned in the above post that a foot controller would be useful for playing drums via the Superstylonanphone, and that I had added a 15-pin socket to the back of the device for this purpose.

This is the controller I made for it:

Yes, it looks like a length of plastic guttering – but I did say somewhere on the blog that I was looking for low-cost ways of achieving things . . . I found this in my garden shed: it was an offcut left over from a length I bought some time ago at a car boot sale.

The player side is to the left, and the 4 single-pole momentary switches are inclined slightly this way, for ease of use. The two on the left are for hi-hat sounds, the two on the right for bass drum sounds. The 15-pin cable is plugged in on the right hand-side, away from the player’s feet.

Inside you can see the simple connections from the switches to the socket – no electronics required, the Superstylonanophone recognises the switch presses and outputs MIDI instructions accordingly.


(When I connected wires inside the Superstylonanophone, I made a diagram to show which notes or which drums were connected to which of the 15 pins, so I knew which pin to connect to which switch in the foot controller).

This, together with the two styluses, has made playing MIDI drums a little more natural on the Superstylonanophone.

[Edit: this foot controller has had further modifications, albeit for a different purpose.  See here.]


Guitar FXBOX – Part 2, the hardware

In my previous post on the FXBOX, I described a series of PureData patches used for guitar effects, and the need for a Foot Controller to operate it.

I happened to have a suitable case for this project – the remains of a previous mixer project which was never entirely finished. It was a large console-style case, about 18″ square, which I had already drilled with about 80 or 90 holes. The holes were too close together for all of them to be foot controller buttons, but about half of them could be used.

Outside of box DSCF0003

There were to be 4 sections to the controller, which would be: 1. Audio in/out and Audio to USB; 2. Audio to MIDI and MIDI to USB; 3. Keyboard Letters and Numbers, output via USB; and 4. Also via USB, Buttons and Potentiometers from a game controller.



The audio section was slightly more complicated than it might have been, as I’ve been using a twin-necked (6 and 12-string) guitar, and at some point intend to separate the output of the two sets of pickups.  For this reason, I added two audio input channels to the Controller.

The system basically works so that it can accept inputs either via a 6.35mm stereo socket or separate 6.35mm mono sockets, and can be routed either to a 6.35mm or 3.5mm stereo output, or two 6.35mm mono outputs. Each channel has a separate mono Send and Return, and there is stereo Send and Return covering both channels.

Audio DSCF0012

The 3.5mm output was included simply because this is the normal type of audio input socket on a laptop – which I was using to run Pure Data – and this would remove the need for a 6.35mm to 3.5mm adapter. Internally, there are connections to a Sonuus G2M Audio-to-MIDI converter – described in the next section – and an Audio-to-USB converter.

I took a chance on a cheap Audio-to-USB converter. I tried a few of the very cheapest type (99p on eBay), which worked OK, but I experienced too much latency, and these can only be used when the delay between playing and sounding isn’t important – on automatic or aleatory devices, for example. In this case, the next cheapest type (£2) seemed to work fine.


The intention of the Controller was that all four elements (the Audio to USB , the MIDI to USB, the keyboard numbers and letters, and the gamepad controls) would all be capable of output via a single USB socket. To accomplish this, I added an extremely reasonably priced (£3.95) 7-input USB hub. Given the number of items it would need to cope with, I got a powered one, which came with a 2-amp 5v mains adapter.

The inside of the box was going to be a bit like an enclosed pedalboard, and I simply velcroed this unit in position inside the case.

7 port hub

The hub was connected to a double USB socket unit – the type that would be fitted on a PC – with one socket connected to the type B output socket on the hub, the other one serving as an extra external input.



I added the MIDI section for two reasons: the first was that although MIDI implementation wasn’t really the point of this Controller, it could, I thought, come in handy for later applications, and be a convenient place to house my Sonuus G2M – a monophonic guitar-to-midi converter. The G2M, like the USB hub, was velcroed in place and linked up via internally-connected plugs.

G2M 27589983

Secondly, I’d successfully used a very cheap MIDI-to-USB converter in a previous project (‘A new use for USB keyboards‘), and decided for £3 or £4 that one could be included here. In this case, I didn’t even remove the outer casing as I had done the previous time, but simply shortened the IN, OUT and USB leads to fit and velcroed the unit to the inside of the case.

MIDI Inside box 1 DSCF0001

Audio and MIDI inputs would normally be via internal connections, but I added two 5-pin DIN sockets to the outside of the case. The first was for MIDI Out; the second, via a DPDT toggle switch, allowed input to the converter to be internal or external in case I wanted to connect a MIDI instrument or controller, such as my Behringer FCB1010, use another audio-to-MIDI converter, or decided not to use the G2M inside the case.




I had worked out for the previous project referred to above how to use the PCB from a defunct Apple keyboard as a means of outputting ASCII codes. The [key] function of Pure Data can be made to interpret and take action on these in any way required. I wanted to include this feature to help in using my looping program, Jesse Chappell’s Sooper Looper.


As well as being controllable via MIDI, many of the Sooper Looper functions are controllable by input from the computer keyboard.  I wanted to include a simple system which would output some of the keyboard letters required to record, overdub, reverse and so on.

A 10×4 matrix would output all the letters in the alphabet, and the numbers 0-9, so I could put up to 40 buttons on the Controller (including a couple which represented punctuation marks), but I wouldn’t need anything like 40 buttons for this application.

I started confidently, as before, disassembled one of my collection of broken keyboards and took out the PCB.  It was very similar to the one I had used before: very wide, and with two USB input sockets on the ends – but it was a completely different make! So, I plugged the USB out cable into the computer, got the crocodile clips out, started up Open Office and began touching the matrix points together to see what letters came out – it had an entirely different layout from the one I’d used before!

However, after a certain amount of testing, it became clear that the matrix lines were essentially the same, but just in a different order on the board, which meant I could still get the 40 letters and numbers I wanted, and the pinouts on the sockets I planned to use (15 pin DIN HD) would still be compatible with the unit I had previously built.

In fact, it didn’t really matter about compatibility, as this would – at least as initially conceived – be a self-contained Controller unit, but I wanted to keep things consistent across my range of devices, and perhaps at a later date allow for an alternative or supplementary control unit to be connected to the Foot Controller.

I carefully connected the appropriate pins of the matrix to a ‘break out’ board, to which I connected a 15-way PCB header.

Apple PCB DSCF0004

This would make it a relatively simple job to connect buttons later.



Again, I had used a game controller before, for the Theresynth/Cybersynth project, using the PureData [hid] function; but this time I needed to be more ambitious and use the joystick potentiometers as well as the buttons.

Of course, there are companies which produce USB controller modules, mainly for arcade controller enthusiasts, for example Ultimarc:, and GroovyGameGear:  The best value seemed to be the ZD (Zero Delay) Arcade controller, which is readily available on eBay.

Arcade Controller

I bought a couple of these two years ago at £8 each, but they seem to be even cheaper nowadays.

Good though they are, however, these units are limited to 12 buttons and two potentiometers.  Game controllers tend to have quite a large number of buttons – especially if you include the hatswitch buttons – and potentiometers on a single circuit board.

I needed 18 buttons, so I decided to use a game controller board for this part of the project.

There are a number of explanatory articles on the internet, such as this one:, and a lot of valuable information on this forum:, as well as a few videos on YouTube. I like this one, which, although not captioned in English, is nicely visual:

Even Nic Collins’ classic book Handmade Electronic Music [] has a chapter on the subject.

There are many different makes and models of gamepad, and one thing I’ve learned is that they’re all different – or liable to be different – in their electrical connections, so a certain amount of cautious experimentation is required to find out, for example, whether button connections are made to ground or some other voltage value in the circuit; if they’re arranged in a matrix; or if there’s a mixture of different systems. Sometimes this can readily be determined by looking closely at the circuit board and following the tracks around, sometimes it can’t.

So, if you’re reading this for hints on how to make the connections, use it as a guide to the type of thing you may need to do, but you may not necessarily be able to copy the steps precisely.

The other thing to note is that the connections on these PCB’s are usually very delicate, so you need to proceed carefully to avoid the narrow copper tracks coming away from the board.

As far as my gamepad was concerned, I used a Nyko Airflo, which was around £5 on eBay.

I removed the outside and an internal plastic piece which supported the two main PCBs and the fan which gives the Airflo its name.

Disassembled 2 IMG_1647

The idea was to reconnect the gamepad’s buttons to buttons on the FXBOX foot controller, so I detached the fan and looked for the button connections on the PCBs.

PCB 1 & 2 IMG_1650

Four of the 12 buttons were on their own mini-PCBs, connected by wires to the main board; the function of the wires was marked on the board, so I cut off the small PCBs and left the wires.

The various hatswitch connections and 6 of the remaining buttons were on the main board. These all had suitable spots in the copper tracks where it would be possible to solder wires.

The remaining two buttons were part of the joystick assembly on the second main board. It was easy to see the connections, and as the buttons were normally open (not connected), it would just be necessary to connect wires to the two sides of each one – or one side if the buttons all proved to have a common side, which is the usual practice.

I also needed to use the 4 potentiometers, two on each joystick, and wasn’t looking forward to de-soldering them, as I was anxious about damaging the tracks on the board. It doesn’t look too difficult on the videos, but I noticed on mine that there was small gap above the board where you could see the three legs of each potentiometer – the small ‘preset’ type – just enough room to insert a hacksaw blade and cut them off.   This is what I planned to do.


First, as with the other devices in the Controller, I needed a much shorter USB out cable to connect to the hub, so I shortened the lead, but reconnected it before going any further, as this would be needed for testing.

The next step was to bring out the button connections to a ‘breakout’ board and find out exactly which ones I needed.

In most cases – perhaps all – I was sure that it wouldn’t be necessary to use 2 wires per button, as I had done with the Cybersynth; one side of the button connection would usually be Ground, and I hoped it would be possible to use one Ground connection for all of the 12 buttons.

This did prove to be the case, and I didn’t have the problem reported by some others of the unit not working at all without the joysticks connected.

I connected the 13 wires (one for each button + one for Ground) from the gamepad board to the breakout board, and a 13-way PCB header to give easy access to them.

The hatswitch connections looked as if they might be the same – except that there were 4 buttons, and I knew that 8 separate outputs are available from a hatswitch, meaning that 4 outputs were available from the 4 buttons individually and 4 outputs were available by connecting adjacent buttons simultaneously.

To make it easy to access these 8 outputs with 8 separate buttons, I connected diodes like this: hatswitch diodes

The connections at the top go to buttons in the Controller, and connections 1, 3, 5 and 7 at the bottom go to the 4 button positions on the circuit board; connections 2, 4, 6, 8 and 9 don’t need to be connected directly to the board.

This arrangement means that, for example, pressing Button 1 activates only Button 1, and pressing Button 3 activates only Button 3, but pressing Button 2 activates both Buttons 1 and 3 at the same time.

Only adjacent buttons are meant to be connected at the same time, which is why a hatswitch has 8 different outputs; but I discovered that connecting any two non-adjacent buttons on this particular board produced a ninth different output, recognised by PureData, which is why a ninth button is shown.

As a Ground connection was already available on the breakout board, I only needed 9 further connections for the 9 hatswitch buttons. This meant that 21 separate buttons would be available altogether.


The next task was to replace the two 2-axis joysticks with 4 potentiometers. Two of these would eventually be footpedals so that certain settings – volume and pan, for example – could be adjusted while playing.

I started by cutting through the legs of the existing potentiometers, as described above.  Once cut off, the potentiometers were easy to remove, exposing the three connections for each one.

Tracing the lines on the PCB, I could see that the ‘top’ and ‘bottom’ connections of each one were the same: only the middle pins had individual connections.

The bodies of the joysticks didn’t need to be removed from the board – and in fact were best left where they were, as some Ground connections from one part of the board to another appear to made through them.

I knew the potentiometers were likely to be more difficult to make use of than the buttons, but I was puzzled that I wasn’t able to get them working easily when I connected them to the board. For some reason they didn’t move smoothly from zero at one end to 255 the other as they were supposed to; on occasions they would return to zero and then refuse to move.

In the end, I read something that doesn’t seem to be mentioned much in articles on gamepad hacking, which seemed to be the root of the problem: joysticks are sprung to return to the centre of their travel, so a gamepad is expecting a midway reading on each one when it’s plugged in, and calibrates itself at that point to make sure the joysticks go back to the middle when let go. If potentiometers are used, and left at random values when the unit is plugged in, then the gamepad will get confused, try to calibrate itself wrong, and consequently fail to work properly – or at all.

The value of the joysticks in my gamepad was 100k, and they looked to be connected as voltage dividers, with the ‘top’ and ‘bottom’ tags all connected together, so, assuming these were +v and 0v (although it doesn’t really matter what they are) – I created a midpoint 50k from the top and 50k from the bottom (two 100k resistors in series = 50k). This would be connected to the centre tags of the potentiometer inputs to the board when the unit was turned on, the circuit would be calibrated, then the actual potentiometers could be connected and would correctly produce values from 0 – 255.

The writer of the article quoted above [] had a neat solution to this, using switched jack sockets, but I wasn’t able to use this method, as I wasn’t always going to be plugging into sockets. Instead, I connected the centre tags of the four potentiometer inputs to the centre tags on a 4 pole, two-way switch: this switch would be in the ‘off’ position when the unit was plugged in, which would connect the inputs to the ‘halfway’ voltage, enabling them to be calibrated, then when the unit was ready to be used the switch would be moved to the ‘on’ position, where the potentiometer inputs would be connected to actual potentiometers.

As a result, I ended up with a breakout board with 12 pins representing the 12 buttons numbered on the board, 9 pins representing the hatswitch buttons, 4 pins representing the 4 potentiometer outputs, and 3 pins representing +5v, 0v and +2.5v.

I also used 2 further pins for the game controller LED which lit up when the USB connection was made: I connected these to an LED on the outside of the case where I could see it and verify that the board was working.

That made 30 pins. Even when I calculated that I needed only 6 of the 9 hatswitch buttons, that still made 27 pins, plus 15 pins from the Apple keyboard PCB described earlier.

All the connections needed to be in place while the case was still open, so I needed to join all these pins on one side of the box where the circuit boards were to connectors on the other side of the box where the buttons were. To bridge this gap, I decided to use 40-pin ATA cables, normally found inside a desktop PC, which are inexpensive and compatible with the PCB connectors I was using.

ATA cables

These cables (as in the above picture) frequently have two separate connectors quite close together at one end. This made it easier to make connections not only from one side to the other, but also to special output sockets on the back of the case.  These could be used if alternatives were required to the buttons on the unit.

The 15-way socket on the back of the Controller has the same pin designations as my previous keyboard PCB-based project; the 25-way socket is a new arrangement, specific to the game controller:

Keybd & HID out DSCF0012


Finally, there was one downside with internal fixing of the Sonuus G2M ‘Guitar to MIDI’ unit – it runs off a PP3 battery: this would mean firstly that the ‘Battery low’ indicator couldn’t be seen from outside the case and secondly that the battery couldn’t be changed without taking the case apart. As this is held together with about 10 self-tapping screws, this would be too much trouble.

The main electrical supply was the the 5v adaptor that came with the USB hub, so I bought a small step-up voltage module for a couple of pounds to provide a 9v supply for the G2M.

voltage converter

I adjusted it to slightly over 9 volts, to make sure the G2M would be operated reliably and added a second power on/off switch for the 9v supply.


This is the almost finished base of the unit, showing the 7 elements.  All the connections are in place, except the power connector lead, which runs from connector 7 in the picture over to the power switches on the front of the unit:

Inside captioned IMG_1397

1: MIDI to USB

2: 7-port USB hub

3: Audio to USB

4: Apple keyboard PCB

5: Sonuus G2M, Audio to MIDI

6: Gamepad PCB

7: Power connector

This is the almost complete top section:

Top captioned IMG_1395

I gingerly put the two halves of the case together, and all the functions seemed to work, so I screwed it firmly together.

Now, with minimum use of the laptop keyboard, I was able to control the Looper with the buttons on the Top Panel:

Top Panel DSCF0009

and the FXBOX PureData program with the buttons on the Front Panel:

Front panel DSCF0010

I left space for additional button descriptions as the unit isn’t limited to controlling the Sooper Looper and FXBOX: in fact, it could be used to control any PureData patches which required [key] or [hid] inputs.

In addition to this, I had made provision on the front of the case for 4 footswitches which could duplicate the effect of any of the buttons on the panels:

Front DSCF0011

So far, I have just implemented two of the four possible: Footswitch 1 duplicates the ‘Overdub’ control in the Looper; Footswitch 4 duplicates the FXBOX ‘Freeze’ control.

I obtained some very nice momentary footswitches for only about £3 each from eBay.  They are apparently intended to operate tattoo machines, and have the advantage of coming with 1/4″ (6.35mm) standard mono jack sockets attached, perfect for this application.

tattoo switches

As for the footpedals, I haven’t implemented those yet.  When I do, I’ll describe this in a further post.


The X-Terminator, Part 2 – ORAC

After finishing the X-Terminator, which worked exactly as described, I began to think of additions that could be made to it – two in particular, which I thought might be useful.

This extract from the circuit diagram shows the one slight change I had made from the original circuit of the Cacophonator – replacing the latching switch and the momentary push button with a single toggle switch, latching in one direction, momentary in the other:

Cacophonator Power

It also shows the very big capacitor, C7, which enables the X-Terminator to keep sounding for some time after being charged by a quick press of the momentary switch connected to +V.

First of all, the original description mentions that ‘the discharge period for C7 [i.e. how long it keeps sounding] is affected by the load at the audio output, which should therefore be a high impedance in order to obtain this period.’

Rather than rely on the vagaries of whichever unit the X-Terminator might be plugged into, I decided to provide it with its own high impedance circuit to maximise the period for which it would sound.  This circuit would be a completely separate unit, connected to a different power supply, so as not to interfere with the working of the X-Terminator.


Secondly, I thought it would be handy to have a method of automatically retriggering the device after a set interval: a variable, but fairly long interval – up to a couple of minutes – to give it time to finish ‘winding down’.

In order to provide an external method of doing this,  I added a socket in parallel with the switch, which would connect to the new unit:

Cacophonator Power Rev


I was intending to use a suitable Dr Who-related case for the project, but couldn’t find a model of K9 which was big enough.  The only K9 I could get hold of was very small, and not really of sufficient size to contain any worthwhile circuitry.  So, in the end I had to be satisfied with adding a second 2.5mm socket which would allow a button on the small K9 to operate another of the samples in the Dr Who talking keyring which had been incorporated into the X-Terminator case (the Dalek).


New sockets on the back of the X-Terminator

The button was a tiny tactile switch connected to to a 2-way cable which terminated in a 2.5mm mono plug.  This fitted into a new socket on the back of the Dalek which was wired to the keyring PCB.

The K9 model itself was not only small – approximately 7cm from nose to tail – but rather too light, so I added some weights to give it a bit more body.  These could be useful in other situations where a case might not be heavy enough to resist being dragged about.


Originally intended for tyre balancing, these were either 5g or 10g and were sticky on the back, so they could be cut from the strip and easily fixed in place.  I used one of each in the base of the K9 before gluing it back together:

K9 IMG_1511

When the button is pressed, the response ‘Affirmative’ is given.  This, of course, comes from the speaker in the base of the Dalek.


When it came to the audio section of the unit, I had a clear plan, which would use a quad op-amp: at first an LM324, of which I had several lying about, to be replaced by a TL074 if the audio quality of the LM324 wasn’t good enough, as I had read might be the case. These two chips have exactly the same pinout, so a swap would be perfectly possible once the circuit was up and running.

The reason I wanted a quad op amp was because the first would be used as a high impedence buffer (or non-amplifying amplifier), while the other three would form a phase-shift-type stereo simulator.  The circuit looked like this:

Phase shift Pseudo stereo2

I connected it up, but for some reason it wouldn’t work, the output was mono and the cacophonator would still not continue sounding for more than about 15-20 seconds. I removed the battery to do some further testing and . . . the circuit worked perfectly: a noticeably stereo sound and up to a minute of cacophony while the big capacitor slowly discharged . . .

I tried removing the LM324, but the sound reverted to mono . . . I noticed the input signal and 0v leads were connected the wrong way round so I changed them . . . but the sound reverted to mono . . . so I just left the chip in and removed the power leads.  I really have no idea why it worked – at least to an extent – in this condition: maybe the collection of components forms a kind of filter network, affecting one channel differently to the other . . . however, it worked, so that was fine by me.  Perhaps I’ll go back to it later and try and sort it out properly . . .


So much for the audio section.  Turning to the auto-trigger section, the requirement here was for a circuit which would briefly close the switch to charge up the big capacitor, wait for a certain length of time for the resultant cacophony to subside, then repeat the process, and continue repeating at intervals until turned off.  The sonic results of this would be more interesting than leaving the switch permanently on.

As previously mentioned, this could only be done by a circuit kept separate from the X-Terminator circuit if the latter was to run as intended.  So I decided to use an electronic switch, one of the four such switches in a 4066 integrated circuit:

4066 pinout

The two sides of the charging switch  – brought into the unit via a 2.5mm mono socket – would be connected to, for example, pins 1 and 2 in the above pinout diagram.  Normally, pins 1 and 2 remain unconnected, as their control pin, pin 13, is held low – i.e. connected to 0v by a 100k resistor.  The lines to pins 1 and 2 can be connected together, like throwing a switch, by inputting a +V pulse into pin 13.

In the final version I used pins 10 and 11, rather than 1 and 2, with the control signal going into pin 12, but the effect was exactly the same: a +V pulse into pin 12 would connect the switch and trigger a new cycle of cacophony from the  X-Terminator.

I planned to add a push-button on the top of the unit and a 6.35mm mono socket for a momentary footswitch.  These would both be capable of sending a +V pulse into pin 13 and trigger the charge switch as an alternative to the switch on the X-Terminator itself.

However, my main objective was to have this done automatically.

The way to do this, I reasoned, was to use a very common timer or oscillator chip, the 555.  A 555 set up in astable (‘continuous’) mode, but running very, very slowly, with a variable control to go from 0v to +V at intervals of between 10 to 15 seconds minimum and one or two minutes maximum.  In addition, the ratio between the ‘on’ (+V) time and ‘off’ (0v) time would be set so that it was mostly off, and turn on briefly for a suitably short length of time to operate the trigger.

The typical connections for a 555 in astable mode are like this:

ORAC Timer circuit diagramThe frequency at which the circuit oscillates (goes from 0v to +v and +v to 0v) is determined by the three components Ra, Rb and C.  The way to allow the circuit to oscillate at a range of frequencies is to put a potentiometer in place of Rb.

The version of the circuit I used has an extra component which isn’t normally necessary.  This is the diode in parallel with Rb, between pins 6 and 7.  The purpose of this is to allow the time the circuit spends at +v to be much shorter than the time it spends at 0v.  The effect of this will be that if it’s oscillating at a very slow rate – say once a minute – there will just be a short pulse at the beginning of the minute to trigger the X-Terminator, and then the trigger signal will remain off until the next minute begins.

A preset variable resistor in place of Ra can be used to increase or decrease the length of the pulse, to make sure the X-Terminator is reliably triggered.

There are numerous places on the internet to find out more about the very useful little 555.  Some of my favourites are and


As for the case itself, this ended up less as Dr Who, more like ORAC from Blake’s 7.  Not very like ORAC, really . . . but it was transparent and had flashing lights in it, which was near enough for me!

While researching a suitable 555 timer circuit for the automatic trigger, I came across (here: a circuit for turning 9 groups of 3 LEDs on and off in sequence, using another 555 and a 4020, a counter with up to 14 stages.

LED circuit

The 27 LEDs are typically arranged in a cube shape, and I thought something like this would be an attractive indicator that the automatic trigger was on.  So along with the circuitry I began supergluing LEDs on the inside of the transparent plastic box.

Just to make it different – and to cut down slightly on the number of LEDs – I used 4 red-blue bi-colour LEDs.  These have 3 legs, so each would have to be last in a series of 3, enabling each of the two outer (anode) legs to be the end of a series of 3, and the centre (cathode) leg to be connected to ground.


So the timer/flashing light part of the circuit needed two 555’s, a 4020 and a 4066.  Rather than use two 555’s, I used a 556 – a dual 555 – and the final circuit looked like this:

ORAC Circuit Diagram

Wiring all the LEDs together was quite tricky, but gradually it all began to come together . . .


. . . and I was delighted when I connected a battery and the lights began to flash!


I needed to protect some parts with bubble-wrap, to avoid short circuits, but when the lid was back on, and the trigger and audio were connected to the X-Terminator, it operated exactly as intended.

This has added some extra and very useful functionality to the original ‘Cacophonator’ circuit.

The finished ORAC:



ORAC in use with the X-Terminator and the Taurus amplifier:Orac & X-Terminator

and with the external footswitch attached:

ORAC & FootswitchHere’s what they sound like:


Incidentally, it was only shortly before I began on this series of posts that the inventor of the 555 died in Los Altos, California.

Born in 1934, Hans Camenzind came to the United States from his native Switzerland in 1960.  At first he worked for various companies in the newly developing semiconductor industry, such as Transitron, Tyco Semiconductor, and Signetics, then in 1971 formed his own company, InterDesign,  specializing in semi-custom integrated circuit design.

It was there, working under a contract with Signetics, that he invented the 555 timer, one of the most successful chips in the history of the semiconductor industry, and one which is still widely used today. Versions of the device have been or are still made by dozens of major semiconductor vendors, including Texas Instruments, Intersil, Maxim, Avago, Exar, Fairchild, NXP and STMicroelectronics.

Camenzind also introduced the idea of phase-locked loop to design and invented the first class D amplifier.  Altogether he was named as inventor in 20 patents.  He was a prolific author with interests as diverse as electronics textbooks and the history of the semiconductor industry, to a book on God and religion.  He also lectured at the University of Santa Clara.

His last book, Much Ado About Almost Nothing, subtitled A history of electricity and electronics, written for the non-expert, sounds quite interesting.  You can read about it at


Notes on game controllers

I decided to write this post just to tie together some of my experiences of using game controllers of various sorts to make music.

Generic USB controllers like these are generally pretty easy to use:

Game Controller 3


Since computers come with USB ports on them, it’s usually just a case of plug them in and get going.  There are lots of them about and they can be picked up cheaply on eBay and Gumtree or from local charity shops.

The main consideration is what program to use which can interpret the signals the controller is sending out and allow you to use those signals for your own purposes.  There are many of these, ranging from simple apps to tweak the operation of a particular device, to large and complex  programs designed to customise a device’s every action to the user’s requirements.

This is made possible by the existence of the ‘HID’ standard for USB devices.  HID = ‘Human Interface Device’, a description which can be used to cover devices such as computer keyboards, mice, game controllers, joysticks, and the like – all the things which humans use to interact with computers.  As long as the device is made to conform to the standard – and manufacturers have readily got used to the idea of doing so – these programs can interpret the input and make it available to be changed to a different input; to perform an action completely unrelated to the device’s original purpose; or send data to another program which can use it creatively.

I’ve used several of these for different purposes.  There’s Multicontrol, which I used for this MIDI Drum controller:


Multicontrol has the ability to interpret the game controller’s signals and pass them on in the form of MIDI messages, or OSC (Open Sound Control).  Designed by Alexander Refsum Jensenius, it’s distributed free for Mac OS.  There is a source file downloadable from the site referenced above, although I have no idea if this can be compiled for Windows PC’s.

I’ve also used a commercial program, ControllerMate, which enables very sophisticated interpretation of controller signals.  This allows not only for simple button ‘mapping’, where you specify, for example, keystrokes for each controller button, but also, with this window you can build up complicated series of events, initiated by a button press.:

ControllerMate window

The small drop-down list to the right indicates the wide variety of actions that can be incorporated into the instructions for each button or other control.

The list in the left-hand column indicates a couple of devices which I’ve made customised groups of special controls for: once you’ve set the controls up, you can save them and call them up by name.  It’s possible in this way to have several different set-ups for the same device, depending on what you want to use it for at different times.


My favourite program is PureData, or Pd for short.  Using Pd means you have to write the programs yourself – but this is done graphically, rather in the manner of flow-charts, rather than by writing lines of code, and the program is specifically designed for making music, so it has typical audio and MIDI functions (Pd calls them ‘objects’) ready to use.

I’ve used Pd both for creating instruments, like the Theresynth, which uses the PCLine Rumble Pad pictured above, and for sound and sample manipulation.  The blog post for the Theresynth (which uses one of the joysticks on the controller for changing pitch in a way reminiscent of a theremin), also has quite a detailed description of the Pd programming.  I’ve also blogged about various sound manipulation apps (or ‘patches’) in the past, including the StyloSim, which uses the joystick controller pictured above, and the Black Widow.

The StyloSim patch isn’t very extensive, and looks like this:


The small box with ‘hid’ in it, near the top right-hand corner, is the Pd object which recognises input in the HID standard; the ‘route’ objects below split up the different inputs, and then you can send them off to do whatever you need them to do – control oscillators or filters, perform mathematical functions, create MIDI messages, and so on.

While on the subject of software, a handy piece of freeware which I often use is Joystick and Gamepad Tester from AlphaOmega Software.  AlphaOmega produce a number of simple but ingenious apps which help you with your Mac, including an app which cuts out that annoying ‘chime’ when the computer opens (my car doesn’t sing at me when I turn the ignition, my hi-fi stays silent until I put in a CD, my TV remains mute until I select a channel – why on earth do computer manufacturers think we want to hear the machine start up!  One of life’s unexplained mysteries . . .), but also some apps which can have a value in computer music.  I may well have blogged about some others elsewhere.

The purpose of Joystick and Gamepad Tester is to tell you what controls your USB device has, and if they are devices like joysticks, what are the minimum and maximum readings you can get from them: 0 – 127, 127 – 255, etc.

I recently bought a game controller like this from a charity shop:

Logitech Buzz

It looked as if it was originally part of a quiz game, and had a USB connector, so it looked as if it would be easy to use with the computer.

I took it home, plugged it in and started up Joystick and Gamepad Tester.


The instructions say to press all the buttons and move joysticks and other controls so they’re recognised. but when I clicked ‘OK’ on the screen above, I saw this:


I found out first of all what the device was – a ‘Logitech Buzz Controller V1’ – and was able to select it from the drop down list.  Note by the way that all the normal USB-connected devices are also listed: in my case, there’s the laptop keyboard, the infrared receiver on the front and the trackpad.

The Apple IR Remote – listed in the screenshot above as ‘IR Receiver’ – isn’t exactly a game controller, and isn’t exactly an HID device like the others discussed here, but it’s worth a brief digression as its uses are very much the same.

As far as  Joystick and Gamepad Tester is concerned, nothing was listed when I selected ‘IR Receiver’ or registered when I pressed buttons on any of my Apple remotes – only when I selected one of the two entries ‘IOSPIRIT IR Receiver Emulation’.  I don’t know why there are two entries, but they’re identical and are the result of installing either the app Remote Buddy, or its free driver Candelair – or very probably both – as I’ve been working on using Apple Remotes recently (see blogposts, starting here).

A useful feature of  Joystick and Gamepad Tester in this respect was that it showed the remote’s individual ID No. in the ‘Now’ column.  (The ID numbers in the ‘Min’ and ‘Max’ columns are irrelevant, as they will just show the highest and lowest Remote ID numbers used in the past).  Just picking up a remote and pressing a button will change the now column to verify the number.

When I selected ‘Logitech Buzz Controller V1’, all the controls were already listed:


There are 5 buttons on each of the controls, and the list suggests that they are unique – that’s quite a decent number of buttons for a game controller, so that could be handy in some situations.  Buttons usually show up with a minimum and maximum of ‘0’, so it was quite interesting see that 4 of them with a different reading in ‘Max’: perhaps these were the big red buttons, one on each handset?

Actually, there weren’t: as you go round the buttons pressing them, you can see exactly which is which – the value appears in the ‘Now’ column: ‘1’ for pressed, ‘0’ for not pressed, which is typical for buttons, so by the time you’ve finished, they all have ‘0’ in the ‘Min’ column and ‘1’ in the ‘Max’ column.  If you’re intending to modify the controller you’re testing by taking it out of its case and fixing new buttons to it, this is very useful because you can make a note at this point of which one is which.

Better still, if you click the ‘Save’ button – indicated by the arrow on the screenshot above – you can save the list as a text file, print it out and make your notes on that.

First you’re given the usual ‘Save’ options:


Then  Joystick and Gamepad Tester confirms that the text file has been saved and it’s safe to quit or begin testing another device.


I was impatient and clicked ‘Save’ before testing all the buttons, so the text file shows an incomplete test – I haven’t verified yet that each of the buttons gives a maximum ‘1’ when pressed and goes back to a minimum ‘0’ when released.


I was intrigued by the two entries at the bottom for ‘X-Axis’ and ‘Y-Axis’.  I studied the device carefully, and could find no control on it which resembled a joystick, which is what an entry like this would be for: data from these sources wouldn’t just be a ‘0’ or ‘1’, but a number moving from perhaps as low as -255 to +255.  I’m assuming this indicated that the chip used in the device is capable of supporting a joystick, but this hasn’t been implemented.  Perhaps, if one knew how, one could hack the PCB which controls the buttons and add this capability.


There are two things worth mentioning about HID devices at this point.  The first is that, provided you leave the USB output leads intact, you can remove the circuit board from the original case, solder your own buttons and potentiometers to it and it will still be recognised as the same device by the computer.  This was the theory tested by the Cybersynth, which is basically a Theresynth, as described above, with the PCB removed from the Rumble Pad and put into a completely different case.  It doesn’t look like it any more, but the computer still thinks it’s a game controller.


In fact, you can also do this with an old computer keyboard.  It’s possible to remove the PCB from these, work out which connections make which letters and wire these connections to your own buttons or switches.  I did this with the board from inside an old Apple keyboard (as described here):

Blueberry keyboardsm

It was very cheap, having been scrapped as being broken, but what was wrong with it was nothing to do with the electronics.  I took the board out, rewired it, and use it for controlling a looping program.

MIDI CPU insidesm

You may be able to tell from this picture – although the scale isn’t particularly evident – that the PCB inside this particular brand of keyboard is ridiculously large.  You could undoubtedly find a make with a much smaller board which would be more practical.

As it happens, I’m using this particular board for an application which requires letters as an input, and no remapping – i.e. ‘A’ is ‘A’, ‘B’ is ‘B’ and so on.  However, since the keyboard is an HID device, using one of the programs above, you could change the functions of the buttons and have a very large number of different control buttons available: the equivalent of 26 letters, 10 numbers, numerous punctuation keys; and programs will normally distinguish between lower and upper case letters, increasing the total number of controls even further.

The second thing to mention is that there are many PCBs on the market with circuitry on them to output HID standard signals, and allowing you to attach your own combinations of buttons, switches, knobs and joysticks.  People who make their own arcade games like them, so this is where you’re likely to come across them (on sites like this, for example).

Some of these are relatively inexpensive.  I got this one, which can encode 12 buttons and 2 joysticks for £8.00, complete with connecting leads for the buttons, joysticks and USB:

Zero Delay Encoder Board Rev2 -2

You have a free choice of what kind of buttons to attach, and using a board like this is easier than extracting and rewiring an existing game controller board


As for other types of controller: there are many.  This one by Nyko for Playstation – which I have in the collection, but haven’t worked on yet – combines the traditional game controller with a QWERTY keyboard:

Nyko IMG_1668

This one, the Airpad, is interesting because it contains a tilt mechanism which enables control by tipping the device up:

Airpad IMG_1667

You may notice something odd about the above two controllers – the funny connectors on the end.  Your computer probably doesn’t have sockets that shape.  This is no problem, though, as Playstation to USB adapters are easy to come by and not expensive.  This one cost less than £2:

PS Adapter IMG_1669

It’s also possible to find extenders and hubs for Playstation devices, and these don’t usually cost much second-hand on eBay:

Extension IMG_1255

Hub IMG_1561

Using PS3 (wireless) controllers is also perfectly possible.  There are drivers for Windows; later versions of Mac OS (from 10.6 upwards, I believe: see here for further details) have drivers built in, using Bluetooth.  Earlier versions of the Mac OS can work with a driver from Tattiebogle.

USB adapters also exist for XBox controllers, although replacing the proprietory connector with a USB plug doesn’t seem difficult,  according to this illustrated article.

[Edit: unfortunately, both the sites I used for this information are unavailable now.  I’ve left the link in case that site’s unavailability is temporary, and I have an image from the other one:

xboxcablemodpaintThis implies that the Xbox cables have wires using the standard USB colour-coding, so if the wire attached to your USB plug uses these standard colours, they can simply be attached like-for-like].

Once again, Tattiebogle provides a driver for wireless XBox controllers – although you’ll also need one of these wireless receivers:

wireless receiver2

Third-party receivers can cost as little as £5.

At the time of writing, the most advanced consumer-oriented controllers are the Nintendo wii and Microsoft’s Kinect.  The wiimote controller is a hand-held device which uses accelerometers and infrared to detect position and motion in addition to control by button-presses; Kinect uses infrared, cameras and microphone to detect spoken commands as well as hand and body positions from a distance.  I’ll be looking at musical uses of these two systems in the next post in this series.


Fun with the Apple IR Remote, Part 3: Additions

In the previous post in this series, I dismantled and modified a white Apple infrared (IR) Remote control.

In this post I describe a foot controller which can be plugged into the DB9 socket on the modified remote, and then go on to consider what you can do if your Mac doesn’t have an IR receiver built in.

I had already constructed a very simple foot controller, which I had used with the Superstylonanophone.  The controller was  – well it was exactly what it looks like: a length of plastic guttering with a few push switches inserted into it, and a multi-way socket.


There were just 4 buttons on the foot controller: two for bass drums and two for hi-hats.  These were connected very simply underneath: one side of each switch was a common connection, the other sides went to 4 appropriate pins on a 15-way D socket.


It occurred to me that the same controller could also be used for the IR Remote, which also required a number of push switches with a common connection.  There would need to be more of them – at least 6 – and an alternative 9-way connector, but provided both connectors weren’t used at the same time, the controller could operate either device.

I had some spare buttons of the same type, so I added 3 extra ones in the spaces between the 4 originals (not in a very straight line between the 4 originals, it has to be said!), a new DB9 connector, and an LED which would come on when the foot controller was connected to the modified remote.

Outside DSCF0004

Only 6 of the buttons were required to duplicate the functioning of the Apple remote.  Using my IR Remote Tester in iRedLite, I verified that all the button presses – short, long and double – were being received and transmitted correctly from the six buttons I had wired up.  I connected the seventh so that the LED – which can be seen illuminated at the bottom of the picture – would go out if it was pressed, as a warning that it had no function.

Inside DSCF0003

I moved the bass drum triggers to the two leftmost buttons, and hi-hat triggers to the two rightmost.  At some point, when I revisit the Superstylonanophone, I can consider adding in further drums as there are now 3 spare buttons in the middle of the controller.

Connection DSCF0002


The foregoing is all very well if you have a MacBook, MacBook Pro or whatever, which has a built-in IR receiver – but what if your Mac doesn’t have this capability?

Fortunately, if this is your situation, all is not lost.  As I implied when discussing Joystick and Gamepad Tester, the Mac’s IR receiver is part of the USB system – this can be verified by checking the machine’s System Profiler:

system profiler ir receiver2

So, to add IR control, the ideal thing to get hold of would be an Apple IR receiver module which has a USB connection.

Luckily just such a device exists!

There may be a number of these, but the one I got was either Apple part number 922-7195 or 922-8355, not sure which: one is from a MacBook 15″, the other from a MacBook Pro; both have an IR receiver input and a USB output, so I daresay both would work equally well in this application.

IR Rec module IMG_0679L

I bought mine here: at a cost of less than £10, including postage from the U.S. – a bargain!

I got the idea for this part of the IR project from this article:  The aim was to install this module in a new case with a USB lead, thus enabling a Mac with no IR receiver to benefit from the remote, or to use  the remote at a distance or from an angle where a direct line of sight to the computer wasn’t available.

The new case I chose was this one:

IR REC front IMG_1567

It’s a Fisher Price ‘CD Player’.  It doesn’t, in fact, play CDs at all, but I picked it partly because of a definite stylistic connection with the modified Apple remote described above, partly because of its large front ‘window’ – which might allow for a certain degree of repositioning of the IR receiver inside – and partly because it was powered by three AA batteries, somewhat similar to the 5v provided by USB.

IR Rec back IMG_1568

I undid the 6 screws in the back (four of them are already out in the above picture, the two at the top remain), revealing the internal structure.

IR Rec inside IMG_1571

It was very well made, and very difficult to get apart as a matter of fact, as the two large white surfaces you can see were glued together.  It looked like blobs of a sticky adhesive which stretched when pulled, so I was able to prise the two halves apart slightly and cut the glue with a craft knife.

The speaker is visible in the top right-hand corner.  One of the three circuit boards in the unit can be seen at the bottom of the back section; the other two are underneath the two sides of the front section.

Circuit boards IMG_1569

The 8 press switches that can be seen on the tops of the circuit boards are operated by the 4 buttons on the front of the unit.  The switches are in pairs and the two switches in each pair are identical.

I tested each switch in turn and noted their outputs.  They worked by cycling through a number of samples: a short bell-like tune, some spoken phrases (‘Sing with me!’, ‘Oh, yeah!’ and ‘Let’s Boogie!’) and some longer songs with voices and instruments (‘One, two, buckle my shoe’, ‘Itsy-bitsy spider’, ‘Row, row, row the boat’, and some songs that sounded as if they may have been specially written for the unit).  Three of the pairs had a 9-step sequence, one of them a 6-step.

I wasn’t, in this instance, interested in the songs, as I wasn’t intending to circuit bend the device, but I wanted the LEDs to come on when IR input was received.  The best LED display was seen while a song was playing; during the bell tune and the spoken phrases the lights came on only for a short time.  The sequences weren’t the same for each button, and I decided that button three (bottom left)  was the best one to concentrate on, as there was a higher proportion of songs in the sequence compared to short phrases.

Steps in the sequence were initiated simply by a short +V pulse to an appropriate point on the PCB, which should be easy to generate.


First of all, however, I needed to connect up the IR receiver module.

Being color-blind, I’m always nervous about connecting up colour-coded wires – especially to a USB plug which would be going into my laptop.  However, the module seemed – to my eyes at least! – to follow the conventional red-white-green-black USB wiring scheme (+5v, Data +, Data -, Ground, in that order), so I snipped off the small 4-way connector it came with and connected the four wires to a short length of multi-core cable.  The other end of the multi-core cable was connected to a USB plug, via a small PCB connector.  There was no PCB: this was just a convenient way of joining together various wires – the four USB wires, power leads from the batteries and some others I’ll explain shortly.

So, the Apple IR receiver module was connected to a USB plug.  I didn’t want the unit to have a long lead trailing out from it, so the lead to the plug was kept very short, and plugged into a small USB hub which I fixed to the battery compartment lid on the back of the unit:

hub IMG_1585

hub 3 IMG_1587

It was an excellent little hub – only £2 or £3 on eBay, and capable of being powered, if required.
Now ready for testing, the unit looked like this:

The new receiver module can be seen lying in the middle of the front of the unit.  The short USB lead and plug can be seen emerging from the back, and at the bottom of the picture the mini-USB lead goes from the hub to the laptop.  The purpose of the three unused wires in the multi-core cable is explained later on, and is not to do with the Apple receiver.

Checking in the System Profiler, I now saw two IR Receivers instead of one:

System profiler 2510

I experimented simply by covering up one or other of the receivers and making sure, using iRed Lite, that my remotes – especially the new modified one – were able to control various functions in Safari and would print the correct numbers in Text Edit.  The two receivers seemed to work in tandem on the MacBook – it didn’t matter which of the two I covered up, the other would immediately register the button presses and carry out the required function.


The vital question was: what would happen if I connected the unit up to a computer that didn’t have a built-in IR capability?

I started with my eMac, which runs the same OS as the MacBook, 10.5.8.  I checked the System Profiler – no mention of an IR receiver; then I plugged the unit in and was gratified to see the IR receiver shown (I needed to close the System Profiler and reopen it to make the new device show up):

eMac before&after IMG_1605

I didn’t have Joystick and Gamepad Tester or iRed Lite installed on the eMac, so I had to content myself with testing the functions the remote normally performs on a Mac – opening and closing Front Row and turning the volume up and down.  Using the new modified remote, I confirmed that it would do this.

I then tried the same procedure on an old G5.  I can’t remember what OS it uses, but I think it’s either 10.5 or 10.6.  Once again, using the System Profiler, I verified that no internal IR receiver showed up at first, but when plugged in the new device was registered:

G5 before and after IMG_1608

The one thing that did appear first of all in the USB section was my iPazzPort.  I’ve described in a past post what this is – a very handy little device, no more than 4 or 5 inches tall, which duplicates the function of the keyboard and trackpad:


As can be seen, it connects via USB – not a problem, even on the G5, which only has one USB socket on the front, as I was able to plug it into the hub on the back of the new receiver and use the two devices together.

Once again, the remote worked exactly as intended, proving that IR functionality could be added to a Mac which originally had none.


I didn’t immediately reassemble the unit, as there were a couple more things I wanted to do with it.  First of all, as mentioned earlier, I wanted to include a method of making the lights flash when an infrared signal was received from the remote.  As described, this needed something to give a +V pulse when the signal came in.

I didn’t want to interfere with the Apple receiver module, so added a second IR receiver like this:


This device, an AX1838, has three leads: two for the power supply, with the third giving an output when it detects an IR input.  It wouldn’t be necessary to interpret the input – which is what the Apple module does – just give an output pulse on receipt of a signal.  Unfortunately, according to the data sheet, the output of the device goes low when IR input is detected, not high, which is what the ‘CD Player’ circuit requires.

I was under the impression that the low level output from the device would be sufficient, when inverted, to operate the switch in the CD Player, but this wasn’t the case.  In the end I looked around at circuits for simple infrared-operated switches, and used an adapted version of this one, using just three components, a BC588 transistor, a 22μF capacitor and a 100k resistor.

Apart from the existing electronics concerned with playing the samples and sequencing the lights, the electronics I added to the device looked like this:

IR Receiver Electrics Revised2

In fact, this is what I intended, but as I didn’t have a 100Ω resistor, I added a 470Ω instead.  I don’t know if this was too large a value, but I’ll find out when I come to use the wii later.

I didn’t bother with a piece of stripboard, I just wired everything up to the three legs of the transistor.  This addition to the circuit seemed to have the desired effect: the output of the transistor is normally kept low; an incoming IR signal is detected by the AX1838 and as the capacitor charges up the multiple signals are smoothed out into one.  The output of the transistor goes high and is boosted to a level sufficient to operate the CD Player switch and turn on the lights, giving a visual indication that an instruction has been received by the Apple IR receiver.

Stiff wires were attached to the two IR detectors, anchored inside the unit, so the detectors could be repositioned within the CD Player front window.


Finally, while on the infrared theme, I just had two more things to do  before reassembling the finished unit.

Firstly, I added two infrared LEDs to the front of the unit.  These had nothing to do with the receiver or the flashing lights: they’re a little closer together than the original, but they’re designed to duplicate the function of the wii ‘sensor bar’.

IR LEDs IMG_1609

I’ll be blogging about the wii system later, but the ‘sensor’ bar’ is a most inaptly named device, since it doesn’t ‘sense’ anything at all, but instead provides two points of infrared light which the wii remote controller – or ‘wiimote’ – uses to fix its position.  Being a little closer together than the Nintendo original isn’t a problem – the wiimote might just think it was further away from the sensor bar than it really was.  As I’m not proposing to use my wii controller for playing sports, I don’t anticipate a problem with this.  Further information will appear in my wii posts.

The new infrared device had one more secret, hidden in the carrying handle:

Candles 1 IMG_1612

There are many reports on the internet of wii users who have substituted candles for infrared LEDs when using their wiimote, so I thought I’d guard against battery failure in the unit by adding candle holders – the kind you buy for birthday cakes.  Believe it or not, this does work!


Front & Back

After reassembling the unit, and thinking again about the wii remote, I added an extra external item to the USB hub: a tiny Bluetooth dongle.  I found this in Poundland, for £1 (obviously!) and thought for that price it would be worth experimenting with.


August 2017
« Jun    

Enter your email address to follow this blog and receive notifications of new posts by email.