Making music with the BBC Micro:bit, Pt 1

Recently I was lucky enough to be given a BBC Micro:bit as a present.

What is a Micro:bit? – It’s a micro-sized computer, half the size of a credit card, with a row of input and output pins along one edge, Bluetooth capability, a display consisting of 25 LEDs in a a 5×5 pattern, and able to be powered and programmed via USB.  For ultimate simplicity, it can be programmed directly from the website www.microbit.org, via WebUSB using the Chrome web browser.

When it was introduced, its purpose was to ‘encourage children to get actively involved in writing software for computers and building new things‘, rather than being merely consumers of media, and around a million of them were given away to schoolchildren by the BBC.

Once I found out that it was considered suitable for primary school children, I was greatly encouraged that I would be able to write programs for it; and, in fact, there is a particularly straightforward way of doing this (as well as Javascript and a version of the Python programming language): that is, the Microsoft MakeCode system, which involves arranging and sequencing interlocking ‘blocks’.  You still have to have the programmer’s mentality, but without having to remember the precise wording and syntax.

As shown in the pictures above, The Micro:bit has a row of about 20 pins on its bottom edge, which have different digital or analog functions, and 5 of them, in particular, are easily accessed with crocodile clips or 4mm banana plugs.  These are +3v (actually 3.3v) and Ground, and analog pins P0, P1 and P2.  As a matter of fact, these last 3 pins can be operated simply by touching them!  You may have to touch Ground with your other hand to make sure they work, though.

Two tactile switch buttons are also available for incorporation into simple programs, and there is a tactile ‘Reset’ button on the back, which causes the Micro:bit to reboot.

For more complex applications – which can even include operating external devices such as servos – a range of edge connectors is available, which can aid permanent connections or take advantage of the smaller input/output pins.

There seemed to be several different ways in which I could make use of the Micro:bit’s capabilities.  First of all, it can, with a speaker attached directly to one of its analogue pins (typically pin P0), make monophonic square-wave sounds of its own, including playing a number of tunes stored in its own memory; secondly, it can be programmed to output MIDI messages; and thirdly, it can utilise and output data from its onboard detectors, which include light and temperature sensing, a three-dimensional accelerometer, and a compass/magnetic sensor.

I decided to start by using the Micro:bit’s internal sound-generating capabilities.

For this, I decided to make a module into which the Micro:bit could be inserted, and which would contain a power supply, speaker and various input and output sockets – all the hardware needed for a free-standing Micro:bit-controlled musical instrument.  That is the subject of this post.

*

I began with an empty Stylophone case, left over from an earlier project.  I left the speaker in, and the two slide switches on the front left.

In order to incorporate the Micro:bit, I bought a ‘proto-board’ – an edge connector into which the Micro:bit slots at a right-angle, with a section of stripboard attached for ancillary circuits to be built on.  I chose the right-angle one because I needed the Micro:bit to be visible when in use, and to have access to the front and back of the Micro:bit where its sensors are located.

I used this board for a couple of things: a simple op-amp based buffer/voltage follower, and an audio output transformer to be used with an alternative to the speaker, a piezo element.

I also bought a sturdy protective cover for the Micro:bit to ensure that it suffered no damage while being plugged in and out.  This particular type of cover leaves the edge with the pins exposed for just this sort of application.

This picture shows the board in situ, kept in place with matchsticks used as locating pins.  The transformer and op amp are on the right-hand side; on the left are a 4-pin i.c. socket and capacitor left over from an experiment with an audio amplifier, which I decided not to keep.

The voltage follower is the simplest possible op-amp circuit:

I used one half of an NE5532, as that’s what I happened to have available, but any op-amp can perform this task of ensuring the output has a suitably low impedence level.

I’m not sure how useful the transformer is in this exact context, but I learned of its use with piezos from this Nic Collins video on YouTube and had bought a handful of them for this kind of use.

These pictures show how the piezo was fixed into the former Stylophone case, from the inside (L) and outside (R) in the place previously occupied by the tuning knob, which protruded from the bottom of the case.

The Micro:bit can also be powered through thie proto board: mine had a terminal block already installed in it for +3v and Ground; I powered the unit with a PP3 battery, as I am wont to do, so added a small adjustable voltage regulator before the terminal block, set at 3.3v.  This meant that the Micro:bit was receiving its correct voltage, but more volts (up to 9v) would be available for any additional circuitry required.  Two LEDs show whether the 9v and 3.3v parts of the circuit are powered up.

While working on the inputs and outputs, I added the following: an external 9v power in socket; send and return sockets so that external tone controls (such as these) could be used; sockets for an external speaker or headphones and an external piezo; a line out socket for easier mixing or recording; and two sockets connected to analog input pins P1 and P2.

Pin P1 was connected to a 10k lin potentiometer, one end of which was connected to 3.3v, the supply voltage for this part of the circuit, the other to 0v; in this way a continuously variable voltage could be available at pin P1 for control purposes: the Micro:bit would interpret this as a number between 0 and 1023.  If something was plugged into the P1 socket, the potentiometer would be disconnected and the external signal read by the pin instead.

Pin P2 was not connected, unless something was plugged into the P2 socket.  A second 10k lin potentiometer, set up exactly like the one for P1, was added, terminating in a 3.5mm mono plug.  This was available to be plugged into the socket and used for the same purpose if a program were to require it.

In use, I found I had problems with the circuit if the PP3 battery wasn’t new or, if rechargeable, well charged; fortunately, with the external socket it would be possible to use a mains adapter.

*

I set the mIcro:bit up to make some trial tones, but the sound was rather quiet, through both speakers and piezo, so I added a small amplifier.  This was a very economical (99p) module from a UK eBay seller, based on the PAM8403 chip.  This is a 3W stereo amplifier chip, but I would only be needing one of the channels.

It required a 5v supply, so I powered it from the 9v source and added a small 7805 5v regulator.

I put a 10k log volume control before the amplifier input, with the line out socket between the volume control and the amplifier input.  If a plug is inserted in the line out socket, the signal to the amplifier is cut.

After the amplifier there is a 3-way switch to choose between internal speaker, external speaker or headphones, and piezo element.

The following picture shows the majority of the interior at the end of phase 1 of construction (but before I added the two LEDs):

Features marked: 1 = the original Stylophone switch PCB, repurposed for 9v on/off and 3v on/off; 2 = volume control; 3 = the original Stylophone speaker; 4 = the 5v voltage regulator and amplifier PCB; 5 = the 3.3v voltage regulator PCB; and 6 = the 3-way audio output switch (internal speaker/external speaker or headphones/piezo element).

On the exterior I added three tactile switches to replace the two switches A and B on the front of the Micro:bit.  The first two switches simply duplicate the effect of the two switches on the Micro:bit; with the aid of a couple of diodes and a 4066 digital switch i.c., the third tactile duplicates the effect of pressing A and B at the same time, an action recognised by the Micro:bit.

I didn’t add any pull-up resistors on the outputs of the 4066 as the Micro:bit already has these internally.

*

After this I had a working module, so it was time for some programming!

*

I started with a couple of simple programs to make use of the light sensitivity and magnetometer functions.

While experimenting, I connected the Micro:bit to my Macbook with a USB cable, opened the Chrome web browser and wrote the programs using MakeCode on the microbit.org website.

The following picture shows the main features of the coding page:

1 = the simulator.  Most – but not always all – of the coding you write is automatically simulated here.  As you can see, the first instruction of my program, to display the number 1, is shown, as is the indication that I have chosen instructions which require the speaker to be attached;

2 = the button you press to load the program into your USB-connected Micro:bit.  WebUSB has not yet been implemented in most web browsers, which is why I use Chrome to do this.  Incidentally, if you’ve made any syntactical errors in the program, you will be told when you click this button;

3 = the area to name and save your program as a hex file.  The alternative way to program the Micro:bit is to open its window and drag and drop a hex file onto it;

4 = where you choose to program using the blocks, as I have done, or to write the code in Javascript;

5 = the area where the program is written.

*

As for my first program: the light control on the Micro:bit takes advantage of the fact that if the current to an LED is inverted, it becomes (slightly) sensitive to light.   The Micro:bit has an array of 25 LEDs on it, and it’s possible to use 9 of these together to record light levels on and around the device.

I found that the most useful way to use this feature was to set the Micro:bit up to sense the ambient light level, and then react to brighter lights being shone onto the LEDs, rather than the other way round (i.e. reacting to being shaded from the ambient light).

In this case, the reaction I programmed was to sound a note, then increase the pitch of that note as the light level increased.  Initially I just used the torch in my mobile phone, but I had already made 2 devices which could be used to control the Micro:bit in Light Reactive mode, the UFO and the Shuttlecraft.

As I said, the Micro:bit was programmed to start up in a waiting state and display the number ‘1’:

Then, when its Button ‘B’ was pressed – or the Button ‘B’ on the top of my module – it would run the part of the program related to the Light Reactive Instrument and display the number ‘3’:

The Micro:bit outputs a number between 0 and 255 to represent how bright the light level is.  0=dark and 255=bright.  The variable lightlevel in the program is set to be 20 times this number, i.e. between 0 and about 5,000.  The opening pitch chosen, 220Hz (the note A below middle C) and the range of values represented by lightlevel is designed to allow the Micro:bit to output pitches between 220Hz – a low to medium note – and about 5kHz – a very high note.

The variable lightambient is used to sample and remember the normal light level around the instrument on startup.  If the light level is no greater than this, the instrument makes no sound, the idea being that it should remain silent until a light is deliberately shone on it.

*

The second simple instrument I programmed was, in essence, the same thing, but reacting in this case to the presence of a magnet.

The Micro:bit measures magnetic force, as it says above, in microteslas (µT).  It turned out that the range of readings it gave did not need scaling or multiplying like the light level readings did, but produced a useful range of pitches without any changes.  So in this case the variable magforce was equal to the microtesla reading and gave rise to an output at the same Hz as the reading.

In this case, a magnet in the vicinity of the Micro:bit caused a pleasing arpeggiated effect, increasing in pitch the closer the magnet came to the Micro:bit, and decreasing as it was moved further away.

Again, the variable magambient was inserted in order to stop the instrument from sounding until the activating magnet was intentionally brought close to it.

I bought a neodymium (NdFeB) magnet especially for this purpose, as these are particularly powerful – up to 20 times as powerful as conventional ferrite (iron) magnets, in fact.

Neodymium magnets are graded from 28-52 according to their strength.  This one was an N52 (highest power) type.  It works very effectively, but has to be kept well away from any metal parts of the instrument – indeed metal parts of anything – as it will stick very easily and very strongly to them.  I wasn’t sure, but it even seemed to be affecting the speaker in some instances – a speaker, of couse, being driven by a magnet.

The only negative thing about this second instrument is that every time you reboot the Micro:bit, the compass/magnetometer has to be reset if you come to use it.  This is not, unfortunately, a simple matter, as you have to turn the Micro:bit every which way, with your progress shown by the LEDs lighting up one by one.  Only when all 25 of them are lit can you proceed.  This is obviously critical, if you genuinely want an accurate compass direction, but not so critical if all you want to do is make entertaining noises . . .

*

As I mentioned earlier, I had added two potentiometers connected to analog input pins P1 and P2.   I didn’t have an immediate use for these, but I thought it would be handy to have two variable inputs – for tuning or transposition, for example.

In preparation for Phase 2 of the instrument, I made use of the input to pin P1, and programmed it in the following way:

At the beginning of the program the potential input from pin 1, 0 – 1023, is divided into 21 equal sections, and scaled down to 0 – 20.  Each of the 21 divisions is numbered. ‘notenumber 0’, ‘notenumber’ 1′, ‘notenumber 2’, etc.

There are 20 notes on the former Stylophone keyboard, so there is one number for ‘off’, and one number for each note on the keyboard, ranging from 220Hz (‘Low A’) up to 659Hz (‘High E’).  When the potentiometer connected to pin 1 is turned fully anti-clockwise, the instrument is silent; as it is slowly turned clockwise, each note is stepped through in turn, until the highest note, ‘High E’ is reached.

This experiment proved that it should be possible to connect the keyboard to pin 1 and use the Micro:bit like a Stylophone.  This what I intend to do in Part 2 of this series.

Meanwhile, here are some recordings of these two instruments.  There are 8 short recordings, following this pattern: first the Light Reactive instrument through the internal speaker, external speaker, internal piezo element amd external piezo element; then the Magnet Reactive instrument through the same four media.

The recordings with the external piezo, glued to the bottom of the tin, are particularly interesting.  My experiments with piezos (beginning here), have so far only been in using them as microphonic elements, in particular as contact microphones, and as part of custom-made percussion instruments, and although the introductory article refers to their use as speakers, this is the first time I had actually used one that way.  Hopefully, there will be an opportunity to complete my survey of piezos by looking into this in more detail.

The tin, in fact, had been prepared for use as a kind of drum – and could easily function that way if attached to a suitable preamp.  It is quite large in size – 22cm (about 8.5″) in diameter and 14cm (about 5.5″) deep – and would make a very effective drum.  In this instance, using it as a speaker adds a noticeable reverb effect to the sound of the Micro:bit instrument.

 

 

The MIDI CPU Project – 3. Bass Pedals

After building the MIDI CPU box and programming it to accept input from keys, switches and potentiometers, it was necessary to build MIDI instruments to use its features.

As the MIDI CPU accepted input via a 25-way DIN socket, it would just be necessary to equip each instrument with such a socket and link it to the MIDI CPU with a suitable cable.

The first instrument I’d planned was a set of 13-note bass pedals, and the initial SysEx file with which I’d programmed the MIDI CPU was suitable for this application, with the first 13 control terminals, 0 – 12, configured as a complete octave from C0 to C1.

I got the pedals from a local seller on eBay who dismantled and repaired Hammond organs.

They were in excellent condition, and the switches on each of the pedals seemed to be still wired.  They looked like this:

and the actual connections were like this:

The two tabs on the front linked one side of all the switches together; when a pedal was pressed, this bus would be connected to the other side of that individual switch, the tab on the top.  This was perfect for this application, in which an individual switch connected to 0v would be interpreted by the MIDI CPU as a note command.

My main task, then, was to connect each of the 13 switches to a 25-way socket, in order to pass the switch presses to the MIDI CPU box.

In addition to this, I wanted to have Octave Up and Down and Hold commands available, so there would be 3 further connections to the 25-way socket.

Finally, I would have to construct a housing in which the pedal unit would sit.

*

There were no circuits as such involved in this project – it was just a case of wiring up the switches and connecting them to the socket.  At the same time I decided to add a couple of extra sockets that would enable the pedals to be used in a different way if necessary.

The additional sockets added were a 15-way socket, which would be compatible with the Superstylonanophone (another MIDI device, with  a built-in MIDI-USB interface):

and a 9-way socket compatible with the Apple IR remote:

*

I connected the switches to the sockets and, because the enclosure I had planned was designed to have another instrument on top of it (another MIDI foot controller, a Digikick Footar) I connected the Hold and Octave Up and Down connections to 1/4″ sockets so these switches could be external, rather than on the top of the pedals.  All the sockets were housed in a small panel, which would be attached to the rear of the enclosure.

*

After connecting the switches to the sockets, I found a D25 cable and attached the Bass pedal unit to the MIDI CPU box.  At the moment the MIDI CPU box is connected to a laptop via a Midisport 2×2 MIDI-USB interface – along with the Digikick Footar – and controls software instruments in Apple Logic.

I added 2 or 3 different bass instruments to the Logic set-up and tested the pedals.  All notes worked as they should.

With an external switch I tested the ‘HOLD’, ‘OCTAVE UP’ and ‘OCTAVE DOWN’ functions, which seemed to be working OK, so deemed it safe to screw down the top of the case in which the pedals were housed and fix the panel to the back of the case.

The MIDI CPU Project – 2. The Software

At the end of my previous post on the MIDI CPU Project, I had completed the wiring and construction of the MIDI CPU box – apart from solving the small problem of the box not being big enough for its contents, that is! – and it was time to test it to see if it worked.

The additional feature of the MIDI CPU is that it depends on being suitably programmed in order to function the way you want it to.  I don’t necessarily want to go into great detail about the exact programming I did, but I thought it would be useful to describe generally how it’s done, if only to reassure anyone thinking of embarking on such a project that it isn’t all that difficult, and shouldn’t be an aspect of using a device such as the MIDI CPU that would put you off.

First of all, the method of programming is via the MIDI connectors, so here’s what you need:

1. a MIDI/USB interface (mine is a very cheap M-Audio Midisport 2×2, quite old now, but works perfectly, drivers for mac and PC readily available on the internet, cost less than £10 on eBay).
2. 2 MIDI cables, for ‘in’ and ‘out’ (remember – which I don’t always do! – that the ‘out’ from the MIDI CPU goes to the ‘in’ on the MIDI/USB interface, and the ‘in’ from the MIDI CPU goes to the ‘out’ on the MIDI/USB interface!).
3. a USB A to B type cable if your MIDI/USB link is like the Midisport and doesn’t have one built in.
4.  a suitable program for sending and receiving SysEx messages.  The one to use for the mac is SysEx Librarian, and for PC, it’s SendSX.  These programs are free and come with documentation, so are pretty simple to set up and use.  Being a mac user, I also used a companion program of SysEx Librarian called MIDI Monitor, which would allow me to see what messages were being sent back and forth from my laptop to the MIDI CPU, and a small PureData patch of my own to see a little more detail of what was in the messages.

Not only does the MIDI CPU come with a fully detailed description of the board and ways of wiring it up, it also has a comprehensive guide to programming.  In addition, there is plenty more advice on the Forum, which I referred to in my previous post.  Even though, as I said, the forum is due to close at the end of 2017, I believe there are plans to preserve it in some way, which would be a very good thing, as it’s a mine of information which would be useful in all kinds of projects of this type.

Essentially, the programming is done in SysEx, and SysEx messages have the following format: a Header, consisting of SysEx header (F0), Manufacturer (e.g. 00 01 5D), Device ID (e.g. 04) and Command (e.g. 01), then some message information, and a footer (F7).  All numbers are in hexadecimal format (i.e. 01, 02, 03, 04, 05, 06, 07, 08, 09, 0A, 0B, 0C, 0D, 0E, 0F, 10, 11, 12, etc.) – which caught me out once or twice, but I soon got the hang of  it.

If you’re writing your own SysEx messages, you may find this chart useful, with all the MIDI numbers in it together with their hex equivalents:

*

The MIDI CPU programming guide gave a couple of examples of useful SysEx messages.  This one asks the MIDI CPU to send back a message with the current firmware version:

F0 00 01 5D 04 00 7D
00
F7

(it can be written on one line, but I’ve separated the sections so you can see the header, the message and the footer).

You can write your own SysEx messages using a text program like TextEdit, Wordpad, BBEdit, etc., but what SendSX and SysEx Librarian prefer is to use SysEx messages in a file format with the suffix ‘.syx’.

To help you with this the Highly Liquid site kindly provided an online tool for you – this is now on the Code and Copper site at http://support.codeandcopper.com/txt-to-syx/ – so all you have to is write your SysEx message in a text program, copy and paste it into the online tool, press ‘Convert!’, and you get your message back in .syx format, ready to send to the MIDI CPU.

So, first of all, this is what I did.  I wrote the firmware enquiry message F0 00 01 5D 04 00 7D 00 F7, as above, in a text file, which I was able to copy and paste into the online tool.  I got back a file which I downloaded and renamed something like ‘firmware_request.syx’, so I’d remember what it was for.

I added this to SysEx Librarian’s library, made sure to select the port on the Midisport 2×2 I was using, Port B, at the top of the SysEx Librarian window, and pressed ‘Send’.

This is what SysEx Librarian’s window looks like.  The arrow in the top left is the ‘Send’ button:

The list of files in SysEx format which have been added to the Library are shown in this box.  Highlighting one and clicking the ‘Show File’ button at the bottom opens the folder in which the file is stored; clicking ‘Contents’ enables you to see what’s in the file:

After pressing ‘Send’ in SysEx Librarian, I could see with MIDI Monitor that a message had been sent, and a message had been received.

You can double click on these messages to see what’s inside them.  The received message was very similar to the sent message, but with one extra piece of information.  It was all on one line, but I’ve separated the header, message and footer to show the new information in the middle:

F0 00 01 5D 04 7D
01
F7

The ’01’ meant that the current firmware version in the MIDI CPU I had bought back in 2010 was 1.1.  There haven’t been many updates since then but there was an important update between 1.1 and 1.2 which would affect my plans for octave up and down buttons, so I knew from this that I would first need to update the firmware – but the most important result of the message transfer was that I knew the device was working!

I’d downloaded the SysEx file from Highly Liquid for updating to firmware version 1.2a – and, in fact, it’s still available somewhere, as are later firmware versions – so the next thing was to send that message to the MIDI CPU.  This was a slightly more complex procedure, but the steps are laid out in the documentation.  I sent the (much longer) message, and when it was completed, sent the firmware enquiry message again.  This time it returned the information ’04’ in the middle, meaning firmware version 1.2a was now installed:

Following the guidance in the manual provided by Highly Liquid, I then wrote the most complex SysEx message, configuring each of the 24 control terminals.  Between the header line F0 00 01 5D 04 01 and the footer line F7, there had to be approximately 48 lines: one line for each terminal to tell it what to do on receipt of an ‘on’ message (a 0v pulse), and what to do on receipt of an ‘off’ message (a return to +v).  It was a little fewer than 48 as the terminals configured as potentiometers, modulation or pitch wheels just needed to be told to look out for a value beween 0 (0v) and 127 (+5v).

In this, my first scheme, the 24 terminals (0-23) were configured as follows:

0-12 were configured as on/off switches, producing a MIDI note on receipt of an ‘on’ message, and going silent on receipt of an ‘off’ message. (This scheme was created with the aim of producing a set of bass pedals.  These will operate the MIDI CPU via the 25-way connector, but the keypad buttons C, D, E, F, 9, A, O and B are also designed to produce notes for testing, tuning, etc.).

13 was configured as doing nothing.  (Its use will be seen in later schemes with more notes than a set of bass pedals).

14-16 were configured as latching on/off switches, for Hold, Sustenuto and Portamento.

17-19 were configured as momentary switches for octave down, octave restore and octave up.

20-21 were configured as potentiometers to control velocity and the amount of portamento.

22 is a ‘spare’ control, which can be routed by the ‘Select’ switch either to a spare latching switch (7 on the keypad), a spare momentary switch (8 on the keypad), a spare potentiometer, or the modulation wheel.  The programming will decide which of these is to be used; in this scheme I decided initially to configure it as a modulation wheel.  What exactly is modulated by this wheel always depends on the individual synth patch.

23 was configured as a pitch wheel control.

I originally wrote the text file like this, to remind myself  of some of the important details in it:

Afterwards, before I could use it, I had to remove all the comments on the right-hand side.  So then it looked like this:

which I copied and pasted into the online SysEx file creator.  I downloaded the .syx file, renamed it something like ‘Bass_Pedals.syx’, and sent it to the MIDI CPU.

The moment of truth came when I pressed some of the letter buttons on the lower keypad.  MIDI Monitor showed that the right notes were coming out:

(Note that a ‘Note off’ message is actually a ‘Note on’ message, but with a velocity of zero.  I had the velocity control turned down rather low, at 27 – it would normally be much higher than this).

I used my PureData patch, ‘MIDI Tester’, to check a bit more closely what was going on:

It’s possible to see from the set of figures on the left that the MIDI channel in use was set to 3 by the MIDI channel control knob.  The velocity is 0 as this is always shown when you let go of the key (or keypad button, in this case), but I was able to check as I pressed down that moving the velocity control altered the velocity all the way from 0 at the left-hand end through to 127 at the right hand end.

The figures in the middle show that the first latching switching, ‘Hold’, had been turned on.  127 is on, 0 is off.

There was something wrong with the octave buttons, though – according to MIDI Monitor, which showed me the note names, they were clearly raising and lowering the pitch by more than 12 semitones . . . it took me a while to work out that I had written ’12’ in the SysEx message, but the hexadecimal number ’12’ means 19, so the buttons were raising and lowering the pitch of the notes by an octave and a half, not just an octave.  I quickly rewrote the text message with ‘0C’ in place of 12, got a new .syx file online and resent it to the MIDI CPU, and all was well.

I tried using the internal MIDI/USB interface instead of the Midisport, but although it basically worked, it seemed, according to MIDI Monitor, to be outputting some spurious messages as well as the intended ones.  Consequently, I’m not sure if this can be reliably used – only further testing can confirm this.  It wouldn’t be much of a loss if it didn’t work – the commercial device the board came from was very cheap, just a couple of pounds, it didn’t take much effort to wire it into the box, and the Midisport isn’t currently being used for anything else.  It would just be more convenient if a board within the MIDI CPU box could be used, rather than an additional external one.

Just before I finished, and while the PureData MIDI Tester was still open, I connected the MIDI CPU box directly to the laptop with a USB cable and pressed all the buttons on the upper keypad.  These produced the numbers 1, 2, 3, 4, 5, 6, 7, 8 and 9, and the letters i, o and p, as intended, so that part of the project had worked, too.  I envisaged that some applications of the MIDI CPU would be connected with PureData patches, so having these 12 input symbols available, in addition to the MIDI data, could be useful.

There are also 3 sockets on the rear of the box connected to the Apple keyboard PCB, so an external device connected via the 25 way socket could also be connected one of these if the numbers and letters were also required in addition to the MIDI.

The next post in the series describes the construction of the bass pedals.

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 codeandcopper.com, 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 circuithub.com and github.com, 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 resistor, 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.

Sample Manipulation 4 – Databending

I started talking about manipulation of samples by describing The Black Widow, a PureData patch for controlling up to 4 samples using a flight simulator-type joystick control, and the Black Widow II, with improved features and an automatic mode.  I also described two other applications by Karlheinz Essl and Kevin Holland (Sineqube) which work similarly, manipulating 4 samples in real time.  The third post in the series described two applications which work in real time to manipulate a single, longer sample.

This post covers some non-real time methods of working on samples, often known as ‘Databending’.

The basic idea of databending is very simple: open a sound file with an application it’s not meant to be opened with, change the file in a semi-random way, then save it.  When you play it again as a sound file, it will sound different from the way it sounded originally.  Often quite a lot different.  Some good advice on how to do this can be found at http://www.intelligentmachinery.net/?page_id=29.

*

First of all, what sort of files does it work on?  I’d say you should always start by trying different formats of the same sound file – certainly an uncompressed format like aiff or wav, and a compressed format like mp3 or flac.  There can be a big difference in the results.  Once you’ve tried a particular technique on two or more formats, you might decide it generally works better on one of them, and then concentrate on that one; the next technique you try might work more effectively on another type.

*

Secondly, try some files with different musical content: one file with, say, fast percussive content, another with slow, sustained passages.  A particular technique might suit one style, but not another.

*

Next, what ‘other’ applications could you try?

Text applications are always good.  All files can be displayed as text, as you will have noticed if you’ve ever had occasion to read one – trying to open a pdf in Word by mistake, for example.  It generally looks like gobbledygook most of the the way through, although there’s occasionally a ‘header’ at the beginning with some readable stuff in it.

Sometimes, even the mere act of opening a sound file in a text program and immediately saving it can make significant changes to the way it sounds when you play it back again.  Notepad in Windows or Text Edit on a Mac can be used in this way.  Provided you save the file as ‘text’ and keep the extension (e.g. ‘.wav’ or ‘.mp3’) the same, you’ll be able to play it back.

The first example shows this.  The first extract is from the original sound file I used; the second extract is the file opened and saved in Notepad on a PC; the third extract is the file opened and saved in Wordpad.

Once you’ve got the file in a text editing application, however, there are many things you can do with it.  I’ve tried the following and got some interesting results: changing all lower case letters to uppercase; changing all zeroes to 1’s; changing 1’s to zeroes; cutting and pasting text from other places into the middle of the file; and swapping bits of the file around.  Occasionally you’ll end up with a file that won’t play at all, occasionally a file that sounds exactly the same as it did before – which is particularly disappointing – but usually you’ll have changed something about it in a hopefully interesting way.

Incidentally, I normally use ‘Save As . . .’ rather than ‘Save’, and give the new file a name which reminds me what I’ve done to it.  This has the double advantage of helping me to achieve the same effect again by working out what I did to the file, and ensuring that I don’t lose an original which I might need again – either in its original form, or as the source for more experimentation.

*

Some of these files that you end up with can be rather unstable and may sound different depending on which application you choose to play them back in.  So my next piece of advice would be to try some different applications to audition the results of your work – Windows Media Player, Audacity, VLC, Quicktime, and so on.

If you have a way of re-recording them as you play them, this would be good, as you can then save a stable file which will sound the same whenever you use it.

The second example illustrates this.  The first extract is the original sound file I used; the second extract is this file after processing in BBEdit Lite, played back using Videolan VLC; the third extract is exactly the same BBEdit Lite file played back using Apple Quicktime, producing a significantly different result.

Both files were re-recorded to preserve these differences permanently, as described above.  I use an excellent application called Wiretap Studio for this, but it isn’t freeware.  There are ways to do it without having to buy extra software – free applications like Soundflower (which I think only exists for Mac) or Jack will enable you to route the output of one application, which plays the sound file, to the input of another (like Audacity, for example), which records it.

*

Another, less obvious, way to ‘bend’ sound file data is to open the file in a picture editor like Photoshop, apply an effect and save the file.

This is slightly more complicated; I don’t know about other applications, but Photoshop won’t recognise sound files as pictures, so you have to do a couple of things to persuade the application to try opening it.

First of all, make sure to choose ‘All Documents’ (as opposed to ‘All Readable Documents’) from the ‘Enable’ list.  This makes all files, even sound files, potentially openable.

In my experience the ‘Format’ option was greyed out, but make sure it shows ‘Raw’ to enable a dialogue box like this to open up:

Clicking ‘OK’ should enable Photoshop to open the sound file, and give you a visual representation of it.  It’ll look something like this:

If it doesn’t open and you get the dialogue box at the top of the following picture – which happened to me a lot – reduce the numbers indicated until you get the dialogue box at the bottom, then it will open.

After that, you can apply some effects to the file, then save it.  As mentioned above, I would keep the suffix – usually .aif or .mp3 – the same, but change the file name to reflect the process it had been subjected to.  I had some success with Gaussian Blur, Noise and Despeckle, but any one of the many effects could do something to the sound.

The first example here shows the original sound file; this file with a Gaussian Blur filter applied; then this file with a Despeckle filter applied.

The second example shows an original .aif file with a Noise filter applied; and an original .mp3 file with a Noise filter applied, to show the different effect an identical filter may have on a sample which was identical in every way except the file format.

*

If you have problems opening a sound file saved by a graphics application such as Photoshop, the free Audacity can probably help.  Even if you get the dialogue box shown at the top of the following picture, you can still use ‘Import’/’Raw Data…’ to open the file, and then save it in the format of your choice.

Using the above methods you should be able to make some random, unpredictable and interesting changes to your sound files.

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

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 2: Modifications

In the first part of this series of posts, I described the Apple infrared (IR) Remote system and some software which allows you to use the IR signals for controlling apps on the Mac.

In this post I take a closer look at the Remote controller itself, and describe the way I modified mine.

I must say that I’m not familiar with the silver aluminium remote, although I have no reason to believe it’s substantially different on the inside from the original white remote.  This is the one I have experience of.

What’s good about the white remote is also what’s bad about it – it’s very tiny.  This is great if you just want to tuck it away somewhere and not have a bulky TV/DVD player-type remote to lug about, but not so good from the point of view of it easily being overlooked or mislaid.

So, one reason you might want to modify the remote is to make it larger and more suitable for the human hand.

Frankly, the most cunning solution to his problem is the one described here by Brad Moon.  I hope he won’t mind me using his picture:

Yes, what Brad has done is simply to glue his Apple remote to a hand-sized piece of wood.  Job done!  As he says in his blog post: ‘Too big to lose, too big to slip behind a cushion or slip into a pocket . . . The Apple TV remote hack has been in place for roughly a month.  In that time, the remote has been lost exactly zero times.’

This certainly takes care of the problem of the unit itself being rather small, but to address the problem of the size of the buttons themselves and their awkward layout, the unit has to be taken apart.  At the time of writing, you can still get hold of these white remotes on eBay for about £3, so if you want to try this, there’s no need to sacrifice the one that came with your Mac.

This is how it’s done:

The picture above shows the unit and the tool (or maybe one of the two tools) you need to open the remote unit.  This is a small Philips or crosshead screwdriver.

As well as being used in a moment for taking out screws, the first thing you can do with it is poke the small depression on the right-hand side of the base of the remote unit.  This releases the battery tray, which pops out on a spring:

Next, you have to undo a screw which is right down inside, next to the release button:

Undo the screw and take it out:

The next bit is the most difficult.  On the opposite side – the lower side in these pictures – is the spring which pushes the battery compartment out.  The spring is firmly attached to the bottom of a small piece of plastic, and you have somehow to grab this piece of plastic and pull it out, with the spring on the bottom of it.

The next picture shows what the spring and the plastic piece look like.  You might reach in and grab it with tweezers or narrow long-nosed pliers, but it’s right up against the edge of the case, and hard to get hold of:

If you look at the full-size version of the picture, you can see that the piece of plastic has tags on it, so I was able to poke the screwdriver under a tag and drag the plastic and spring out.

Underneath where the spring was is another small screw.  Unscrew this and take it out:

You can then pull the battery compartment out.  I did this with a pair of narrow pliers, gripping the white release button, which you can see in this photograph.

Then you can push out the remaining parts left inside the case.  I did that by inserting the screwdriver here:

The circuit board, with the springy battery connectors behind, slid out very easily:

You can carefully detach the end  piece from the circuit board, clicking it off the tabs which hold it in place over the end of the board and the IR LED:

This an exploded view of the remote, with all the parts visible:

Putting it back together, of course, is the reverse of this procedure.  The trickiest part is undoubtedly getting the spring and its plastic top back in.  This video by Andrew Williams, to which I’m greatly indebted: http://www.youtube.com/watch?v=vuP6CH770NM shows a remote being put back together, and explains the direction in which the tabs must face – front and back – for the plastic piece to go back in the correct position.

*

I wasn’t interested in putting it back together again, so I looked more closely at the circuit board:

You can see in the top part of the picture the infra-red LED and the 6 buttons.  You can also see 4 screws which attach the circuit board the the plastic fitting.

The first thing to do was take off the six silver ‘domes’ which make the contacts when the buttons are pressed, and see what connections they made.  These are often, in my experience, attached together to a transparent sticky sheet which peels off, and so it was in this case.

As you can see from this photograph – taken after I’d removed the four small screws holding the PCB to the plastic fitting – each button makes a contact between an outer ring and a centre spot.  All the outer rings were connected together, to what looked like +V, while the six centre spots were separate.  What I wanted to do was transplant the board into a larger unit, so I needed to solder seven wires to the board, and connect them to buttons in the new unit.

The larger unit I’d chosen was this one:

This is a vtech Tiny Touch Phone: it’s powered by two AA batteries – 3v, same as the Apple Remote; has 12 buttons – exactly twice as many as the Remote, which could be handy for dissociating short, long or double presses; and has flashing lights – which is always good.  It also makes sounds, and under normal circumstances I would be looking to ‘bend’ these, but in this instance making noises wasn’t what the project was all about, so I decided I’d remove the sounds completely by taking out the speaker.

The Phone also has a hollow plastic ‘antenna’, which was perfectly placed for installing the IR LED.

This is what it looked like inside.  In  this picture the large mechanical unit, which looks like the film sprockets in an old 35mm film camera is obscuring the speaker housing.  With the speaker removed there looked as though there’d be plenty of room for the small Apple Remote PCB there.  The wires for the LED could easily pass from there up into the antenna.

The general idea would be to rewire the button connections on the Apple Remote PCB to the Tiny Touch Phone buttons.  The Phone buttons (visible in the first picture above) are, however, hollow, and make connections with a membrane, rather like  QWERTY keyboard, via their edges .

I wanted to leave the membrane intact, to operate the flashing lights, so I decided to add small tactile switches with longish 3.5mm actuators which would be glued in the hollows with the actuators sticking out through a hole in the top of the Tiny Touch buttons.  It was these switches which would actually operate the IR remote.

Gluing these in without gluing them together so they wouldn’t function proved difficult.  Letting superglue anywhere near them – even the gel type which I usually use – could prove fatal, as it has a habit of running everywhere.  In the end I used epoxy, which is stickier and less runny, and tiny pieces of tissue paper soaked in epoxy to keep the switches in place.  The moon and star buttons aren’t hollow, so I stuck tactile switches with short 1mm actuators to the top of them, on the outside, with wires running in through a small hole.

In the end I only connected up the star: it would have been difficult to make the hole in exactly the right place in the moon and route the wires inside without disturbing the membrane too much.  The star operates the ‘Menu’ button, which is less important than the others and doesn’t require more buttons to distinguish types of presses.

In the event, all but one of the tactile switches worked after this treatment, which was OK, as there were two new buttons for each button on the original remote, so all functions would still be available.

To modify the new unit, I first removed the speaker and replaced it with a resistor (two 22Ω resistors in parallel, actually, as I had these lying about.  I didn’t have any 8Ω resistors to match the speaker, but 11Ω, I reasoned, was close enough).

This created enough space in the top of the unit for the small Apple remote PCB.

I reinstalled the buttons in their places and connected the tactile switches together.  One side of each switch was connected to +3v, the other sides of the switches were connected together in pairs (except the moon, as explained above).  This made 7 extra wires running down to the bottom of the unit.  The presence of the wires might have an effect on the operation of the TouchPhone’s original buttons, but this wasn’t important as their only function now was to light up LEDs when the remote was operated, a feature which Apple neglected to provide in the original.

As can be  seen in the above picture, there was just about enough room for a 9-way D socket in the base of the unit.  I put this in partly because it would allow for external operation of the 6 remote buttons – perhaps by means of a footswitch – and partly because it provided a handy link point between the tactile switches and the Apple remote PCB.

To attach the remote PCB, wires were connected to the centres of the 6 switch points, and one of the outer rings, which were all connected together on the board.  3v and 0v power cables were connected to the springy metal pieces which formerly connected to the coin-battery in the original remote housing.  These connectors were shortened in order to fit the PCB neatly in the space where the speaker had been.

At the same time I detached the infrared LED and put it on the end of a longer lead, so it would reach to the front of the unit when in operation.

At this point everything was connected up, although not back in place, so I made a quick check, using iChat and the laptop camera in the way described before.  I pressed all the buttons in turn, pointed the unit at the camera, and watched for the infrared LED to come on.

When I was satisfied that it did so, I replaced the membrane and the TouchPhone PCB, as this would make pressing and testing the buttons a great deal easier.

*

For the next step I needed a way of thoroughly testing if the remote worked as intended.  I did this by creating a Tester program, using iRedLite.

It takes quite a few steps to create a ‘Layer’ – a set of instructions for each remote button – in iRedLite, but this is how I created a ‘Remote Tester’.

The ‘Menu’ button has special functions in iRedLite, but the other 5 buttons respond to short presses, long presses and double presses, so 15 separate instructions would be required.  What I decided to do was use Text Edit, and simply have it print the numbers 1 – 15, according to which remote button was activated.

Step 1 was to open iRedLite.  You can set it up in various ways in the preferences, but I have it set so it just opens an icon in the menu bar:

The first step is to select the Editor from the drop-down menu:

This brings up the Editor screen.  The top half of the window is a copy of what iRedLite calls the OnScreen Display (OSD).  The bottom half allows you to edit Layers and Buttons, and select the actions the buttons perform.  I began by creating a new Layer for my Text Edit actions:

Then I entered the details of this Layer:

I typed a name for my Layer into the ‘Title’ box, and then made choices about what would happen when the Layer was selected.  I chose not to have the Layer activated when I switched to Text Edit, in case I wanted to type some text while using iRedLite with another application; but I did choose to have Text Edit activated when I switched to this Layer, because the actions all required text to be typed in it.  I have several remotes, so to be certain which remote was being tested, I set it to respond only to a particular one: in this case, the one with the ID No. 214.

Having finished creating the Layer, I clicked on the small arrow in the bottom right-hand corner of the Editor window.  I believe they call this the ‘Expert’ button, but it’s simply for accessing the section where actions are created and organised.

Clicking this button opens the right-hand side of the Editor.  In here, if you look in the ‘Application’ column and can’t find the application you intend to use the remote with, click the ‘+’ button at the bottom of the column to add it to the list:

Type the application name in the box which appears.  The program will be recognised if its name is written the same as it would appear if you moved your mouse over it in the Dock.  Text Edit is actually written ‘TextEdit’, so that’s what I typed in the box:

Next you have to create a ‘Group’ – not for any special reason, I don’t think: it just works that way.  If you create a lot of actions for one particular application, this allows you to put different types of actions together, i.e. Keystrokes in one Group, AppleScripts in another, and so on.

I just wanted keystrokes, so I created a group called ‘Keys’.  Group names are your personal choice.  Once again, I clicked the ‘+’ sign under the ‘Groups’ column, and typed ‘Keys’ in the box which appeared.

Then it was time to create some actions.  Each action is entered individually, so I had to click on the ‘+’ sign at the bottom of the ‘Actions’ column 15 times, name the actions in the boxes which appeared, and specify what was to be done.

They were all more or less the same, and this is an example:

Click the ‘+’ sign; name the action – again, this is entirely your choice: I just called them ‘1’ to ’15’; type the name of the application, or choose it if it appears in the drop-down list; check the box if you need the application to come to the front – which I did, because I wanted to read what it had printed; and type in what keystroke or keystrokes should be made.

Allocating the actions to the buttons is just a matter of dragging and dropping the action onto the appropriate button, and clicking ‘Assign Action’:

The button will be given the name of the action – in this case ‘1’, which is the name I had given to the first action, which was to print the number 1.

You can rename the button, and I did, calling it ‘1/2’.  This is the reason why:

iRedLite shows the pattern of buttons in the way that it does to indicate that the button nearest the centre performs the short press action (which they call ‘Action on click’), while the button on the outside performs the double press action.  In reality, of course, these actions are performed by pressing exactly the same button on the remote, but it makes it clearer to see which number of presses produces which action.

So the ‘short press’ and the ‘double press’ are specified, but the ‘long press’ action (which they call ‘Action when holding’) remains to be allocated.

I decided to add the long press action to the instructions for the inner buttons, so in the example below I selected the appropriate inner button (Action 4, the ‘+’ button on the remote) and the ‘Advanced’ tab.  This allowed me to drag and drop the action I wanted to be performed as the long press action, printing the number ‘5’.

I added a long press action to buttons 1 (the ‘Left’ button on the remote), 4 (the ‘+’ button), 7 (‘Right’), 10 (‘-‘) and 13 (the centre button) and renamed the buttons in iRedLite accordingly (‘1/2’, with ‘3’ being the double press action for that button on the remote; ‘4/5’, with ‘6’ as the double press, and so on).

When I’d finished, the set-up looked like this:

Note the button in the top right-hand corner,  marked ’15’.  There are 12 more places in the grey area of the button window where you can drag and drop actions, 6 on the left and 6 on the right.  If you drag and drop an action somewhere in the grey space, a new button will be created there.  This might come in handy if you had a modified control with differently positioned buttons.  In this case, I used one of the spare places for the double press action associated with the centre button.

Removing buttons, should this be necessary, is one of the functions on the drop-down menu where I chose ‘New Layer’ at the beginning.

I opened Text Edit and pressed all the buttons in order, single press first, then long press, then double press, hoping to see the numbers 1 to 15 displayed.  This what I saw:

The numbers were all printed out in order, so the combinations of short press, long press and double press all worked as predicted – but the long presses produced a continuous stream of outputs, even though I tried to take my finger off the button as quickly as possible.  The exception was the Centre button, which produced a single output of the number ’14’, no matter how long I held the button down.

This behaviour might not be what you require if, instead of printing numbers, you want a single specific action to be performed.  You might find the action repeated many times unless you’re able to take other steps to avoid this.

However, for testing purposes, this was fine, and I had established that the remote should, with iRedLite, be able to distinguish between 15 separate actions, despite only having 6 buttons.

*

The final stage of the project was to try out the new Tiny Touch Apple IR Remote to see if it would function correctly, using the iRedLite TextEdit Tester.

I quickly opened Joystick and Gamepad Tester to check the ID number of the new remote, which was 211.  I then opened iRedLite, went to the correct Layer for my Tester, and changed the remote number to which it would respond from 214 – the remote I had originally use to create the Layer – to 211.

The TouchPhone has a Power switch, but in fact the IR Remote worked even when it was in the ‘off’ position; in the ‘on’ position it worked with added lights.  As before, I pressed each button in turn with a short press, a long press and a double press, checking to see that the correct numbers were printed in Text Edit.

They were, so now it was safe to put the unit back together.  I glued the IR LED into the ‘antenna’:

fixed the 9-way socket in place:

and  wrote the ID number on the back.  Now I had the world’s most colourful Apple IR remote!  It could have been the world’s noisiest, had I not removed the speaker, but I felt this would be gilding the lily – and would probably have been a distraction, given that I had conceived of the remote as being part of a sound-modifying system, not a sound-producing system.

I was a little upset as, just as I was putting it back together, I broke the plastic link behind the ‘telephone’ button that mechanically ‘winds the film’ and changes the picture on the screen.  However, this only deprived me of more ways of turning LEDs on, and didn’t in any way affect the IR  controls, so ultimately I was satisfied with my achievement.  I didn’t want to spend more time on it at this stage as I wanted to move onto the next part of the IR project.

For this, see Part 3: Additions.

 

[Edit: I’ve since managed to get hold of another Tiny Touch Phone and replace the broken film winder, although I haven’t yet had time to change the tactile switch that got glued together].

Fun with the Apple IR Remote, Part 1: Making it work

This article, by and large, is for Mac owners, as it describes the Apple infra-red (IR) remote control system that’s been used on and off in Apple machines for about 7 or 8 years.  There is an article here which describes the remote being used on a Windows PC, and here on a Mac running Windows, but I imagine these are not common usages for this system.

In fact, I don’t believe the Apple IR system is well known at all amongst Mac users, and I hope this study will show that it can be more useful to music makers than was previously thought.

*

From about 2005, Apple began adding an infra-red remote capability to their machines, which came with an attractive little remote control like this:

It’s not clear from the picture, but if you haven’t seen one, it’s quite tiny – about 8cm by 3cm.  I’ll be returning to that point in Part 2.

The IR system began with the iMac G5 and quickly spread to the white Macbook, Macbook Pro and Mac Mini.  A slightly larger silver aluminium version of the remote came out in 2009, but also in that year Macbooks stopped being made with IR capability.  It remained as an option on the Macbook Pro, but the remote itself wasn’t being bundled with the laptop.

This is the silver remote.  Note that the ‘Play’ button has been moved from inside the ‘+’, ‘-‘, ‘Left’ and ‘Right’ buttons, and placed separately, to the right of the ‘Menu’ button.

At the time of writing, the Mac Pro and Mac Mini seem to have built-in IR capability.  It’s difficult to keep track of what does what, however, as newer models of computer seem to be dropping this feature and users are being encouraged to use an iPhone app which does a similar job; but if it has one of these on the front:

then it’s got IR built in.  The one area where the control seems to have remained popular is with the Apple TV/Home Theatre users.  There was an application called Front Row, which used the remote to control films and music, but I don’t believe this has been in use since OS 10.7.

All of this is a shame, as the ability to control your computer wirelessly can often come in handy, and several companies produce excellent software which greatly expands the ability of the Apple remote to control pretty well any application in any way you want.

Of course, if you have a Mac, then you very likely have the luxury of Bluetooth as well, and I have blogged, or will be blogging, about various uses of Bluetooth.  However, it could be that your Bluetooth system is fully occupied with, say, your wii controller, and this extra way of passing information to your computer becomes a vital necessity.

Although most of the following is based on my experience with my MacBook, which has IR built in, I’ll be speaking about things one might do to add IR capability to a non-IR Mac.

*

First of all, then, the controller and getting it to work:

There are three things to do to make sure your IR remote is potentially going to work.  The first is to ensure that the battery is OK; the second is to confirm that the infra-red LED is lighting up; and the third is to make sure the computer’s IR capability is turned on.

The remotes are powered by a CR2032 coin battery.  Apple designers, as we know, live in a world where bent paperclips are always to hand, so with the white remote – like the method of ejecting stuck CDs – there’s an indentation in the bottom of the case which can be poked with a bent paperclip to eject the battery tray.  In this case it isn’t inside a small hole, so a pen, pencil, or a 3.5mm headphone plug will also work perfectly well.

As illustrated, the silver remote has a different method: a battery compartment which is opened by twisting a small coin in it.

As for checking that the remote is functioning, the essential problem with this is that the light it gives off is infra-red, and therefore you can’t actually see it.

Fortunately, though, cameras can!  So if you have a laptop with a camera at the top here:

all you have to do it open something like iChat, go to Video > Video Preview and film yourself pointing the remote at the camera and pressing buttons.  If you can see a light like this:

then the unit is working.

Finally, you just have to make sure the IR capability isn’t turned off.  Do this by opening System Preferences > Security, and look for this:

Make sure the box isn’t checked and it says ‘The computer will work with any available remote’.

While on this subject, it’s worth noting that this might not be the situation you want.  If you’re in an environment where there are several remotes in use, you might want  your machine to respond only to yours.  Under these circumstances, the ability to ‘pair’ your remote and computer might be very useful.  Clicking this button:

will enable you to do that (provided you’re logged in as an Administrator).

When you click it, it tells you how to do the pairing:

Rather like a wii controller, you point the remote at the computer (but in this case it must be from just 3 or 4 inches away) and press the ‘Menu’ and ‘Next’ (‘Right’) button at the same time.  After a few moments (maybe 5 seconds), the following large icon will appear on the screen, with the ‘link’ sign flashing:

The remote and the computer are now paired; the ‘Pair’ button changes to an ‘Unpair’ button, and the text now says ‘This computer will work with only the paired remote’.

The process of unpairing them is simply a case of clicking that button:

Using the remote itself, you can unpair it by pressing ‘Menu and ‘Left’ at the same time, for about 5 seconds.

According to Apple, the remote works up to 9 meters (30 feet) from the receiver.  Unlike Bluetooth, of course, we’re talking about light here, so there can’t be anything in between the remote and the receiver that would block the signal – although you might be lucky and able to bounce the signal off a wall on on its way to the receiver.

*

So, now the remote is working, what can you do?

The answer is, not a lot.  You can use Front Row to watch films or listen to music, unless you have a modern operating system, 10.7 or later; you can remotely control iTunes, or you can make your computer go to sleep and wake up.  Not very practical for making music, which is, after all, what this blog is about.

[Edit: since writing the above, I’ve installed OS 10.6 and a newer version of the program VLC, from Videolan, an excellent free audio, but predominantly video, file player.  Some of VLC’s functions can be controlled with the Apple Remote, which is handy.  I don’t know if this can be done with earlier versions of Mac OS].

So, an important part of making the remote work would be to find some suitable software to interpret the input.

The first thing I looked into when I got my remote out of the cupboard and got it working was whether it would work with PureData (Pd).  Many types of HID (Human Interface Device) will act as musical instruments or effects devices – as I have described in the blog before – and so can the Apple IR Remote, although only to a limited extent.

I used a generic ‘HID Tester’ patch which I had created for investigating different devices, and determined first of all that the IR system was recognised by Pd – in this instance as Device 0:

I activated Device 0 and pressed all the buttons in turn, but this is all I got:

So unfortunately Pd was only able to recognise two of the buttons on the IR Remote, ‘+’ and ‘-‘.

*

This was of limited value, so I needed to see if there was any software which could expand the usefulness of the device.

Luckily, there was.  There are several programs, in fact, which can greatly extend the range of control  the Remote can give you.

Andreas Hegenberg’s BetterTouch Tool (BTT) has a section for the Apple Remote, although is generally more aimed at the Magic Mouse and trackpad

Nowadays, in fact, Andreas seems to be concentrating on the amazing Leap Motion Controller, which is going to deserve its own blog page one of these days.

I wasn’t able to test out the BetterTouch Tool: it’s free, so there’d be no problem for you downloading it (from here, for example) and trying it out, but only supports OS 10.7.  There might be a legacy version still available for 10.6, but I couldn’t find one for 10.5, which I’m still using.

I did find a screencap, though, which shows that button presses are known as ‘Gestures’.  This is an example of the window in which button presses are assigned different actions:

*

Mira is a dedicated Apple Remote app which, when installed, is controlled from System Preferences.  The opening view shows the remote buttons in the centre: you click on each button to assign a function to it, which may be a keystroke, system action, or instruction open a program (including AppleScripts).

Mira supports short presses and long presses, effectively doubling the number of actions available from the 6 buttons, and provides a number of combinations of short press/long press combinations.  A comprehensive Help menu is available by clicking the ‘?’ button in the bottom right-hand corner of the Mira window.

Mira is available from Twisted Melon in versions for OS 10.4+ and 10.5+.  Also available, for the deprived Mac with no IR receiver, they offer the Manta TR1 plug-in USB IR receiver.  At the time of writing Mira costs $15.95 (Canadian) for single licence and $29.99 for 3 licences; the Manta TR1 costs $19.99; and a bundle of 1 Mira licence and a Manta costs $29.99.

*

Remote Buddy looked particularly promising as it also offered control of wide array of remotes, not just the Apple remote, but other makes from the likes of Griffin and Sony, iPhone and iPod Touch, and even Nintendo wiimotes.  OS 10.4.6 and above are supported.

Remote Buddy also installed its driver, Candelair (also available as a free stand-alone).

Configuring the remote’s buttons consists of specifying an application – although ‘Default’ and ‘Virtual Remote’ options are available – and defining a group of actions called ‘behaviours’.

There are appropriate suggestions for each application, and you can create your own Custom actions.  Like Mira, Remote Buddy supports short and long button presses and allows the same kinds of action choices; Help is available from the Remote Buddy menu.  It costs €19.99.

As a matter of fact, once I had installed Remote Buddy/Candelair, the following entries showed up in PureData:

Opening these device numbers, I was able to see two more actions displayed:

However, I wasn’t able to use these with the [Route] object, as one normally would.

Even if you don’t use Remote Buddy, I’d recommend installing Candelair, as I’ve encountered a number of instances like this where the presence of this alternative driver allows you to do things that can’t be done otherwise.  It can be controlled – even uninstalled – in System Preferences:

*

Undoubtedly, the be-all-and-end-all of infrared applications is iRed.  Designed to work with the iTrans infrared module – which transmits as well as receives  – this system can, in a nutshell, allow you to control your computer with any infrared control and allow your computer to control any device with an infrared receiver.

Possibly slightly extravagant for present purposes – and it doesn’t work with the standard Apple IR receiver, of course (which doesn’t transmit).  However, iRed Lite is much more the sort of thing I’m considering here.

In fact, for several reasons, this is the one I chose to use, partly because it’s free, partly because I liked the flexible onscreen display window, partly because it recognises short presses, long presses and double presses.

When opened, all that appears is an icon in the menu bar.  Clicking on this icon brings up a choice of actions, including opening the Onscreen Display or the Editor window.  This view of the Editor windows shows some of the important features:

1.  This panel replicates the Onscreen Display.  The buttons are laid out here in the same format as the buttons on the remote.  The ‘extra’ button at the end of each row is for the ‘double-click’ action.

2.  This section, when the ‘Button’ tab is selected, allows for changing the style of the buttons.

3.  In this section the action performed by the button can be changed.

4.  This drop-down menu, as the name suggests, allows the settings for different Layers to be displayed.  A Layer is a collection of actions, usually applying to the same application.  When a Layer is active, the actions described in that layer are the ones which will be performed when the remote buttons are pressed.

5.  This drop-down menu gives access to more functions, such as remove selected button, create or remove a Layer and open the Character Palette for access to special characters and symbols.

6.  Clicking this arrow reveals or hides the sections on the right-hand side of  the picture in which more complex actions can be specified.

7.  Clicking on the ‘Add Action’ button allows actions to be specified which replicate keystrokes or mouse movements; a third possibility is to run an AppleScript.

8.  The special action is chosen in this area.  The picture shows a simple AppleScript to initiate an iTunes function.

Actions can be dragged and dropped onto the buttons in the panel on the left and different patterns of buttons can be created for ease of understanding or to match modified remotes.

*

Modified remotes is the subject of Part 2 of this series of posts, but before we leave the topic of software, I must just mention a small command-line app which runs from the Terminal.  I haven’t yet worked out if this is potentially useful or not yet, but it’s called iremoted and ‘listens for button-press events and prints the identifier (the HID element cookie, to be precise) of the button in question’.

A description of the program can be found here, together with the source code in a file called iremoted.c.  Its GitHub entry is here.  I compiled it from the Terminal by typing the recommended instruction ‘gcc -o iremoted iremoted.c -framework IOKit -framework Carbon’.

When I ran it, sure enough it showed me the HID element of the code sent by each button press, like this:

It’s interesting that ‘+’ and ‘-‘ were the only two buttons that showed an entry when pressed before another entry when released.  Whether this has anything to do with the fact that they were the only two buttons to show up in PureData, I don’t know.

The above isn’t the only information passed via the infra-red link when a button is pressed.  I’ve read numerous articles on the subject which, frankly, I don’t understand – they either don’t say the same thing, or they say the same thing in a different way . . . suffice it to say that 4 different pieces of information are transmitted each time a button is pressed, according to the NEC Infrared Transmission protocol, which Apple remotes use (in a slightly non-standard way): the first two are purely Apple’s own ID, the third is the instruction code, as above, and the fourth is the remote’s individual ID.

*

The individual remote ID is the final thing I want to deal with in this post – which I ought to do, as I glossed over it rather surreptitiously when talking about ‘pairing’ earlier on.

When you pair a remote with your computer, you’re not pairing just any remote in the vicinity: you’re pairing a particular remote; and the way the computer knows which particular remote is being paired is because of its individual ID, which is a number from 0 to 255.  This isn’t fixed: it can be changed, although not to a number of your choice.

The advantage of pairing a remote is that you can – as  in my earlier example – ensure, in an environment in which several remotes might be in use, that your computer responds only to your remote.  If by some chance you find yourself in a situation in which there are two remotes with the same number, you can change the number and re-pair it.  To change the number, all you do is press ‘Menu’ and ‘Play’ (the centre button) at the same time, and the number will increment.

I have read that the remote will attempt to pair when you do this, so if you don’t want to pair at the same time, do this outside the distance from the computer (3 or 4 inches) which is required for pairing to work.

So, pairing can be useful.  But what might be even more useful is not to pair a remote with your computer, but to allow the computer to recognise individual remotes by their IDs and have them do different things.  Programs like Remote Buddy do this, as the following screen shots show:

Checking the box ‘Enable support for multiple remotes’ – indicated by the arrow at the top – brings up the list beneath.

In the right-hand column, remotes are distinguished by their ID number, not paired, but associated with different ‘behaviour’ groups.

*

In the iRed Lite Editor window, clicking on the ‘Layer’ tab brings up a number of parameters that can be altered, one of which is the ID of the remote which will control this layer.  The actions described will not be performed by another remote with a different ID.

This raises the possibility of using a number of separate remotes for entirely separate purposes, using modified remotes with multiple ‘personalities’, or teaching a universal remote with a learning capability to mimic remotes with different IDs.  This article: http://funwithcomputers.wordpress.com/2008/03/01/using-the-harmony-880-remote-with-your-macs-built-in-ir-port/ describes a project to teach a Logitech Harmony 880 to imitate 8 Apple remotes via Remote Buddy.  In this way 48 different buttons were created (could have been 96, but long presses were not configured) and all manner of things could be controlled in a home theatre set-up.

At some point, you might want to check the ID Number of your remote.  If you’ve only got one, chances are its number will pop up everywhere.  If you have more than one, someone else uses one in the vicinity of your computer, or you haven’t really used it before, here are two ways to find out what it is.

The first thing to say is that isn’t always quite as easy as it might be, as only ID number changes seem to be registered.  If you have more than one remote, it’s less of a problem – every time you use a different remote there’s a number change; if you have only remote, the following needs to be done the first time you use your remote after booting up the computer:

Open iRedLite and select ‘Preferences’ from its drop-down menu, and then ‘Apple Remote IDs’.  It will probably show ‘0’ as the current ID number.  Press a button on your remote, and it will display the remote’s ID number, as below.  If you have more than one remote, you can check the numbers here at any time, as the change from one ID number to another will be registered (although once I was fairly sure I wouldn’t be incrementing the IDs any more I wrote the numbers on the back of each remote!)

Another useful program you could use for this purpose is Joystick and Gamepad Tester.  I’ve blogged about this at greater length elsewhere, but since the Apple infrared receiver is part of the USB system, it will be picked up by this program, which is designed to identify buttons and other controls on USB devices (such as joysticks and gamepads).

In my experience, this only worked after I’d installed Candelair, as recommended above.

I open Joystick and Gamepad Tester and click ‘Ok’:

I can then choose from a drop-down list.  Instead of choosing ‘IR Receiver’, which normally shows nothing, I choose ‘IOSPIRIT IR Receiver Emulation’:

A list of buttons and functions appears, the last being the Remote ID number.  Pressing a button on the remote shows the current ID number in the ‘Now’ column.  Any button will do, as the device’s ID number is transmitted as part of every message.  Don’t take any notice of the ‘Min’ and ‘Max’ columns, as they just show other device ID numbers that may have been used before.

*

Some of the above could only legitimately be described as ‘fun’ by those of us with a rather esoteric definition of the word.  In Part 2 I’ll progress closer to using the IR remote for modification and music-making purposes.

UCreate Music, Part 3 – the software

In Part 2 of this series I dealt with the UCreate hardware.  Now we come to the software.

The issue of the UCreate software is a contentious one, as the software to allow users to swap around the sounds and effects in their UCreate could only be used by connecting to the UCreate website; but after a couple of years Mattel took down the website and it was no longer possible to do this.

There is a long and very interesting discussion on the subject – from which many of the ideas below originate – at http://nomeist.com/ucreate-music/199.

The way it originally worked was this: the first time you plugged in your UCreate it automatically connected to the website, and downloaded a program, which – on the Mac at least, looked like this:

This confirmed that your device was connected, and gave you the Firmware version (I think version 9 was the last one) and the individual number of your device.  Each time you plugged in your UCreate and opened the program, this is what you would see.  As the instruction at the top suggests, if you rested your cursor on various parts of the picture, you were given an explanation of the function of the various controls, for example:

However, more importantly, if you clicked the tab on the right, ‘Music portal’, you were able to log onto the website:

As you can’t do this now, I’ve had to rely on an old screenshot from a Windows PC.  I don’t have any screenshots of what you would find when you got there, and even the Wayback Machine only shows a background image, presumably because the site operated via a Flash app; but you were able to download some alternative sounds directly to the UCreate device, and move the effects around.  What users anticipated was, as time went on, more sounds and new effects would appear, perhaps even a community of users sharing their own creations.

Instead, the site was closed, and you now see only this:

Not only was access to the existing sounds and effects withdrawn, but, worse still, also the means of loading them into the UCreate devices; and everyone who used one was stuck with whatever sounds they currently had installed.

For most, this was the original sounds the UCreate came with, or one of the extra packs that had been available on the website.  I had the extra packs, but couldn’t use them because there was no separate software available to install them on the machine.

Some astute users had observed that the downloading process occurred in two parts: first the sounds were downloaded from the website to the host computer; then they were transferred from the computer to the UCreate.  The time-lag between these two operations allowed their own sound files, suitably renamed to match those being downloaded, to be quickly substituted between downloading and transferring.  The timing of this was crucial, and could be a bit hit-and-miss, so one proficient user, ‘scragz’, even wrote a routine for Macs that automated the task (https://github.com/scragz/ucreate-loader); but if these were still in the machine when the site was taken down, these were the sounds you were left with.

The following article describes how samples can now be loaded into the UCreate, and furthermore how you can create and use your own samples in the device.

*

First of all, I should say that this isn’t entirely straightforward,  but there are basically 3 steps to getting your UCreate to accept new sounds.  These are:

Step 1. Get your computer to recognise your UCreate device;

Step 2. Create the right kind of sound files for the device to use; and

Step 3. Load the sounds into the device.

Fortunately, there is now a step by step video tutorial on YouTube at https://www.youtube.com/watchv=Ehh1fn6D2Lk&list=PLJSvyfpaaK7ESfsIWcdwDMCS-YhIw1xc4 which tells you exactly how to do it.  This was made by Krimzon Ninja, who’s done some marvellous work in sorting this problem out, following on from a user by the name  of ‘marbs’ who created a program a couple of years ago (http://marbs-online.blogspot.co.uk/) which he called ‘u-load’.

[Edit: the YouTube link no longer works.  You can download Krimzon Ninja’s tutorial here]

Part 1 of the tutorial lists the programs required, and setting up the folders you need on the computer.

Part 2 describes how to get your computer to recognise the UCreate.

Following the instructions in the videos is the best way to do it, but these are my original notes from the first version of this article, which may help:

Step 1. Getting the computer to recognise your UCreate device.

If you just plug your UCreate into the computer and run u-load, you’ll get this:

which is no help at all.  What you need to do is install a USB driver to communicate with the device.

The way to do this is as follows:

a.  Download the driver installer program ‘Zadig’ from here: http://zadig.akeo.ie/ (choose a version according to whether you’re using XP, Vista or Windows 7), and unzip it with a program such as ‘7-Zip‘.

[Edit: Now, what I’ve been told is that not every version of Zadig will do. There are different versions for XP and Vista or later.  I used this one: http://sourceforge.net/projects/libwdi/files/zadig/zadig_v1.1.1.137.7z/download which worked fine].

b.  Start Zadig, go to the ‘Options’ menu, and select ‘List All devices’.  marbs’ instructions said ‘choose GENERALPLUS-MSDC from the drop-down list’.  I didn’t have this on the list, so I used the ‘Edit’ function to rename the one item that was there – I don’t know if this was necessary or not, but as there was only one file in the list, and only one USB device plugged in – the UCreate – I knew it must be the right  one.  Just make sure you identify the correct device or terrible things might happen!

c. Then click the ‘Install Driver’ button.

This picture shows the Zadig window, with the 4 actions to take:

1) Choose ‘List All Devices’ from the ‘Options’ menu.

2) Only one item appeared on the list, which is the long box partly hidden under the drop down menu.  Probably a good idea anyway to make sure the UCreate is the only USB device connected, to avoid confusion. I checked the ‘Edit Name’ box so I could rename it ‘GENERALPLUS-MSDC’.

3) Actually, I can’t remember what was selected here.  I didn’t change what it already said, which is probably what is showing here.

4) Clicking this button starts the installation.

d.  The installation wasn’t instant: it took a couple of minutes, and some messages came up about restarting devices.  I switched the UCreate off, restarted the computer, switched the UCreate back on, and started u-load.

This time I got the following message:

which was a whole lot better, indicating that u-load now recognised the UCreate, and was ready to load sounds and effects into it.

You only have to do this once, then your device is set up.

One final thing: I think it only fair to point out what marbs says at the end of the README file: ‘To use the original application delivered with your ucreate, you have to deinstall the [USB] driver in the device manager.’

In other words, you won’t be able to use the UCreate’s original software now, unless you can do this deinstall. I’m not sure whether Zadig does this or not; but I believe it’s designed not to remove existing drivers, so it would be possible, I presume, to restore the UCreate to its original state with this or with the Windows Device Manager.  It’s a moot point whether it would worth doing it, of course, since the website on which the original software depends no longer exists.

(Doing this on the Windows computer, incidentally, didn’t stop the original software from running on the Mac when I later connected the UCreate to that).

This is what you see when you press 1, then ENTER for ‘Help’:

This tells you exactly what u-load can do: ‘Make’ = group your sound files together into a big file which can be used by the UCreate; ‘Write’ = load these file groups onto the UCreate.

*

Step 2.  You need to create some sound files of the type that u-load and the UCreate can use (with the extension ‘.lop’).

Part 3 of the tutorial video describes how to create your own samples with the program Audacity.

Part 4 shows how to convert your samples to the format used by the UCreate with the programs Lopgen_a – Lopgen_e.

The 5 Lopgen programs can be downloaded from: https://drive.google.com/file/d/0B_ZkjKZUhAHQbWVsSWhuZXBFOFE/view?pli=1

There are some restrictions on the samples you create – principally making sure the files are not more than 5 seconds long.  There were reports in the past of some UCreate devices being irreparably damaged by not doing this.

The Lopgen programs don’t require the UCreate to be plugged in, they just work on sound files stored in a particular location on your computer.

All you have to do is create ‘.wav’ sound files with the correct attributes, and then have LopGenerator turn them into files the UCreate can recognise.

Edit the files in Audacity, to ensure:

a. they’re mono and 5 seconds long:

b. The project rate is 8000:

c. They’re saved as ‘Other uncompressed files’ and, by clicking ‘Options’, the header is set to ‘WAV (Microsoft)’ and they’re encoded as ‘Unsigned 8 bit PCM’.

d.  Finally, you need to remove all Metadata before saving the file.

Once the file or files are done, copy them to the folder with the appropriate version of Lopgen in it, and run Lopgen.

*

Step 3: The final step is to load the sound files into the UCreate.

Part 5 of the tutorial video shows how to do this using the program ‘u-load’.

To do this, you’ll be typing 2, then ENTER (‘Make SamplePackage’, as the Help screen tells you), which will create a file which you can load onto the UCreate with a ‘Write’ command.

But first, you need to rename the sound files you created, and put them in particular directories.  There are 12 buttons on the UCreate for sound files – not including the two at the bottom for your own recordings – so u-load will be expecting to see 12 files with the names ‘sample_0.lop’, ‘sample_1.lop’, ‘sample_2.lop’, etc., up to ‘sample_11.lop’.

So, find the 12 sounds you want to load, rename them like this, and put them in a folder called ‘Samples’.

Type 2, then ENTER, and u-load will ask you to give a name for the file it’s going to create from your samples.  Type in the name, press ENTER, and it will gather the 12 samples together and create the file.

I wasn’t sure whether the file required the extension ‘.upload’ or not, so I created one with and one without.  The first screengrab shows the name ‘Beats’ being entered, then ENTER:

At this point, I had to close u-load, switch the UCreate off and on again, and reopen u-load.

Type 4, then ENTER (‘Write SamplePackage’): u-load will ask you which file to upload.  Give it the name of the file you just asked it to create, it will load the samples onto the UCreate, and you’re ready to go!

*

To add files to the two spaces originally used on the UCreate for your own recordings, create .lop files as above, and put them in a folder called ‘Recordings’.  They can be loaded into the two special spaces by typing 5, then ENTER (‘Write RecordPackage’).  u-load will ask you for the name of the first file to load: tell it the name, and press ENTER.  It will then ask you for the name of the second file: give it that, too, press ENTER, and the two files will be loaded onto the UCreate.

*

[Particular thanks to KrimzonNinja.  He acknowledges his influences at the end of the video tutorial].

Guitar FXBOX – Part 1, the software

I haven’t blogged about the guitar before, although this is the conventional instrument I play.

There are enough places on the web to find descriptions of commercially produced effects – of which there are many thousands – and, with possibly one or two exceptions, I won’t be writing about these.

However, I thought it might be worth describing some which I’ve been using which were written using PureData and which together I’ve called the ‘FXBOX’.

Some of the effects I’ve bought have cost £100 – £200, but for no extra expense other than a computer – which I assume you must have, as you’re reading this – and a little know-how, all these effects and more are available.

I have to say, I didn’t write the majority of these effects myself. The know-how has come from examples in tutorials or instructions for PureData, like this one: http://en.flossmanuals.net/PureData/ or this one: http://pd-tutorial.com/ or from the PureData forum at http://puredata.hurleur.com/.

A particular inspiration was Pierre Massat’s ‘Guitar Extended’ blog. Pierre has developed a sophisticated system using an Arduino and a Raspberry Pi to make and control the sound of the guitar, which you can read about in detail here: http://guitarextended.wordpress.com/.

In my case, there were a small number of particular effects I wanted to combine in a single unit, and my good fortune was to find this Spectral Delay patch by Pierre Massat (from an original by Frank Barnecht, based, in turn on work by Johannes Kreidler, whose tutorial is referenced above): http://guitarextended.wordpress.com/2012/02/07/spectral-delay-effect-for-guitar-with-pure-data/

This became the central element of the FXBOX project. What is does is to give different delay times to different harmonics of the input, producing an effect which Pierre likens to ‘hundreds of sparks or stars that fall like raindrops or broken crystal’ – a poetic, but apt description. More conventional echo effects are also available from this patch.

In the FXBOX I put a couple of conventional effects before the Spectral Delay, namely Chorus and Distortion, and a variable attack patch; at the end of the chain I added patches for panning and stereo imaging. The two interesting effects which remain are a pitch controller – the normal guitar input can be raised or lowered by up to an octave – and an unusual ‘freeze’ effect, which can produce either a static drone or a very odd series of pitches in response to the input.

This screenshot of the main page shows the various effects and their controls: I’m very grateful to Pierre and others for making their patches available for everyone to use.

One or two people whose patches came from posts on the Pd forum, I know only from their online names: ‘ralf’ for the Freeze function [http://puredata.hurleur.com/sujet-6100-fft-freeze-help], and ‘dack’ for the Pitch Shifter from his ‘Guitar multi-effects rig’ [http://puredata.hurleur.com/sujet-2525-guitar-multi-effects-rig].

The various patches which are required to make the FXBOX work are here [Edit:  these are the revised files after changes described in Part 3 of this post]:

http://www.andymurkin.net/Electronica/FXBOX/abswitch~.pd

http://www.andymurkin.net/Electronica/FXBOX/crossfader~.pd

http://www.andymurkin.net/Electronica/FXBOX/expression.pd

http://www.andymurkin.net/Electronica/FXBOX/FXBOX22.pd

http://www.andymurkin.net/Electronica/FXBOX/Guitar_specdelay~.pd

http://www.andymurkin.net/Electronica/FXBOX/LoopGenerator.pd

http://www.andymurkin.net/Electronica/FXBOX/midiin.pd

*

All the variable controls are available on the screen, but I decided for practical performance purposes it would be best to have presets which could be selected quickly.

In addition, after starting to use the FXBOX, I rapidly came to the conclusion that it needed a controller which was easier to use than the laptop trackpad. For one thing, you can’t adjust a setting manually and still keep playing. So I set about designing a controller which would also be compatible with PureData. Some controls might practically be operated by hand, but essentially this would have to be a foot controller with buttons and pedals for the various presets, and for adjusting settings which might need to be changed while playing.

The second part of this post describes the controller.

The Black Widow MkII and more on sample manipulation

I recently came to use the Black Widow sample manipulator again and decided to make some improvements to it.

Initially, I improved some of the existing features: what I had at first perceived as ‘unreliability’ in its responses to button commands was really only a difficulty in making the required number of presses to ‘fix’ volume, filter or pan settings on a sample.  This involves making one, two or three quick presses on the hatswitch button – like making a single, double or triple mouse-click reliably – not perhaps one of my best ideas, and a little difficult to execute, especially without any feedback as to whether the fix had been made or not.  So I added indicators to show if the fixes were on or off.

I then moved the sample arrays onto the same page, so there was no need – as there had been in the original – to move from page to page on screen to see what was happening with the samples being played.  This screen also now has the various indicators for volume, filter, playing position within the sample, etc., visible next to the representation of the waveform in the array:

Above each array are also indicators ‘REVERB ON/REVERB OFF’ and ‘ECHO ON/ECHO OFF’.  I thought simple versions of these two effects would be useful, and added them to each of the output stages.  Having run out of buttons on the Black Widow, these effects are manually turned on and off by using the ‘W’ and ‘E’ keys on the computer keyboard.  (Although ‘E’ makes sense for echo, ‘W’ doesn’t for reverb, but I chose these two letters so as not to conflict with another program I commonly use, where ‘R’ and ‘V’ have particular functions; and ‘W’ happens to be next to ‘E’).

Also, on the right-hand side, indicators for ‘Auto Speed’ and ‘Number of sections done’ refer to the next change I made: a function to allow the Black Widow program to run automatically.  It’s designed to do this in a similar way to the way it’s operated manually: one sample at a time is operated on, and there are built-in delays between stages to allow a particular selected combination of settings to play for a while before being changed.

The particular settings are chosen by random numbers generated by the program.  In normal operation this will allow them to range between minimum and maximum values in each case.  In the event that this wide range is not required (for example, turning the  filter to minimum usually has the effect of turning the sound off, as does turning the playback speed to zero), there is now a page on which minimum and maximum values can be set for each parameter of each sample:

It’s possible here to fix any parameter, so it cannot be changed during ‘auto’ mode; and to fix any sample to play back at normal speed, full volume, average filter setting and centre panned.

Finally, I added a third section in which samples can be recorded into the arrays, rather than loaded from existing sound files.  This could be useful for variety in a ‘live performance’ in which short samples (90 seconds is PureData’s default maximum) could be recorded and almost immediately loaded and manipulated, manually or automatically.

The screen that opens automatically when the app is run has had to be expanded, and now looks like this:

It looks a bit complicated, but I haven’t mastered the method of producing a neat GUI; however, it works fine, and is easy to use if the numbered steps are followed.

A link to the PureData patch for the Black Widow Sample Player and manipulator can be found in a later post in this series.  The next one is here.

Here’s an example of the Black Widow in operation:

The 4 short samples used here are a recording of  a park, birdsong, running water and a live performance of the Cracklephone.

*

It’s perhaps worth mentioning here, as I haven’t done so anywhere else, a very handy little device I used, not wanting to have a full-sized keyboard in the way when I was trying to use the Black Widow controller.  This is the so-called iPazzport, a miniature keyboard and trackpad, which connects to the computer by USB.  It looks like this:

If you imagine that the trackpad is slightly smaller than the trackpad on a laptop, this gives you an idea of just how tiny the keys are – but I was still able to press the correct key when required.  In case of difficulty it comes with a stylus and a small attachment which fits on the end of the finger, with a point underneath it.

Mine was about £10 off eBay, but I don’t know how readily available they are now: the one you see these days is a wireless version which costs a bit more, between £15 and £20.  There are now some similar items – also wireless – styled rather more like TV remote controls, which look as if they might have larger keys.

*

Also worth mentioning here, if you’re interested in this kind of thing, is the work of Karlheinz Essl.  You can read about him here: http://en.wikipedia.org/wiki/Karlheinz_Essl_junior and on his website at http://www.essl.at/.

Of particular relevance in relation to the Black Widow project is one of the various programs Essl has created for sample manipulation, fLOW, which is described like this: ‘fLOW . . . generates an ever-changing and never repeating soundscape in real time that fills the space with flooding sounds that resemble – metaphorically – the timbres of water, fire, earth, and air. This ambient sound scape generator adjusts itself through various parameters and controllers that are represented in real time on your screen.’  It comes with four samples, which are are loaded and manipulated automatically via a comb filter, ring modulation, frequency shift and a flanger, but you can also load your own samples into it for a more personalised experience.

You can read about fLOW and download it from http://www.essl.at/works/flow/download.html.  I don’t remember how much it costs, but it isn’t very much, and well worth the money.

This is an extract from a track created with fLOW. The source file was an edited recording I made of a boat passing through a lock in Earith, Cambridgeshire:

It’s well worth reading more about Essl, too.  His main preoccupation is one that I’ve become interested in in recent years: ‘music that is created at the moment of its sounding (“realtime composition”)’. Improvisation, looping and manipulation of sound and music samples are all part of the same field, and chance can play a significant role.  In a later post I’ll be mentioning another his programs, REplay PLAYer (found at http://www.essl.at/works/replay.html), a multi-featured program for manipulating a single sound sample.

[Edit: that post is here]

*

Finally, a very nice freeware program with similar features which I’ve used is Sineqube’s Sapling, which is described here: http://www.sineqube.com/blog/?page_id=157.  Sapling provides an easy means to load 4 samples and vary – manually or automatically – the speed and volume of playback, and the length of a loop created within each sample.  It works well with short samples and allows a very useful combination of automatic and manual adjustments to be made in real time as the samples are played, and a facility for recording the output to disk.

This is an extract from a track created using Sapling.  The source file was an edited version of some recordings I made on my iPhone of a windmill in Burwell, Cambridgeshire:

*

With all of these programs, including the Black Widow in Auto Mode, I enjoy setting up the conditions and listening to the samples play, although for a more permanent record of what was created, I normally edit the recorded results.

*

[Edit: more modifications have been made to the Black Widow Controller (although not for sample manipulation). See this post.

MIDI controls have been added to the Black Widow MkIII, described here].

The Black Widow – Sample Manipulator

I was lucky enough to get a decent joystick for a good price from eBay, a Speedlink ‘Black Widow’:

Obviously, this is a bit more sophisticated than the controller with small joysticks which I used for the StyloSim, and the kind of thing used for semi-realistic flight control programs, having a throttle on the left-hand side and joystick on the right, and a nice feel to it.

As for musical applications, it connects to a computer via USB, as can be seen in the photo, so is very suitable for use with PureData’s ‘hid’ (Human Interface Device) function.

I thought at first of designing an instrument, but felt this would be less easy to operate than the Cybersynth or Theresynth, which used gamepad-type controllers.  An effects device like the StyloSim would be possible, but at the moment would seem like going over old ground: something I might come back to later.

Instead, I decided on a device for manipulating samples.  At the time I thought this was an original idea, but I have subsequently discovered someone who does this – in quite a different way, but using the same kind of device: http://www.youtube.com/watch?v=9wdb6-QLnQ0.

That was Johannes Kreidler, a very interesting contemporary German composer making music with cutting edge electronics.  Check out his website at http://www.kreidler-net.de/english/index.html or type ‘Johannes Kreidler’ into YouTube.  Kreidler is also an expert on PureData, as it happens, and wrote the very good tutorial ‘Programming Electronic Music in Pd’, translated into English at http://www.pd-tutorial.com/english/index.html.

So, I used PureData to create a simple device for manipulating samples with the Black Widow.

There are 4 buttons on the front of the Black Widow:

These are used to control up to 4 separate samples: when the Black Widow Pd app is first opened, the buttons are pressed one by one to load the 4 samples; when in use, the throttle, joystick and other controls operate on the sample whose button was last pressed.

As for the other controls, these are: on the left, the throttle, which includes two buttons on the reverse,left and right:

Pressing the left-hand button on the back of the throttle and moving the throttle forward from the central position increases the sample playback speed; moving the throttle backwards from the central position increases the playback speed, but plays the sample backwards.  When the button is released the speed and direction are fixed.  Pressing the right-hand button on the back of the throttle toggles the playback direction.

Moving the joystick to the left pans the sample to the left; moving it to the right pans it to the right.  Moving the joystick forward from the central position increases the playback volume; moving it backwards from the central position increases the centre frequency of a bandpass filter.

The other buttons on the joystick have the following functions:

The button F3, when pressed as the sample is playing, sets the start point of a section within the sample; F4 sets the end point.

The hatswitch has 4 functions: RIGHT cycles playback from the start point to the end point of a section set with the F3 and F4 buttons; DOWN pauses playback; UP Restarts playback; LEFT fixes a volume or filter setting.

F2 restarts playback at normal speed from the beginning of the sample.

This is the control window, in the process of loading a sample:

There are some problems with it: it doesn’t always seem to respond to instructions, particularly the ‘Fix’ command from the hatswitch, don’t quite know why.  Also, the interface isn’t very practical: if you want to look at what you’re doing as well as listen, there are separate windows for each sample which you have to bring to the front.

However, it mostly works as described, and is quite entertaining to play with!  I’ll post a sound file shortly.

[Edit: the Black Widow has been superseded by the Black Widow, MkII, described here].

Jack and the StyloSim

My next programming project was designed as an experiment to see if Pure Data could deal with QWERTY keyboard input, USB input and audio input all at the same time.

I planned to make an audio effects device, using a Stylophone for the audio input, plugged into the laptop’s 3.5mm (1/8″) stereo mic/line in socket; the laptop keyboard; and a nice twin-joystick device I found on eBay.

The joystick device was called ‘USB Simulator’ (‘For Airplan Heli’) and had the model number FS-SM020.  The two joysticks were quite good to use – not the kind you grip in the hand, but bigger than the thumb-operated joysticks you get on a game controller, plus each of the 4 axes had separate adjusters which you could use to fix the centre of the joystick’s range of control.  There were a couple of buttons on the front, which you can see on the bottom right and left, but these proved to be cosmetic only once I opened the case and looked inside.

I couldn’t find out much about this device on the internet, except that it was, as its name implied, normally used for flight simulation – presumably to simulate a radio-control transmitter – and, in fact, it came with a CD, probably containing the simulation program.

The case was quite large, and there would be ample room inside for further circuitry.  I may look at this possibility later, but for the moment I made no alterations to the device, intending just to use the two joysticks: a bandpass (‘wah wah’-type) filter and volume for the left one, and a binaural panning control for the right one.

The first problem to be overcome was to make sure the audio input from the Stylophone couldn’t be heard, only the output from Pure Data, which would hopefully be the audio input modulated by the joystick effects.  This was achieved by the simple-to-use and very handy audio-routing program Jack.

Jack works by running an app called JackPilot.  When opened this presents a small window like this:

Actually, the top button on the left reads ‘Start’ when opened, but I took this screenshot after clicking it and starting the Jack server.  The normal procedure is to open Jack, start all the programs involved in your routing scheme, then click ‘Start’, and then, when it’s ready, ‘Routing’.  (Just occasionally, you may have to start some audio running through a program before Jack recognises it, but mostly that isn’t necessary).

The Routing window looks like this:

All the inputs are in the left-hand column, all the outputs on the right; it always shows the System audio in and out.  In this instance I was just practising, so I only used Pure Data, but I would frequently have Logic running, too.  To set the route, click on all the inputs and outputs in turn (they are shown in red when being edited), and click on the item(s) you want them to be connected to before moving on to the next one.

At the beginning of the Pure Data program I put the ‘Print’ and ‘Open’ instructions, as I did for the Theresynth and Cybersynth (see previous posts):

This configuration enabled me, once I’d plugged in the Stylophone (audio input) and Simulator (USB input),to check the Device number of the Simulator and open the Device so the ‘hid’ object would receive and deal with the output from the two joysticks.  When I clicked the ‘Print’ message box at the top, the following was printed in the Pure Data window, telling me that the Device Number was ‘0’:

(It also gave the Device’s name ‘FS-SM020’, which it hadn’t done with the particular game controller I used for the Theresynth and Cybersynth).

As the Device number was 0, I amended the ‘Open’ box to show this number, and clicked it.  Then I clicked the ‘Print’ message box at the top again, and it showed me the controls it could recognise:

The 4 axes of the joysticks can be seen (‘abs_x’, ‘abs_y’, ‘abs_z’ and abs_rx’, I think, and I can’t remember if any input was recognised from ‘abs_ry) – and also 3 buttons, but the button function hadn’t been implemented in this device.

I clicked the on/off toggle switch, applied the stylus to the Stylophone keyboard, and sounds issued forth – a very good sign!

The Pure Data StyloSim program had three inputs:

On the left is the [key] object, which receives input from the laptop keyboard.  In the end, I added only the box with [== 114] in it: 114 is the ASCII code for the ‘r’ key, so the program only responds to the letter r, turning a reverb effect on or off.

[Edit: I later changed this to 119, the letter ‘W’, to avoid conflict with another program that used ‘R’ for a different function]

In the middle is the audio input, [adc~] (analogue-to-digital converter), which leads to the output stage.

On the right is the [hid] (Human Interface Device) object, receiving input from the 4 axes of the joysticks.  The [route] objects separate the 4 inputs and send them in different directions for their various functions (bandpass filter, volume and binaural panning).

All the effects worked – although the panning was less binaural than left-to-right; I’ve heard better.  This is the complete patch, showing the objects I used, and the mathematical calculations required to get it right.

The patch can be downloaded from here.  (Click ‘Save Link As’).

This proved that Pure Data could combine information from the keyboard (or an external USB QWERTY keyboard) and [hid] to work on an audio signal entering simultaneously.   As  can be seen from the following picture of the set-up in action, I used ‘The Alien‘, my first Stylophone modification, as the audio source.

This instrument has a ‘drone’ function, so it’s possible to put the stylus down and operate both joysticks on the Simulator at the same time.  Both the joysticks, incidentally, are centre-sprung, meaning that all values return to the central ones, except the y-axis of the left one – the bandpass filter.  This means the centre-frequency of the filter can be set and left while other parameters are adjusted.

Here’s a sound file illustrating the StyloSim:

It’s more of an example than an actual piece, just to show what the StyloSim does.

It’s slightly edited, but only to make it a bit shorter, otherwise it’s exactly as it sounded when played. There’s no post production effects on it, I just hit the ‘r’ button to turn on the StyloSim’s reverb before I started.

There are three parts: the first part is the Stylophone played with the stylus in the conventional manner; the second part uses The Alien’s ‘drone’ feature and variable pitch and vibrato controls; the third part is played with the ‘feedback’ switch on.

[Edit: more modifications have been made to the StyloSim joystick (although not for this particular use).  See this post].

Cybersynth – the Theresynth improved

After finishing the Theresynth I thought of a way it could be significantly improved.

A little while before, I had experimented with alternative methods of inputting QWERTY keyboard information to the computer, by removing the circuit board and attaching different kinds of switches (See ‘A New Use for USB Keyboards‘).  I reasoned that the same might apply to gamepads/game controllers: as long as the USB chip inside was still attached to the USB output, it would still be recognised by Pure Data, no matter what kind of switches were used to control it.

In order to test this theory I bought another game controller of the same type as the Theresynth (A ‘PCLine Rumble Game Pad’), took it to pieces and threw away the buttons it came with, leaving just the joysticks and the USB cable attached to the circuit board.

Just as I had done with the dismantled QWERTY keyboard, I scratched away the surfaces of the tracks where a couple of the switch connections had been, soldered wires to the board and push-button momentary switches to the wires.  I plugged the board into the computer via its USB cable and opened the Theresynth patch in Pure Data.

I followed the steps to set it up, as I described in the Theresynth post, and, sure enough, Pure Data recognised it, just as if it was the game controller, rather than a circuit board hanging off the end of a USB cable; when I pressed the test buttons I had soldered onto the board, the ‘hid’ object recognised them just the same as the buttons on the original gamepad.

Confident that I could operate the Theresynth with any type of enclosure for the circuit board, I considered how I could rehouse it.  An obvious thought struck me: I had recently bought a plastic Cyberman head (if you aren’t a fan of Dr Who, they have their own page in the Wikipedia at http://en.wikipedia.org/wiki/Cyberman) for about 50p from a local charity shop, and it was clear that the eyes were spaced apart almost exactly the same as the distance between the joysticks.  This was a clear sign of what I should do next.

In short, I transplanted the gamepad circuit board into the Cyberman head, with the joysticks in the eye sockets and 12 or 14 buttons round the outside in a vaguely ergonomic layout.  A chance visit to a Poundshop during the course of construction produced a nice USB-powered chain of blue LEDs, and I glued these at stategic points on the inside, producing an eerie glow when the instrument was plugged in.  Another spare USB Type A socket from one of my broken Apple keyboards took the place of the hard-wired output lead, and the Cybersynth was ready for action.

I took the opportunity to make some improvements to the Theresynth patch in Pure Data, adding, amongst other things, a facility to change the starting note from A to any other suitable pitch.  I automated some of the device number/control checks at the beginning, and the switching on of Pure Data’s audio.

The starting window now looked like this:

The Pure Data patch for the Cybersynth is here.  (Click ‘Save Link As’)

This photo guide, which I produced for myself before putting the circuit board inside the head, gives an indication of what the buttons are for, and what functions are included in the patch:

I never figured out quite what to do with the former hatswitch controls.  In the end I stuck the switches on the back of the neck and used them for a sort of trill effect – the top button raises the pitch by a 5th when pressed, the bottom one lowers it by a similar amount.

The Theresynth

I recently blogged about using a gamepad as a drum controller (https://andymurkin.wordpress.com/2012/01/09/drums-with-multicontrol-v0-4/), and this was my next project using a Human Interface Device (HID).

HIDs are the devices we use all the time to interact with computers.  Keyboards, mice, trackpads, trackballs, joysticks, gamepads/joypads/game controllers and graphics tablets are all HIDs, and all can be turned to musical use with the aid of a suitable program to interpret their output.  I chose to start with projects using game controllers because they have a fair number of buttons – and often joysticks – and are designed to fit comfortably in the hand (or hands).

The gamepad I used for the drum controller had just buttons, but the one I used for the Theresynth had two thumb-operated joysticks.  I planned to use one of these for controlling the pitch of an instrument.  In addition, although I had used the pre-made MAX/MSP app ‘MultiControl’ for the drum controller, I planned to use Pure Data and do my own programming.

This was not as reckless at it seems, as programming in Pure Data is done graphically.  Many mathematical and audio functions are pre-programmed for you: all you have to do is draw boxes, write in them what function you want performed, and join the boxes together in sequences.  Easier said than done, as I discovered, but easier, I thought, than writing lines of code.

I have described progamming in Pure Data in my post about creating alternative musical keyboards, using QWERTY keyboards (https://andymurkin.wordpress.com/2012/01/01/alternative-keyboards-4/).  There, ‘key’ was the main Pure Data function used, as this is designed to receive key presses from the QWERTY keyboard; in the application I’m about to describe the special function ‘hid’ was the key to interpreting the output from the game controller.

There are many Pure Data instructional videos on YouTube, and this one in particular: www.youtube.com/watch?v=HB_oVny33wA deals with ‘hid’ and game controllers.

If you’re working on a project like this one, the first thing to do is to allow ‘hid’ to get Pure Data to recognise the game controller.  To do this, plug in the game controller, run Pd-Extended.app, open ‘New’ from the ‘File’ menu and write (or draw, rather) the following into the empty box ‘Untitled-1’.

This is a short program which will show all the connected USB devices which Pure Data can recognise.  The ‘Print’ command is in a ‘message’ box, and is connected to the input of the ‘hid’ object.  Inputs are on the top of object boxes; outputs are on the bottom.  When you click ‘Print’, it sends the message, and gives a reply like this in the Pure Data window:

Each connected device has been given a number.  The first six, ‘Device 0’ to ‘Device 5’ are simply the different elements of my MacBook, keyboard, trackpad, and so on; but the seventh one, Device 6, looks like the important one: ‘4-Axis, 12-Button with POV’, ‘device type: joystick’.

Sometimes it will tell you the make and model; in my case, my ‘PC Line Rumble Game Pad’ is identified only by its ‘vendor ID’, 0x0583, and its’ product ID’: 0xa009.

We need to know the Device number, as we’ll use that in the program.  It doesn’t always come up as Device 6, so I always include in my Pure data programs a facility to check this number, and amend it if required.

The next step in writing a Pure Data program based on the ‘hid’ object, is to identify the outputs from the buttons and joysticks  in the controller.  This is done by a couple more additions to the simple program which produced the list of devices:

‘Open 6’ is another message box.  The small square on the left-hand side is an on/off ‘toggle’ switch, which I won’t be using now, but I’ll use it in a minute.

Click ‘Open 6’, and messages from Device 6 are routed to ‘hid’; click the ‘Print’ message box at the top again and the ‘Print’ object at the bottom will produce a list in the Pure Data window of all the buttons and controls in the device:

This shows 12 buttons, (‘btn_0’ to ‘btn_11’), the up-and-down and left-to-right axes of the left-hand joystick (‘abs_x’ and ‘abs_y’), the up-and-down and left-to-right axes of the right-hand joystick (‘abs_rz’ and ‘abs_ry’) and a hatswitch.

Now you know this, you can separate each of the inputs as they come out of ‘hid’ and get them to do various things – make noises (as I did with the gamepad MIDI drum controller), control effects (like filters, for example), and so on.  Other Pure Data objects (boxes like ‘hid’ and ‘print’) can do mathematical transformations along the way.

The way to separate them is in stages.  First of all, look at the left-hand column above.  There are two types of entry here: ‘abs’ and ‘key’.  Using a Pure Data object called ‘route’, we can get the ‘key’ information (from the buttons) to be separated from the ‘abs’ information (from the joysticks and the hatswitch):

Then, looking at the second column, we  can separate out the 4 joystick axes and the 12 buttons:

While I was testing this out just now I did two extra things, which you can see in the screenshot above: firstly I added the small box at the bottom, which is called a ‘bang’.  If everything’s working properly, this will flash on and off when I press the button ‘btn_0’ – which is very likely marked ‘Button 1’ on the game controller – and secondly I clicked the on/off switch (the cross means ‘on’) so that ‘hid’ would recognise and output button presses and joystick movements.

Because the MIDI note number and control system lends itself easily to mathematical manipulation, this  would be a common way to use Pure Data.  In this particular application, however, I decided to use some of its many audio functions.

I’d spent some time modifying stylophones, as you may have read in previous posts.  The thing about stylophones is getting great sounds from them is easy, but getting sinewaves out of them is well-nigh impossible.  In Pure Data, however, it is extremely easy, so I decided to create an instrument which would produce ethereal sinewave sounds, rather like the Theremin.

The Theremin is a wonderful electronic musical instrument, which you play without touching it!  If you don’t know what it is, you can read about it on the Wikipedia at http://en.wikipedia.org/wiki/Theremin.

My plan for the ‘Theresynth’ was less ambitious, but would involve using one of the game controller joysticks (the left one) to control pitch and the other (the right one) to control volume.  In the event, I also added a kind of vibrato (more of a fast auto-pan), controlled by the other axis of the right-hand joystick.  This added a little more depth and interest to the sound.  As well as this, a programming error I made along the way also enabled me to add a second tone to the instrument, which was a kind of frequency modulation/ring modulation – very effective in the lower register.

The exact method by which I achieved this is rather lengthy to explain, and I’ll attach the ‘patch’, as bits of Pure Data programming are called, so you can see, if you want to study it.  In principle, though, it went like this:

The output from the the joysticks is in the form of numbers from 0 to 255.  Divide this in half and you get all the MIDI note numbers (they run from 0 – 127); convert the MIDI numbers to frequencies and use this as the input to an oscillator, feed the oscillator into an output amplifier and you have a simple musical instrument!  All these functions are available in Pure Data.

Using ‘abs_x’ (left-to-right on the left-hand joystick), as I did in the Theresynth, that part of the circuit would look like this:

‘/ 2’ means ‘divide-by-2’; ‘mtof’ means ‘convert MIDI note to frequency’; ‘osc~’ is an oscillator; and ‘dac’, the digital-to-analogue converter sends audio out to the computer’s sound system.  The number 64 is is in a ‘number’ box – it doesn’t do anything, it just tells you what MIDI note is passing from ‘/ 2’ to ‘mtof’.  Useful if you want to check what’s going on.

This program works – I’ve just tested it (but don’t forget to turn ‘audio ON’ from the ‘Media’ menu of Pure Data) – but the problem is that the travel on a gamepad joystick is not that far, and you don’t want to go from the lowest MIDI note possible to the highest in such a short space.  So a lot of what I had to do was to restrict the range of notes available.

In the end, as you’ll be able to see in the finished patch, I did this by dividing again by 10, severely restricting the range of notes available to the joystick at any one time; and then using one of the buttons as a freeze-pitch button, with a very short time-delay to allow the joystick to spring back to the middle.  In this way it’s possible to play a few notes, ending higher or lower than where you started, freeze the pitch there, let the joystick go back to the middle at this new pitch, and gradually move up and down in steps, as required.  After a little practice, this came to seem quite natural.

I never quite got the hang of creating a nice interface for my Pure Data programs, so the window that opens looks like this:

Following these steps gets the Theresynth ready to use.  Steps 1 – 4 just operate the checks I described above: identifying the device number, checking the buttons are all recognised by the program, opening the device and switching on ‘hid’.  Step 5 reminds me to turn the audio on – although in later programs I found out how to do this automatically when the program loads.  Step 6 may or may not be necessary, but clicks some toggle switches on and off to guarantee everything is ready to work, but stays silent.  Step 7 turns up the volume and you hear the initial tone, which is A (440Hz).

The actual programming is visible in two windows, ‘controls’ and ‘oscillators’, which can be opened by clicking the boxes in the bottom right.

In my next post, I’ll describe how I improved this design, but the instrument definitely worked, and seemed to me to be a good use for a second-hand joystick.

Drums with MultiControl v0.4

Here’s a method I used to play a virtual synth drum patch with a cheap (£3 or £4 off eBay) USB game controller and the program MultiControl v0.4.

Here you can see the game controller I used (the type without joysticks), and the MultiControl window.

To set it up, plug in the game controller, open MultiControl and select ‘USB Gamepad’ or similar in the top right of the MultiControl window.  There’s a drop-down list of devices that the program has detected, including the keyboard/mouse/trackpad of your computer, but it should be obvious which one is the game controller you want to use.

MultiControl is a MAX/MSP-based application, and will also open the MAX/MSP Status window.  To start with, this window will probably show you some information relating the keyboard/mouse/trackpad of your computer, but once you’ve selected your game pad at the top, all you need to do is press each button: the program will detect each one and allocate it to a separate line in the MultiControl window.

There’s a video on YouTube explaining how to set up MultiControl, and how to use it.  If you’re intending to do this, it would be good to look at that, here: www.youtube.com/watch?v=I0Z5WpiDQR8

This is the MAX/MSP Status window.  On opening the program, it registered the information in the top half of the window; once I selected ‘USB Gamepad’ it began with ‘hi: focussing on USB Gamepad’ and waited for me to press the buttons; as I did so, it listed them (there are 11 on this device) and allocated them to lines 1-11 in the MultiControl window.

This is a general screen example, not from this Gamepad application, but you can see that the first column, ‘Input’, registers button presses – the shaded bar moves across the box as the button is pressed – and the 7th one, ‘Values’, shows (in the case of this Gamepad application) ‘0’ when the button is not pressed (i.e. ‘off’), and ‘1’ (i.e. ‘on’) while it’s pressed – except for the hatswitch buttons, which can register 0, 0.5 or 1 at different times.

The 4th column shows each button’s control number, ‘c1’ being line one, ‘c2’ being line 2, and so on.  This information will be useful later on.

The rest of the left-hand side of the MultiControl window is not important for this purpose, but the right-hand side, the MIDI side, is.  To allocate the 11 controls to particular MIDI drums, I had to turn MIDI output on by clicking the small box at the top marked ‘MIDI on’; change the first 11 boxes in the next  column to ‘noteout’ rather than ‘ctlout’; and set the MIDI note number for each in the next column ‘MIDI range’.

You can see this in the instruction video, the range being set by clicking and dragging; but in the video you see a rather vague range being set.  The boxes in the ‘MIDI range’ column are so small that it’s very difficult (well, I found it impossible) to set precise values – it was OK starting from 0 on the left-hand end of the box, actually, but getting the upper value correct was the hard bit.  Unfortunately, this upper value is critical, as it represents the exact MIDI note number of the drum sound you want to make when you press that button.

However, this can easily be got round.  This is because it’s possible, using the ‘Save file’ box at the bottom, to save your settings and then retrieve them later, so you don’t have to input them all again every time you want to use a particular gamepad or other device for a particular purpose.  I used this feature to input the exact values I needed, in the following way:

First of all I worked out which buttons I wanted to operate which drums.  Practising with the virtual synth I intended to use, I noted which drum was which, and which note of the keyboard produced that particular drum sound.  Using my chart of notes and MIDI numbers I listed the 11 buttons and wrote the appropriate MIDI note against each one.

By clicking and dragging from the left hand side to somewhere in the middle of each of the 11 boxes in the ‘MIDI Range’ column, I produced a number in the next column, ‘values’, that was pretty close to the MIDI note number I needed for that particular drum sound when the button was pressed.  In every case I had been able to get it to show 0 when the button was not pressed, which is what was needed.  I then saved the settings file with an appropriate name.  These files have the extension ‘.xml’.

I then opened the .xml file in a text program (e.g. BBEdit).  Apart from some general stuff at the beginning, each button had a long entry between the tags <patcher name => and </patcher>.  They didn’t come out in order from 1-11, but this is the entry for the button described on line one, as you can see from the line near the bottom, which says “text edit” value = “c1”.

You could, I suppose, edit any of the values in here.  I’m not at all certain what they all are, but the one that needs editing in this instance is the 4th line: “X Range” value = “0 51”.  The meaning of this is that pressing the button moves the value output from o (no note) to 51 (D#3 – can’t remember off the top of my head what drum sound that represented in the virtual synth I was using).  If you go through each of the entries and make sure that the first number is 0 and the second one is the MIDI note that button is supposed to output, you can save the file when you’re done, with all the right numbers in it.

Next time you want to use this controller for this application, you can just click ‘Open file’ and ‘Load’, and all your saved settings will appear.

The only remaining thing you need to know is how to set up the inputs and outputs.  MultiController has a window for this, which appears when you choose ‘MIDI Setup . . .’ from the ‘File’ menu.  My notes to myself say to set it up like this:

(Although it seems likely that I meant “to MultiControl 1” or “to MultiControl 2”  and  “from MultiControl 1” or “from MultiControl 2”.  If no other MIDI devices are being used at the same time, it almost certainly doesn’t matter).

You might need to use the IAC Driver Bus 1 or 2, depending on the number of MIDI devices you’re using at the same time, but whatever you end up doing, you’ll need to change the ‘MIDI Device’ setting at the bottom of the main MultiControl window, and the input device setting of the synth you’re using, so that they agree.

If you need to change the ‘Audio MIDI Setup’ (on a Mac, at any rate), clicking the ‘System Setup . . .’ button in the bottom left of the MultiControl MIDI Setup window will open that for you, instead of you having to go to ‘System Preferences’.

A new use for USB keyboards

In the course of creating alternative keyboards, and interpreting USB inputs, I had an idea for a project which could prove to be useful.

It occurred to me that the computer was able to recognise the input from QWERTY keyboards because of the chips and circuits inside the body of the keyboard – the actual switches themselves, how they were laid out, what exactly they represented, were irrelevant.  So, if you had access to the circuit board inside the keyboard, and left the USB connection intact, you could do what you liked with the switch connections.

The keys of a QWERTY keyboard are arranged in a matrix – I had no idea how many connections there would be in each axis, and it probably differs from one model of keyboard to another.  But I had an old Apple keyboard I was about to throw out because of sticky keys, and I decided to experiment on this.

Here’s what I did:

First of all, I took it apart, threw away the casing, put the switches to one side, and detached everything from the circuit board, except the USB lead.

As it happens, the circuit board in this keyboard is unusually large – covering the whole width of the keyboard, and with extra USB sockets on each end.  Normally, the mouse would be plugged into one of them – and they aren’t the same: the one with the lead attached is the one that has to be connected to the computer.

The extra USB connectors on the ends of the board would probably be useful later, but more important was the circuit board itself.  Here you could see the two series of tracks for the two different axes of the switch matrix.

In theory, each track in the first series – which I called Series A – would give a different output when connected to each track in the second series – Series B.  There was only one way to find out: I plugged the USB lead in to the computer, opened Word, and got to work with a lead and crocodile clips.

If I remember correctly, I had to scratch off the track surface a little to get a good contact, but starting on the left I clipped the lead to the first track, A1, and progressively touched the other end to B1, B2, and so on, noting in a table what letters or symbols appeared.  When I reached the end of the Series B tracks, I reattached the lead to the second track on the left, A2, and repeated the procedure, touching each of the tracks in Series B and noting the results.

Not all the combinations seemed to work, but eventually I produced the following table:

This list seemed to contain all the letters of the alphabet and all the numbers 0-9, so I considered this a great success!

It seemed to me that tracks 1, 2, 4, 5, 6, 7, 9, 10, 11 and 12 in Series A, and tracks 2, 3, 4 and 11 would be the useful ones – 14 connections giving 40 outputs.  It wouldn’t matter what kind of switches were used to make the connections, their output would be predictable and the ASCII codes they produced could be interpreted reliably by programs such as Pure Data.

All I had at this point was a circuit board with a cable attached to it, so I decided to put it in a permanent box.  I had a suitable one to hand, which it would just fit in, and decided to use this, together with sockets on the rear connected to the 14 tracks.  I gingerly soldered ribbon cables to the two series of tracks, and this photograph of the inside of the box shows how it looks:

You can see the leads from Series A on the left-hand side and the leads from Series B on the right-hand side, leading to a circuit board with PCB connectors.  These are connected to 3 different sockets on the back of the box.

There are 3 sockets because I decided that not every potential application would require the full 40 connections.  There’s a 15 way DB15 HD socket (the type used for VGA) for any application requiring the full 14 connections (10 x 4 matrix covering all the letters A – Z, numbers 0 – 9, and a couple of others); a DB9 socket for applications requiring only 7 or 8 connections (4 x 3 or 4 x 4 matrix, e.g. a numeric keypad); and a 4-pin socket (the type used for S-Video) for an application requiring only 4 connections in a 2 x 2 matrix.

The original circuit board, as described above, had a hard-wired USB out lead and a USB A socket on each end.  As you can see from the above pictures, I took off  the hard-wired output lead and replaced it with one of the sockets from one end of the board.  I know you’re supposed to have USB B, not USB A sockets in this position, but it’s easier to come across USB A to USB A leads, and the functioning is still the same.

The large DB25 socket, and the two 5-pin MIDI sockets on the left are for a future project, not yet finished, for a fully-featured MIDI controller.  I’ll describe this in a later post, when I get round to constructing it.

I also bought a supply of leads, ready for when external switching devices need to be attached.  In some cases this was easier than others.  I chose these formats partly for the availability and inexpensiveness of the leads, but was unaware that the 15-pin HD leads commonly seen are designed for VGA or S-VGA, which don’t have all 15 pins connected one-to-one.  In the end I found the ones I needed, but if you’re doing the same kind of thing, take care.

The final thing to note is the circuit on the left-hand side of this picture:

Although not strictly necessary at this stage, I decided to add this feature while I was working on the box.  The MIDI controller, planned to be in the same enclosure, would need a USB converter in order to be attached to the computer.  The only USB converter I have at the moment might be required in future for another device, so I decided to add a MIDI to USB converter to this box, which the MIDI controller could use if necessary.

I took a chance on a cheap MIDI converter, which was £5 on Amazon.

I had read bad reports of these things, but they’re so cheap compared to the brand name converters, I thought I’d see what they were like.  You can get them for even less than £5, direct from China.  When I got this one, I took the circuit board out of its plastic casing, chopped off the the in/out leads and rewired them to the sockets on the back of the project box.  It was powered via USB, and appeared to work fine with my Sonuus G2M Guitar to MIDI converter, so I took the final step of cutting off the USB lead and attaching the USB output to the spare USB input on the Apple keyboard PCB.  (It was spare because, as mentioned above, I took the socket off to create a new USB output socket instead of the hard-wired lead).

It still worked, so I put the lid back on the box, and called it a day on that project for the time being.  When I get round to creating some alternative switching devices, or start on the MIDI controller, I’ll post something on them.

A brand of keyboard with a smaller PCB would probably be more practical, and any keyboard will do, if you want to try it yourself.  There’s an excellent video on YouTube, here:  www.youtube.com/watch?v=a3NxQ60E72k, which goes through the steps very clearly.

It just so happens that I saw a job lot of broken Apple keyboards for sale like the one I used here and bought them for about £1 each, so I’m stuck with these for future experimentation!  The faults they had were various – sometimes it seemed to be the circuit boards, sometimes it was just the odd key, so all of them looked usable in one way or another.

I may not need the circuit boards – although I could make self-contained instruments if the cases were big enough to hold them – but I have plans for the keying mechanisms, which could be interesting.

Alternative Keyboards 4

After creating the isomorphic alternative keyboard with a Cherry USB QWERTY keyboard and the program MIDI Integrator (see my previous post ‘Alternative Keyboards 3‘), I started to think about the possibility of using two keyboards, like the Jammer.

The Jammer uses MIDI Integrator, but it can do this because it uses two AXiS-49 MIDI keyboards.  It wouldn’t be possible for me do the same with two QWERTY keyboards, for two reasons: a) MIDI Integrator only has the facility for mapping one QWERTY keyboard at a time, and b) MAX/MSP does not recognise alternative key codes with the ‘Shift’ key pressed – i.e. both ‘q’ and ‘Q’ are interpreted the same, even though they have different ASCII codes.  This would mean that however many keyboards you had, they would all output the same notes to the same synthesiser or sound card.

So, I needed to find an alternative program for this application, one that would recognise two QWERTY keyboards, be able to interpret their outputs separately, and potentially route them to two different synths.

A program that will do this is ‘Pure Data’, a relative of MAX/MSP.  Like MIDI Integrator (but unlike MAX/MSP itself) it is free to use, and programming is done graphically.  Full details are on the Pure Data Community site at http://puredata.info/.

A piece of Pure Data programming looks like this:

You create the different types of boxes, write in them the values or functions and sequence them by joining them together with lines.  In the above example, the message box at the top contains the number 60, the MIDI note number for middle C, and a little lower down is a box with the function ‘mtof’, MIDI-to-frequency, which converts the MIDI note number to a frequency measured in Hertz.  There are 4 boxes marked ‘osc~’, which represent sine wave oscillators, mixers (‘*~’) and a graph which will display the complex waveform created by the summing of the 4 sine wave oscillators.

Amongst the many functions available in Pure Data are ‘key’, ‘keyup’ and ‘keyname’, which are designed to accept input from a QWERTY keyboard.  The function ‘key’ accepts and outputs the ASCII key code when a key is pressed, ‘keyup’ does the same when the key is released, and ‘keyname’ tells you the name of the key in use.

Most importantly, Pure Data accepts all ASCII codes, and can therefore distinguish between simple key presses, and key presses + Shift.  This means you can have two whole keyboards-worth of different key numbers, making it worthwhile using two keyboards, with no ASCII code being duplicated in both of them.  As long as the program could be made to understand which numbers belong to which keyboard, it would be possible to treat each keyboard differently, and route their outputs to different MIDI synths.

So what I needed was a) a second Cherry Keyboard, and b) to learn how to program Pure Data to distinguish key presses from one keyboard or the other; divide them into two streams and deal with them separately; and use the ASCII codes received to output appropriate MIDI note numbers.

The second keyboard was easily found on eBay.  It had a PS2 connector, and it was from this experience that I gained the knowledge of PS2 to USB converters which I wrote about in this post: https://andymurkin.wordpress.com/2012/01/01/alternative-keyboards-2/.  It functioned perfectly with the aid of a ‘Blue Cube’.  I also removed the keycaps, cleaned the (second-hand) keyboard, and  painted the keycaps blue.  It wouldn’t matter which keyboard was used for the left hand and which for the right, as they are identical models, but I tend to use the blue one for the left hand and the red one for the right.

They’re set up here for testing purposes only.  Having two separate keyboards for left and right hands means that in practice, they can be placed in a more ergonomically suitable fashion for comfortable playing.

(The eMac they’re connected to is almost worthy of a post of its own.  If you’re a Mac User, and you’ve got room for an old-fashioned CRT-screen desktop, it’s worth considering an eMac: nobody wants them, so they’re very cheap: this one, which was £20 off eBay has the same OS as my laptop – not the latest Mac OS, but a perfectly respectable one; it has firewire as well as USB and Ethernet, and a DVD ROM/CD burner drive.  I’m able to use it as a dedicated MIDI machine, and use the laptop for soft synths and recording.

Upstairs in the Music Room I have 2 iMacs, which are similar in appearance, but slightly smaller.  These aren’t as good as the eMac, and aren’t able to run such a recent OS, but are still able to perform some useful tasks as VST instruments hosts, MIDI control my Behringer V-Amp, and so on – and they were £5 each!)

The USB hub I installed in the Superstylonanphone came in handy at this point: although the eMac has 3 USB connectors, I was beginning to run short, as both of the Cherry keyboards needed to be connected individually, as well as various other devices I was using at the time.

Not shown is a vital piece of equipment required for the blue keyboard, which is a clip to hold the Shift key down.  In order to take advantage of the two keyboards-worth of ASCII numbers recognised by Pure Data, it was necessary to do this – Caps Lock only affects the letter keys, not the others – and I haven’t yet found the best way of doing it.  The next thing I’ll be trying is a drawing board or table cloth clip (it has to be thin and flat on the bottom); but in any event, it’s vital that one of the keyboards outputs the usual numbers and the other one outputs the numbers with the Shift key down.

Turning to the software, the two difficulties would be a) getting the program to distinguish the numbers received by one keyboard from the other, and b) getting it to output the appropriate MIDI note numbers.

The entire program looks like this:

The function called ‘key’ in the top left receives the numbers from the keyboards.  It neither knows nor cares whether these numbers are coming from one keyboard or two.  The function ‘keyname’ is just there for the sake of interest – originally for the sake of testing! – and doesn’t actually contribute to the working of the program (or ‘patch’, as they call it in Pure Data).

The number from the keypress is passed to a very complicated sifting system underneath, the purpose of which is to divide the numbers coming from the red keyboard from the numbers coming from the blue keyboard.

Unfortunately, as I said in the previous post referred to above, there is no simple way of distinguishing the ASCII numbers – they’re pretty random, it seems.  I’ve used a function called ‘moses’.  Like Moses, who parted the Red Sea, this function parts the stream of numbers coming into it: you put a number in the box and it sends this number and any higher numbers out of one output and all the lower numbers out of the other output.  In this way I was able eventually to divide the numbers and send them in the right direction.

In the middle part of the program you can see the two separate streams of note numbers moving from top to bottom; the settings on the right-hand side of the program allocate MIDI channel, velocity, duration and octave information.  At the bottom, the Pure Data functions ‘makenote’ and ‘noteout’ convert all these details to the kind of MIDI signal understood by a synth.  You just need to tell the program where exactly to send these MIDI signals in the program ‘Preferences’.

That just leaves one question: how does the program know how to convert the incoming ASCII numbers to the correct MIDI note numbers?  The answer is in a similar way to MIDI Integrator in the previous post: by means of a pre-written text file.  In the bottom right of the program, there is a list (very incomplete at the moment as it only contains ‘Wicki-Hayden’, ‘Janko’ and ‘System C’, and only ‘Wicki-Hayden’ has so far been implemented!) of layouts which can be used.

When you select the ‘Wicki-Hayden’ option, the instruction at the bottom gets the program to read the text file ‘wicki.txt’ into a table (or array) called ‘notes’; the function ‘tabread notes’ in the middle of the program uses the information in this table to convert the ASCII numbers it receives into the MIDI note numbers you want it to output.

The format of this text file is quite different from the text file in MIDI Integrator.  It looks like this:

On the face of it, pretty meaningless!  The way it works is this: the table is 128 numbers long.  This is because there are 128 possible MIDI note numbers, and why it says in the instructions at the top of the program, in the middle, ‘Open ‘table notes’.  Set array size to 128′.  The button for opening ‘table notes’ is right down near the bottom of the left-hand side of the program window, not right next to this instruction, as you would think it should be.  Don’t ask me why.

So the table is 128 numbers long, and what the program is doing when it receives a number is this: if it receives the number 60, it outputs the number at position 60 in the table; if it receives the number 113, it outputs the number at position 113, and so on.

This is more complicated than the method for MIDI Integrator, but can nevertheless be achieved with a little patience and the correct data to hand.  Here’s what I did:

First of all, as before, I filled out the spreadsheets showing the layout of the keys, the ASCII numbers and the MIDI note numbers (see https://andymurkin.wordpress.com/2012/01/01/alternative-keyboards-3/).  In fact, the sheet for the red keyboard was the same as the one I used in MIDI Integrator, it was the new sheet for the blue keyboard that was different.  To fill this in, I had to change the MIDI note numbers and the ASCII numbers.

In fact, I could have left the MIDI note numbers the same as the red keyboard, but I thought it would be more practical to have them an octave lower, so I entered all the MIDI numbers with 12 deducted from each one – that’s all it takes to lower the notes by one octave.

The ASCII codes had to be changed because the blue keyboard would output the number of the Shifted keys – i.e. ‘Q’ instead of ‘q’, ‘%’ instead of ‘5’, etc.  I used this chart to change the numbers on the spreadsheet:

[Edit: to be clear, this is a list of all the MIDI notes and standard ASCII codes from 0-127.

In the chart below, Column 1 shows the names of all the 128 MIDI notes available, from the lowest to the highest; Column 2 shows the MIDI number associated with each of these notes – these are also the ASCII numbers which my Pure Data patch uses; Column 3 shows the key that produces this ASCII number; and Column 4 gives a description of which key this is].

[Edit: In fact, on UK keyboards the symbols ” (‘Quotes’) and @ (‘At’) are reversed, so ” = 64 and @ = 34]

The one obstacle I came up against was the F keys, which don’t have an alternative number when used with the Shift key.  This meant that the blue keyboard was restricted to 4 rows – but as this is more than 40 notes, it wasn’t too much of a limitation.

[Edit: looking at the chart above,  you can see that the F keys don’t have an ASCII number in any case, so neither of the keyboards can use this row of keys with the Pure data patch, even though the single keyboard could with the program MIDI Generator (see ‘Alternative Keyboards 3‘), based on Max/MSP, which uses a different, non-ASCII system.  This problem may be overcome with some keyboard remapping.

Edit 2: I’ve now used KeyRemap4Mac – now called Karabiner – to remap F1 – F8 as 0 – 7; I couldn’t find a way of remapping F9 and above].

Here’s how I created the text file:

First of all, the first position in a 128-position table is 0, and the last one is 127.  So I opened a blank text document and wrote a column of numbers down the left-hand side from 0 to 127.  These are the ASCII key numbers.  I then went through the two spreadsheets and for each key I needed to use I wrote down the MIDI number against its ASCII number in the text document.  When I finished, I put ‘0’ against every unused ASCII number in the list.

When I had a list of 128 numbers – many of which were now 0 – I removed all the ASCII numbers in the left-hand column, left one space between each remaining MIDI note number, and saved the text file as ‘wicki.txt’.  This file is now read at any time when ‘Wicki-Hayden’ is selected as the layout in the program, and the values don’t need to be entered again.

The patch and the text file are here: Double Keyboard patch; Wicki-Hayden layout text file.

See also this post: ‘Alternative Keyboards 5 – Postscript‘ for a little extra info on the Cherry Double Keyboard.

Alternative Keyboards 3

In my last post (‘Alternative Keyboards 2‘) I described choosing a suitable QWERTY keyboard as a 2-dimensional ‘isomorphic’ musical keyboard.  In this post I talk about the software I used to interpret the key presses and output MIDI information to the synthesizer (virtual synthesizer, in my case).

The first thing to appreciate is that every key press on a computer keyboard sends a number (its ‘ASCII’ code) to the computer via USB.  Every key has a different number, and the number sent out by the key is different when the Shift key is pressed at the same time.  Knowing this, and knowing which key sends which number means you can tell the computer to do a certain thing with each number it receives – for example to output a MIDI note number.

When you use a MIDI music keyboard the relationship between the number it sends and what you want done with it is very simple: press the note C in the middle of the keyboard, and it will send out the number ‘60’.  MIDI synths recognise 60 as the number for C, and C will be sounded; press C#, the number 61 will be sent, and C# will be sounded; and so on.  Unfortunately, this isn’t the case with the computer keyboard – the numbers sent out by the keys bear no relationship whatsoever to where on the keyboard they are: The ASCII code for Q, expressed as an ordinary decimal number, is 113; W, right next to it, is 119; E is 101, and so on and so forth.

So, in terms of software, if you’re using a QWERTY keyboard, as I was, you’re looking for a program that a) recognises ASCII codes input from a keyboard, and b) has a means of you telling it to do something unique with each different number it receives.  In this application the unique action would simply be to output a specific MIDI note number for every specific key number received.

Having read about Ken Rushton (‘MusicScienceGuy’)’s instrument, the Jammer, at www.altkeyboards.com (and his blog at www.musicscienceguy.com), I decided to use the program MIDI Integrator he had devised to operate it.  MIDI Integrator is described, and can be downloaded here: www.altkeyboards.com/integrator.  It’s free, and works on Macs and Windows PCs.  It’s an application based on MAX/MSP, and I had downloaded and installed the free version of this, ‘Max Runtime’ from http://cycling74.com/downloads/.

MIDI Integrator was designed to be used with the Jammer – and is potentially very useful because of that, as the Jammer has 2 separate MIDI keyboards; but inputs for MIDI keyboards weren’t useful for this application, as the QWERTY keyboard doesn’t output MIDI information.  However, there is another feature of the program that would do the trick.

Setting this up was quite an involved process, but consisted of just a small number of important steps.  Most importantly, when done once, most of these things didn’t have to be done again!

When you open MIDI Integrator, the interface you see looks like this:

All the boxes with a ‘p’ at the beginning are boxes which can be clicked to enter information.  There are lots of boxes here, but I only needed to look at two of them.

What I had to do is ‘map’ the keys of the QWERTY keyboard – i.e. match them to MIDI notes – in the top half of the screen, and route the output to a virtual MIDI instrument in the bottom half – which involved telling the program where to send the MIDI signals to operate a synthesiser or sound module.

So, I began by clicking the box marked ‘p mapPCKeys’.

When I did this, it brought up the window for the QWERTY keyboard, which looks like this:

What this tells you is that the mapping instructions used by MIDI Integrator are in a text file called ‘MidInt PcKeys v1.txt’.  What I had to do is replace the text file ‘MidInt PcKeys v1.txt’ with one of my own, with my choice of notes.

To do this, I clicked on the third button ‘coll MidInt PcKeys v1.txt ‘, under the text ‘Click below to edit mapping table’.  This opened the text file, which looked (in part) like this:

You can see from this example that each line has 5 elements, like this:

56 #8, L N 76.  This is interpreted as follows:

56 is the number (usually ASCII) sent out by the key;
#8 is which key that is (in this case, the number 8 on the second row down of the keyboard);
L is the virtual MIDI instrument in MIDI Integrator to which the information is sent (L, R, Lx and Rx are the choices MIDI Integrator gives us; it doesn’t matter which one you use if there’s only in use at any one time);
N means ‘note’ information is what’s being sent;
76 is the MIDI note number.

So all I had to do was identify the keys on the keyboard I wanted to play notes on, find out the ASCII number of each one, and write a line of code for it like the one above.

The problem is matching the right key number on the left-hand end with the right MIDI note number on the right-hand end, and the MIDI Integrator website made this easy, by providing a chart (an Excel spreadsheet), laid out in the same way as the QWERTY keyboard for me to write this information in.  It already had the key numbers in it, all I had to do was write the MIDI note numbers in next to each key.

Not all of the keys on the keyboard have code numbers that can be used, but it’s only a small number round the edge that won’t work.  I experimented to check exactly which ones could be used, and labelled them or didn’t label them in the spreadsheet, as appropriate.

This chart shows which codes MAX/MSP allocates to which key, mostly based on their ASCII codes:

I made this diagram to show the 5-row note layout for the ‘Wicki-Hayden’ keyboard:

and this one to for the ‘Janko’ keyboard:

I figured that I might as well create several different text files for MIDI Integrator while I was at it, and try out some different layouts.

So I had the keyboard layout spreadsheet and the pattern of notes for my layout (I started with the Wicki-Hayden).  The final piece of information I needed was what MIDI note numbers corresponded to the notes in my layout diagram.

This chart shows the MIDI numbers which correspond with all the notes from C0 (the lowest) to G9 (the highest).  C4 is ‘middle C’.

For mathematical reasons, 128 notes are available in MIDI and for mathematical reasons they are numbered 0 – 127, not 1 – 128.

Once armed with this information, I filled in the spreadsheet, went back to the text file ‘MidInt PcKeys v1.txt’, filled in my own numbers and saved it as ‘MidInt PcKeys AM Wicki.txt’ in the same folder as ‘MidInt PcKeys v1.txt’.

The file began like this:

(Large numbers like -999 are used for comments, and are not interpreted as instructions).

It doesn’t matter what order you put the notes in, so I started in the top left of my spreadsheet, so you can see the line of codes representing the F keys, followed by the line of codes representing the number keys.  The file just continues until the end of the bottom line (the one beginning ` Z X C V . . .).

There are other things you can specify in the file – for example, you can map some keys to MIDI control messages, and MIDI Integrator has some of its own commands.  I ended the list with the following:

-2 space, R C SUS;
-15 Home, R C OCT 2;
-13 Pg Up, R C OCT 1;
-14 Pg Dn, R C OCT 0;
-16 End, R C OCT -1;
-12 >, R C OCT -2;
5 Ins, R C KEY -1;
-6 Del, R C KEY 0;
-11 <, R C KEY 1;

Instead of ‘N’ for note as the 4th character, ‘C’ is for control.  MIDI Integrator’s command ‘OCT’ changes the octave of the keyed note up or down by the amount shown, and the command ‘KEY’ changes the keyed note up or down by one semitone.

Now my note instructions are permanently preserved in the text file and never have to be input again.  Whenever I open MIDI Integrator, I can click on the box ‘p mapPCKeys’,

and in the box that opens up, click on ‘read’ next to the text ‘Click to change mapping table’,

This brings up a typical ‘Open file’ dialogue box in which I can select ‘MidInt PcKeys AM Wicki.txt’, which immediately maps all the keys of the QWERTY keyboard to the Wicki-Hayden layout (or the Janko layout if I choose ‘MidInt PcKeys AM Janko.txt’, or any other layout for which I’ve created a text file).

The layout files I’ve so far created can be downloaded here: Harmonic; Janko; Wicki-Hayden.  (Click ‘Save Link As’).

There are a few other things to do to get MIDI Integrator working – for example, the keyboard volume can be set via the slider on the right-hand side – but these are all explained in the detailed MIDI Integrator Manual, available along with the program, the spreadsheet and other things at www.altkeyboards.com/file-cabinet.

The main thing is to select the instrument routing.  This is done by clicking the box ‘p Instrument_L’, ‘p Instrument_R’ – or whichever one you’ve chosen on the lines of the text file – at the bottom of the main screen:

The boxes on the left-hand side, especially ‘noteout l’ (or ‘noteout r’, etc., for the other instruments) are important.

A QWERTY keyboard isn’t quite as good as the AXiS or the Jammer, of course, but it’s a pretty cheap way of getting to know isomorphic keyboards and alternative keyboard layouts.

[Next post in the series: ‘Alternative Keyboards 4‘]