Well, no longer so. I’ve written a small command-line utility which connects a MIDI device to a serial port. Furthermore it lets you connect using non-standard serial speeds such as the MIDI standard of 31250 baud.

MidiSerial v1
usage:
-p FILE set serial device
-s NUM set serial speed
-v print messages sent/received over serial
-l list MIDI input/output devices
-i NUM set MIDI input device
-o NUM set MIDI output device
-c NAME create MIDI input/output device
-h or --help print this usage information


This is actually extremely useful for MIDI DIY-ing. If you wire up a DIN plug to the Arduino you’ve got an instant MIDI out port (see for example Todbot’s Spooky project), but since MIDI runs on 31250 baud you are out of luck with USB – most applications, including the Arduino IDE and Processing, only accept standard serial speeds, and MIDI applications still don’t do serial.

The utility is written using POSIX termios for serial comms, and the cross-platform JUCE library for MIDI, and should compile on Linux and Windows as well as Mac OS X. I’ll try to make a Linux build available soon. It should work fine with any serial connection, not just Arduinos.

Ah, so while writing this I’ve made the inevitable discovery that someone’s beaten me to it – in fact there seem to be several utilities doing pretty much the same thing listed at arduino.cc. Well there doesn’t seem to be a Mac version around so maybe there’s room for another.

Another discovery I’ve just made is that cvs.pingdynasty.com is, um, not showing up the project, or anything else for that matter. I’d better get on that, then. In the meantime, get the source code from here, and a Mac OS X 10.6 i386 binary here.

The previous design that we tried used a MIC5891 serial-input latched source driver. This seemed perfect on paper, but turned out not to work at all with 5v USB power because the IC drops too much voltage to drive the LEDs. Dang! And having at least the option to power by USB only is something we don’t want to sacrifice.

The new design by contrast uses discrete transistors to drive the LEDs, which are multiplexed by the microcontroller. This design can take a separate, higher input voltage, but also works fine with 5v. At least it does on the breadboard, we’ll have to wait and see how the PCB behaves!

Delivery is due in early March, news to follow shortly thereafter.

This means that BlipBoxes will not be available for sale for yet a bit more time, so apologies, again, to those of you waiting.

We don’t want to offer up a device that is not completely reliable, but rather take the time to fix the problem properly.

The good news is that we are already testing a new circuit which includes the MIC5891 source driver. This can drive the LED’s with up to 500mA, which is more than enough for our purposes. In fact, it should be more than enough even for a superbright blue LED version in the future.

Prototype PCB’s are currently on order, we expect to have them fully tested within the week. More news to follow.

Sometimes an idea just gets hold of you, with no regard to how crazy it really is. It keeps churning away in the back of your mind until eventually you say alright, let’s just whip out the soldering iron and do it.

Cheers Jim!

an open source programming language and environment for people who want to program images, animation, and interactions.

This was such an excellent idea that we simply had to do it. And now the beta version of the BlipBox Processing (or p5 if you prefer) library is ready!

Here’s an example of a very simple Processing sketch that talks two-ways with a BlipBox:

ProcessingBlipBox blipbox;
int x = 0;
int y = 0;
int value = 255;

void setup(){
  blipbox = new ProcessingBlipBox(this);
}

void draw(){
  blipbox.setLed(x, y, value);
  if(++x == 10){
    x = 0;
    if(++y == 8 )
      y = 0;
  }
  if(blipbox.isScreenPressed())
    value = blipbox.getX(0, 255);
    // scales X position to 0-255 range
  delay(20);
}

For this to work, the blipbox.jar library has to be added to the sketch using the PDE (Processing Development Environment).

What the sketch does is the following:
It iterates over all LEDs by column and row, setting them to an initial value of 255 (maximum luminosity).
If at any point the touch screen is pressed, then the value is changed to reflect the horizontal position of the touch.

The library code is currently in CVS and will be part of the first BlipBox public release, so that everyone can sketch with the ‘box!

Updated: here’s a silly little video to show y’all it’s for real:

So guess what? The new board works just fine. Without modifications.

To my embarrassment I didn’t much consider that there could be some freak component or connection problem with the first board I soldered up. But that’s exactly what seems to be the case. One lives and one learns. Then one forgets.

The upshot of this all is that
1) I’ve rewritten, optimised and generally improved almost every part of the firmware trying to fix this problem.
2) I am reluctant to send out kits until I figure out what caused the flicker in the first place. Any ideas?

In the meantime I will build a couple of units and put up for sale. Enclosures shall be ordered, but won’t arrive for some 3-5 weeks. Watch this space.

And with that, a sincere thank you for continued support and patience!