Now that the box is all wired up, it's time to actually write the software. One might think "Oh, the hardware is done now and we don't have to touch it again!"

But, if you thought that, you'd be wrong.

Like me.

No, this is where we actually find out if the hardware is working. Of course, tests were done, but when faced with software trying to do real things, it might turn out a little differently. For example, yesterday I wrote about how the Arduino A/D converters were only accurate to within +/- 4 and we were basically losing the bottom 2 or 3 bits of resolution from our 10 bits giving us maybe 8 bits with smoothing.

Today, the MIDI ports are the ones being stressed. The intention is that a MIDI keyboard can be played into Twister, and the results routed between all of the output ports, with the control data from the knobs added as necessary.

Although input is showing ok, output seems to be prone to dropping bytes here and there giving us fairly regular stuck notes when I try to play through it.

Whatever could cause this?

Is it a problem with the hardware or the software?

Time to debug.

For those of you unfamiliar with the process, debugging generally follows the scientific method:

1. Form a hypothesis of what might cause the problem.
2. Perform an experiment to see if that is actually the problem.
3. Observe results: Yes, that was the bug. No, it must be something else.

So, let's try a few:

Hypothesis 1: Problem is input
Experiment: Print the input to the console and see if it is losing any note off commands.
Result: No, all the note on and note off commands could be seen in the console.

Hypothesis 2: Problem is that Arduino is slowed down by printing output.
Experiment: Remove debug printing of MIDI input commands and see if it works better.
Result: No. Results were better, but it was still possible to get a stuck note.

Hypothesis 3: Power supply is insufficient
Experiment: Attach a 1 amp power supply to the Arduino instead of relying on USB power.
Result: No change, still get stuck notes.

Hypothesis 4: The target synth is to blame
Experiment: Grab another synth and see if it is better.
Result: Promising. Certainly fewer stuck notes on the Casio than on the breadboard prototype of the NanoEgg synth. The Casio does occasionally seem to trigger a low bass note that has no relation to what is being played, tho.

Hypothesis 5: This MIDI cable is crap.
Experiment: Try another MIDI cable.
Result: Promising. The Casio almost never gets a stuck note now, but the NanoEgg prototype still sticks all over the place!

Hypothesis 6: USB power from PC hub is insufficient on the NanoEgg prototype.
Experiment: Try using an external USB power source.
Result: No change. Not the problem.

Hypothesis 7: Knob reading code makes it slow.
Experiment: "Comment-out" (temporarily remove) knob reading code.
Result: No change. Not the problem.

Hmmm.

So some improvements have been made, but it still is rubbish at sending MIDI through to the NanoEgg prototype, which is kind of the point of this project. Certainly, the breadboarded prototype of the NanoEgg is going to be more susceptible to electrical noise, but it seems rock solid when played directly from my MIDI controller, so I feel like something else is going on. Is the MIDI out circuitry on the Arduino not as robust as it should be? (It's just two resistors attached to the connector, one to 5V, and one to TX, with a capacitor between 5V and ground.) Or is there electrical noise on the line inside the ratsnest of wires inside of the Twister box?

This seems like a good point to take a break and consult with some other folks to see if anybody has any ideas.

Edit: I came back to it after a bit and noticed something strange. Controls I didn't wire up, like the pitch wheel, are working. So I commented out all the code that is supposed to echo MIDI to the output, and MIDI is still appearing at the output. But only if I call midi.read(). So that means the connections aren't somehow bridged, but that the MIDI library is echoing on it's own?
I'm very confused.

The Arduino MIDI library by Forty Seven Effects Francois Best is a well-written library, but I have to admit that because it makes such use of C++ (vs. straight C) features, I have a difficult time following it. Anytime we get into templates and inheritance, I find myself scrambling trying to find the code that it is referring to and trying to decipher where to find the functions that actually do the work.

I finally found something interesting. The library already has a MIDI thru mode enabled by default, so it has been sending every MIDI command, and then I have been sending it. That might explain our strange behavior! So I found the function to turn it off: turnThruOff .

Now... well now it sends no note data at all, even when I tell it to. That is... not the situation that I desired...

More debugging tomorrow, I guess.