Duck!

My third "Duck" show in a row.  So I brought in my Wireless Easy Button, and they wanted it in the show.  It was fairly easy to cram the XBee into the prop remote (soldering to the board to pick up switch traces was less easy, and the 1-watt Luxeon I put in the front is not nearly as bright as a hoped -- that's the flaw in running it on barely more volts than the voltage drop!)

However.  Instead of using one of my computers, they are using the Stage Manager's computer for sound cue playback.  And that means they are using the free version of QLab -- without the money to pay for the MIDI license.

Fortunately, although the java classes for MIDI are basically screwed on Mac OS and will be for the foreseeable future (heck...it isn't as if java itself has a future on the Mac, with all the effort Apple has been making to have everyone dump cross-platform development platforms and write exclusively on Cocoa)...anyhow, although MIDI is a pain, basic sound file playback isn't bad.  So over the Fourth of July, I sat home and wrote and compiled a stand-alone, double-clickable ap that looks for a serial-over-USB, and when it detects activity at the serial port it plays the sound sample out the default Core Audio device.

It took me a chunk of today to figure out the other trick; when transporting it to a different OS/platform, bring the entire sketchbook folder and open Processing and re-compile from inside that folder.  Between Processing and the Mac OS, I was getting a lot of cryptic error messages instead of a simple "library not found" or "wrong library" and this solved the issue because saving out the entire project this way compiles a copy of ALL of the libraries in your #includes.

And here it is on my not-quite-as-ancient G5:

 

The rubber duck is providing a housing for a XBee Explorer USB, which links the receiving XBee node to the laptop's USB port.  The app window is displaying the selected port and flashes green when the XBee receives a signal.  The hacked remote is under the duck.

The app is total cludge code, of course.  Among other things, I'm not even trying to parse the serial message from the XBee (my mistake on a previous implementation).  Instead I'm simply detecting if ANY serial message is present, and then as soon as I've confirmed that, I wipe the serial buffer! 

(Should have thought of that trick long ago.)



And that's all I have time for.  I have some six minutes of music to compose before the weekend, and I need to learn how to run my new shareware software synthesizer to do it!

Somewhere West of Java

So the Processing language and IDE is an artist-friendly wrapper for Java. You know Java? That C-like language that is hardware agnostic, meaning the same program will run on multiple environments?

Except not always. The handling of MIDI events was broken in the Mac implementation of Java. You know the Mac, right? The artist's machine? Only Apple in all their wisdom decided to cripple MIDI when they transitioned to OSX. With a lot of third party aps and hard work you could re-create the lost functionality of Opcode's OMS, and get back a system that actually listed the patch names of your outboard equipment again.

But then Apple goes and loses the MIDI functionality of Java around OS 10.4 or so. It doesn't come back until a later Java release -- that won't run on anything less than OS 10.6 -- but not all the way; there are still a few broken functions. There is a third party library, mmj, which in some implementations on OS 10.4 (and perhaps even OS 10.5) will work.

Of course even then you are left with the need to build a library for PROCESSING, to "Processing-ize" the MIDI functionality in the raw Java. Oh, to be an actual programmer instead of an artist-type, so I could just write it myself. Or, better yet, go straight to CoreAudio and handle it there, without involving Java.




The nice thing about a Java ap is that as long as the Java virtual machine is properly installed on the user's computer, you can stick a custom icon on the Java ap and it will look just like an ordinary double-clickable application.

And Processing makes the whole thing even one step easier, when you are working with a "sketch" in the friendly IDE, which turns your twenty lines of kindergarten code into something that will actually run...and then you can play with the finished Java ap and make it into a practically stand-alone application.

With libraries like proMidi and controlP5, all the heavy lifting is done for you, and even an idiot like me can make a functional serial-to-MIDI translator.

Or, I could, if I had an Intel Mac. Unfortunately I'm still stuck in the PPC world. I have five PPC laptops that see almost constant use, being used by me or loaned or sometimes even rented to work as sound effects playback, multi-track recorders, video playback and virtual instruments. One of them just came back from being a harp in a pit orchestra (played from a Yamaha Clavinova), one is currently playing back sound effects in a booth, and my main machine is being a drum sub-mixer (an improvised solution I really hope not to have to resort to again!)

Which means, in short, although I intend to do more with Processing and MIDI, I'm simply going to wait until my hardware is updated. Because even if I could get it to run on my hardware, what I want to be doing is making solutions that will run on the average -- aka modern -- machine. It doesn't help any in the long run to have a piece of software that requires OS 10.4 to run.



What I really could have done with, is to not have to spend two days of frustration over compiler errors to finally discover all this.

Oh, and I have an interim solution. Hairless MIDI (yes, that is what it is called) is a serial-to-MIDI converter that works on, well, my lone OS 10.5 machine at least.

With that, I was able to confirm transmission of a MIDI command from desktop to laptop over the airwaves, and trigger QLab remotely to play back a cue.