Archive for the 'Alternative Keyboards' Category


The Chessboard Keyboard

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

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

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

Chessboard keys 5a

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

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

Chessboard keys 5b

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

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

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

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


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

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:  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  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 (and his blog at, I decided to use the program MIDI Integrator he had devised to operate it.  MIDI Integrator is described, and can be downloaded here:  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

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

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.


Alternative Keyboards 2

My first alternative keyboard project was to create a MIDI controller in the form of an isomorphic keyboard, as described in my previous post.

This project came in in two halves, Hardware on the one hand, and Software on the other.  This was a bit of a chicken-and-egg situation – I needed hardware with the type of output that could be interpreted by one of my software programs; but I needed a software program that could deal adequately with the type of output the hardware – a two-dimensional key layout – would produce.

This post is about the hardware (a QWERTY keyboard).

The hardware requirement was for an input keyboard capable of playing about 40 – 50 notes, like the AXiS pictured in my previous post – the keys would be in 4 or 5 rows and the rows would have to be offset, to make it easy to press keys on more than one row at the same time, and to allow diagonal movements for melodies and arpeggios.

Apart from the physical appearance, I was looking for something simple and inexpensive – i.e. I could construct it without advanced carpentry, metal work and electronic skills, or buy it off eBay.

The third requirement was that it should connect easily to the computer.

I bought and tested some tiny ‘tactile’ switches (cheap in bulk from China), but hadn’t at that time resolved the problem of how to get the computer to understand their output; so I put them away for future use.

In fact, my conclusion was that what I needed would look very much like a computer keyboard, with rows of offset buttons, so I looked around and identified what I thought would be the most suitable.  The model I chose was the Cherry G84-4100.

The reasons I chose it were a) it’s quite small and light (282 x 132mm, and 500g), but the keys are a reasonable size, b) it’s flat, making it easier to play as a music keyboard, c) it has 5 rows of equal-size keys (the top row, the F keys, are a smaller size than the others on the majority of keyboards), and d) there were quite a few available for about £15 new, £5 second-hand, on the internet.  (The full price seems to be about £50, but there’s no need to pay that much, there always seem to be some for sale at a lot less).

There are several different models of G84-4100, but I don’t think the differences between them are significant, except for one thing: seeing the PS2 adapter in the picture reminds me that although most versions are USB, some versions have PS2 conectors.

USB is the ideal connection method: modern computers all use it, and music programs understand it; but if you want to do this and happen to get hold of a keyboard – or any other input device, for that matter – with a PS2 to USB connector, it can be converted.  Not necessarily with a simple adapter like the one in the picture, however, which just physically changes the plug: these can’t be guaranteed to work, and you’ll probably need the kind of converter with some circuitry in it, and some of these work better than others.

I’ll be discussing interfacing ‘HID’s (‘Human Interface Devices’ – i.e. keyboards, mice, joysticks and so on) in more detail in later posts, but if this happens to be an issue for you at the moment, this: is the best discussion on the internet of the alternatives.

[Edit: this link seems to be dead now, but there are lots of discussions of this topic on that forum].

I use this one, the so-called ‘Blue Cube’.  It can be found at a reasonable price on eBay, but try and avoid PS2 if your computer doesn’t have a PS2 socket, as a decent converter like this one may cost as much as the keyboard.

[Edit: a more recent post on the geekhack forum recommends this type of connector, rather than the Blue Cube:


It’s said to be much cheaper, but doesn’t always work on Macs.  The Blue Cube seems to work fine on all my Macs].

So, I got the keyboard.  Any keyboard will do, if you’re doing this, so you could just as well use any type – including the one that came with your computer, obviously.  I wanted a separate one because it would be more convenient than the laptop (and had the full-size 5th row of keys), it would look better, and could be customised, if required.

In my case, I customised it by prising the keys off and painting them red, as I found the letters and numbers distracting.  (I should mention at this point that I didn’t do this until I had sorted out the software set-up, which I’ll describe in my next post: it was helpful to know which key was which during the process of getting the computer program to interpret the keys in the way I wanted!)

The keys on this particular model are Cherry ML (not their more well-known MX type, but more suitable for this application, being flatter in profile).  Replacement keyboard caps are available (from, but I wouldn’t bother with those unless you break or lose a large number of the originals, as they’re pretty expensive!

You can also get a special tool for getting the keycaps off gently, but you don’t need it if you’re careful, or don’t want to get the keycaps off at all – and it’s also unnecessarily expensive.  I wanted to take the caps off not just to paint them, but to clean the keyboard, as it was second-hand.  The can of paint was only £1 from the Poundshop, so wasn’t a major expense.

If you do want to take the keycaps off, the best thing is to use two small screwdrivers or similar tools, one under each side, to lever them off with equal pressure on each side.  They just pop off and press back in place, and unlike many keyboards, nearly all of them are identical.  There are a few that are slightly bigger or smaller, and it’s generally obvious which ones; there are also a few – for example the space bar – which also have a little metal bar which you have to put in place before pressing the keycap back on.

At this point I had the keyboard I needed – not quite as nice as the AXiS, I know, but I was sure it would work in much the same way.  Next I needed to pick the software to use it with.  This will be the subject of my next post.


Alternative Keyboards 1

I’m not sure exactly which department this topic should go in, but I’ve added ‘Software/MIDI’ as the advent of these two things has made the possibility of using alternative keyboard layouts very much a practical proposition. I’ve been experimenting with these and come up with some relatively low-cost ways of trying them out.

The purpose of this post is to explain what ‘alternative keyboard layouts’ are – as opposed to ‘alternative methods of controlling synths’ or ‘alternative methods of generating musical notes’, which I deal with elsewhere in the blog. Although there’s undoubtedly an overlap between these things, I’d like to talk here about some specific proposals that have been made over the years to improve the traditional piano/organ keyboard – certainly appealing to those who are non-players of the instruments, but also with a specific appeal to trained keyboard players and those with a keen interest in music theory.

I’ll get into the music theory aspect, insofar as I understand it myself, later; and follow-up posts here will describe the different ways I’ve tried putting alternative keyboard layout ideas into practice.

To begin at the beginning, the conventional piano keyboard, with its line of large white keys interrupted by thin black keys, although a familiar and iconic design, isn’t necessarily the easiest way to play or learn to play music: you have to hold your arms at an odd, straight-on angle to the keyboard; it’s a long stretch from one note to the next octave up or down; you have to move your hands to different positions to play chords in different keys, and so on. Ultimately we might also consider how difficult it makes things if you want to play music using divisions of the musical scale which are different from the 12-note one we in the West are used to.

It was a long time ago, certainly as early as the 19th century, when people began to think of replacing the one-dimensional line of keys found on pianos and organs with a two-dimensional bank of keys, like the bank of keys on a typewriter (or this computer keyboard I’m using now).

It was quickly realised that there would be more than one advantage to this arrangement: notes could be repeated in several places on different rows, allowing the player to find the easiest way to play a particular passage (players of stringed instruments are used to this and wouldn’t want to be without it!); notes which are far apart on the conventional keyboard could be placed closer together, enabling even those with small hands to play chords or melodic passages with large intervals; and, most importantly of all, the keys could be distributed in such a way that the pattern of a particular chord would be exactly the same, no matter which key it was played in, and the pattern of a melodic passage would be the same, no matter which note it started on.

It is this latter feature which leads to the name often given as a description of this type of keyboard – ‘isomorphic’. Well-known isomorphic keyboard layouts were invented by Paul von Jankó and Kaspar Wicki in the 19th Century, and in the 20th Century, Brian Hayden independently developed a system similar to Wicki’s, which one often sees described as the Wicki-Hayden system.

This is a picture of a piano with a Janko keyboard layout. As you can see, there are still white notes and black notes, but not in the same pattern as on a conventional piano, and there are 6 rows of keys:

[Photograph of piano with Janko keyboard at the Musikinstrumenten-Museum, Berlin by Morn the Gorn (Own work) [CC-BY-SA-3.0 ( or GFDL (], via Wikimedia Commons’]

This diagram of the Wicki-Hayden layout shows how the notes are placed in relation to one another. The keys themselves may be buttons, as they are on a concertina or accordion (Brian Hayden was a concertina player), but the hexagonal pattern used here emphasizes the importance of diagonal relationships between the notes, and relates to the method often used in modern electronic instruments of using hexagonal keys set out in exactly this way.

[Diagram of the Wicki-Hayden note layout used on some button accordions and some isomorphic button-field MIDI instruments by Waltztime (Own work) [Public domain], via Wikimedia Commons‘]

You can read about the Janko, the Wicki-Hayden, and a number of other isomorphic keyboard systems in the Wikipedia at:

Each of these pages contains numerous links to external sites, if you’d like to know more. I’ll be dealing with some of the issues that follow on from this, such as microtonality (as mentioned above, these two-dimensional layouts also lend themselves more readily to musical scales of more or less than 12 notes) and dynamic tonality in future posts.

You should also check out this site: which is also the home of the program MIDI Integrator, which I have used, and an interesting modern-day electronic instrument using an isometric keyboard (two, in fact) called the Jammer.

The Jammer, in turn, is a development along similar lines of an instrument called the Thummer – which almost reached the point of commercial production – and uses a keyboard called the AxiS-49, which is commercially available (from C-Thru Music at A larger version of this keyboard, the AxiS-64 is also produced:

All of these instruments these days are MIDI controllers, and YouTube is probably the best place to see them in action. This lengthy introduction to the AxiS-64 also serves as an illustration of many of the reasons why isomorphic keyboards were invented: You can also see the Thummer and the Jammer

There are hundreds more videos of these instruments and others, including a nice-looking Japanese synth called the Chromatone, which appears to be completely self-contained:

The next post in this department will be on methods of creating simple isomorphic keyboards, and the hardware and software I’ve used to create mine.


August 2017
« Jun    

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