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.