Practical Usage

In a previous post, I defined a simple date structure to help in the transfer of the commands sent to/from a pedal board. In this post, I will complete the definition of the data structure and define the physical layer supporting the structure.

Understanding MIDI

“What MIDI Is (from midi.org)
MIDI, which stands for “Musical Instrument Digital Interface,” is a system that allows electronic musical instruments and computers to send instructions to each other.”

The Midi Manufacturer’s association (midi.org) has a nice little booklet about Midi.

Most musicians know about Midi, and many, many, use Midi continuously. I want these musicians to be able to use my pedal boards. I think that my pedal boards should be completely “Midi Obedient”. But, I think that there is a weak spot in Midi. The physical layer. I have not used a piece of Midi equipment that can convey the “what physical control is that command associated with” part. Basically, I think that a Midi commands should be able to transmit a reference to a physical control when necessary.

For example: I have a pedal board with 12 switches. Each one can send one or more commands to software running on a computer. That’s Midi. But I would also like to transfer the switch identifier itself. Midi does not have an easy way to do this. I can use un-reserved Control Change (CC) commands or System Exclusive (SysEx) calls, but the data exchange then quickly becomes complicated. This is what is used today to program the FCB1010 from a computer. Mac and PC versions of programs have been developed by people (who do not work for Behringer) who were tired of trying to program the FCB1010 directly on the board. These programs use SysEx sequences to alter the FCB1010 data. You have to use these programs because SysEx files are hexadecimal, so an interface has to be used to present data to the user and then send it to the Midi device.

If I stick to Midi to program, I have to use SysEx sequences to send programming information. But since I’m using a computer on both sides, why not use something easier?

The Structure Support

The goal is to be able to exchange information between a user (musician), equipment, and computers. The computer part is quite limitless. Using an existing database software, like MySQL, I could easily define tables, databases and all the programs necessary to handle any type of data exchange and storage. On the equipment side, none, that I know of, understand database query languages. On the musician/user, side, some understand databases, some can even program access routines, and some might be comfortable modifying a database content.

But it is all too complex.

That is why, partly, Midi was invented. A “simple” way to exchange information between users and equipment (including computers). Sending and receiving Midi commands is the hardware part of this project. I will try to use standard Midi most of the time, but will need to use fancier stuff too. Actually, “fancier stuff” might end up being easier to use!

My idea is to use simple text files, or CSV files, to exchange data. If you have read the previous post, the conclusion obviously point in that direction. Each “command” is made of a sequence number, effect, switch combination

As a CSV file, this might look like

111,A,1
111,B,1
112,C,2
112,D,2
121,E,3

Although this notation is easy to understand, what will need to happen is a translation to Midi format. Also, it would be easier, I think, to have the physical reference (switch number in this case) second. Our file might actually look like this:

111,1,7,25
111,1,22,0
112,2,7,45
112,2,23,0
121,3,7,90
121,3,24,0

Trust me, this is a lot easier to read than SysEx data!

Here, we have seq number, switch  number, CC command, CC value. So the first line reads: seq number 111, switch 1, CC command 7 (Volume control), volume level 25 (very soft).

This becomes a very easy way to program a pedal board. No fancy interface, just a general knowledge of Midi commands and a CSV editor. If you are reading this post from a computer, any computer, you already have a CSV editor or two. A CSV file is just a simple text file. Oh! wait! A CSV file can also be read an saved from … a spreadsheet program! Chances are that you already have a spreadsheet program on your computer: Excel on the PC, Numbers on the Mac, Open Office Calc on Linux (free). The iPad also has Numbers and many others.

How do we send this to the pedal board computer? This is where the programming comes in. On the main computer side, I use Processing. A simple program reads a CSV file and sends it to the pedal board. The Arduino then stores the commands in EEPROM, its permanent memory.

This is the main code in Processing:

void setup() {
  // Just show an empty square
  size(10, 10);
  background(0);
  stroke(255);
  frameRate(12);

  String [] lines = loadStrings("testdata.txt");// read the file in the current sketch directory
  println("there are "+ lines.length + " lines");
  for (int i=0;i<lines.length;i++) {  // Read each line and process it
    String[] pieces = split(lines[i], ',');  // Cut the line in pieces
    for (int j=0;j<pieces.length;j++) {  //
      print(pieces[j] + " ");  // Do something with the pieces
    }
    //println(lines[i]);
  }
}

Of course, instead of print(pieces…) the final code uses port.write to send the data to the serial port, to the pedal board. With this code, the file can be any number of lines and each line can have a variable number of parameters.

On the pedal board side, the micro-controller has to wait for data to appear on the serial port. Once data is received, it has to be put into a memory “spot” associated with a switch.

The fcb1010 has a numerical display made of 3 digits. It also utilizes a series of LEDs to give more info about its current state. At best, this is an arcane way of doing things, like trying to program a computer using a old rotary telephone. At its worst, it does make you hate the FCB1010.

I will be writing a Mac/PC/Linux interface as I go along, but certain functions are better accomplished on the device itself (very few!)

During prototyping, I will be using an alphanumeric display, made of 2 lines by 16 characters each. I’m debating whether to add a numerical display, either a simple one similar to the one used now on the FCB1010, or a useful one like the one below. Adding the display is trivial, but expensive.

This display, form an old Digitech GNX3000, is ideal: 8 alpha-numeric 14-segments digits and 2 contrasting numerical digits. The entire display can be run from a single chip… but that chip costs 20$, in quantities of 25! Add 15$ for the set of digits…

Driving a 3 digit display, directly from the Arduino using a serial interface and one digital pin can be done for 13$.