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:

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.:

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:

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):

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.

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:

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:

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

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:

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

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:

This 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:

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.

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.

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.

*

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:

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.

I bought mine here: http://www.powerbookmedic.com/MacBook-Pro-Infrared-board-p-18041.html at a cost of less than £10, including postage from the U.S. – a bargain!  [Edit: and apparently still available 5 years later!  The part is still shown for sale on that website in October 2018.  The current MacBook/MacBook Pro no longer has this IR receiver in it].

I got the idea for this part of the IR project from this article: http://photos.pottebaum.com/2009/IR.  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:

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.

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.

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.

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:

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:

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):

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:

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:

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’.

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:

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!

*

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.