I'm not even sure I like programming

Of course, what I'm doing is somewhere between "scripting" and "magic incantations" -- I'm using beginner-friendly tools and I'm copy-pasting lots of code blocks I barely (or don't at all) understand. What little I do understand, I am applying with equal measures of kludge and brute force and ignorance. A Bubble Sort would be an improvement on most of my algorithms!

Anyhow.

A friend just called wanting to see if I had a suggestion to spit out a MIDI event from a detected physical event on stage (the pedal of an otherwise gutted prop piano being depressed). Yes, I do. I've built the circuit in the past. I keep meaning to put it in a nice box (and even make it available in kit form for others) but I keep getting distracted both by Feeping Creaturism, Creeping Elegance, and the uncomfortable realization that 99 times out of 100 a technological solution (even one that is available out of the box and has already been well-tested in practice) will be passed over in preference for a Stage Manager squinting at the stage and calling out "Sound Cue Go!" on headset to someone else who presses the play button.

Such is theater. We're more conservative than aerospace. If it works, we don't like to mess with it.

So anyhow, I have the guts of one of my old button-press-to-MIDI boxes on the desk and all it would take is about an hour to figure out which pins I chose to wire up or otherwise reconstruct the original code for it. It seems sturdy enough and it is well-tested -- been through at least three stage productions that I remember, being used to fire off intercom buzzer sounds for "Moonlight and Magnolias" and a baby's cry for "Into the Woods" and... some show I've already forgotten.


It isn't of course elegant. 

So I've spent the morning going back again through the perennial problem of getting no-driver MIDI to happen over USB. And, yes, the least elegant method is the most robust; buy a $40 MIDI adaptor from Guitar Center, hack it up, wire it to the Arduino's serial port and stick it in a project box with the Arduino. Once the lid is closed, no-one will know the difference.

The newest solution on the block is that the Arduino Leonardo (and some others that come after it) use a chip that speaks USB natively and it is now trivial to turn one into MIDI or HID (aka emulate a keyboard or mouse.) This is completely class-compliant and requires no special drivers or client-side software; just plug it in and most modern computers will recognize it.

I don't happen to have a Leo. I don't think RadioShack carries one and this is a project I want done this week -- Tuesday if possible.

So the most plausible option seems to be using an ATmega32u breakout board I just happen to have, and trying to get either the LUFA framework or the more complete-and-friendly Teensy working on it. And although this might be approached at least at first through the Arduino IDE, it looks probable that once the USB port thinks it is a class-compliant MIDI device I'll have to resort to going through my AVR programmer -- and quite possibly having to delve down into make and avr.gcc and other things I've nearly forgotten.


And of course I'm right in the middle of learning Raspberry Pi now. So C or the Arduino macros or, worse, the avrdude toolchain aren't on the tip of my programming "tongue" right now. Instead I've got bits of Python and lots of Linux commands filling up my brain.

I'm getting a little more comfortable on the Linux command line. That's one of the major things I hope to accomplish playing with the Pi, anyhow. I mentioned before that the GUI (I'm mostly using X, when I use it) is like a coat of paint. A thin coat of paint. It isn't uncommon within X to find yourself presented with a command line in the middle of a drop-down menu or otherwise innocuous selection box, and it is often transparent what command line, err, commands you are issuing even when you make a radio-button selection in that GUI.

So I've got "sudo apt-get" and "cd /dev/pi" and "pkill x" and "nano /dev/config.txt" and so forth all clogging up my brain.

(Among the other amusements, command-key sequences become alt-key sequences on the current Raspi keyboard, except for within the nano editor, where I have to remember to use the "window" key instead).

I'm making progress. Tried out OSMC and OpenElec (different wrappers for Kodi, basically) but neither was friendly towards further hacking; no terminal, difficult to exit X, difficult to SSH into even (I managed to confuse my MacBook into thinking someone was attempting a man-in-the-middle attack and for a while it refused to even connect with the Pi anymore. Say, who is all this security for? You trying to protect me, the owner of the computer, from taking risks I think are justified? Did or did not I pay for the thing?)

So back again (at least twice now by my count) to the Debian clone, Raspbian. This time I hand-installed the Adafruit patches and nano'd the additional lines and config files necessary (err...I said I wasn't going to try to explain Raspberry Pi processes in detail. nano is the default text editor, a utility almost as old as but far less venerated than "ed.")

So now it doesn't force X to go to the PiTFT (Adafruit 2.8" full-color backlit LCD touch-screen). I can chose to throw the GUI, images, or movies to the device of my choice. Can play mkv, mp4, mp3, aiff...but not all with the same application. Each requires different phrasing to set up the options correctly, plus more options to get sound to go to the correct port to accompany a movie. So lots of typing out "sudo SDL_VIDEODRIVER=fbcon SDL_FBDEV=/dev/fb1 mplayer -vo sdl -ao alsa *.mp4" for the present.

I have a theory now why so many people asked at so many forums how to get X back to the HDMI port, and were all given the same answer that does not work by the gurus at Adafruit and elsewhere. Here's the theory; the gurus actually have HDMI monitors. The people with the problem -- like me -- are using an HDMI to DVI adaptor to drive a DVI monitor. So my bet is that when the Pi doesn't "see" the full HDMI it expects at the other end of the cable, it throws up an error and reverts to the last-used display port. Thus going back to the PiTFT instead of switching to the HDMI as requested.

And the gurus never realize this because their gear is too good; they never experience this problem. Whereas the poor noobies are left with no working answers and get frustrated and after a few more posts, leave.

Anyhow.

I have control now. And I figured out how to resize enough of the icons and otherwise reorganize X so I can sort of work with it on the tiny 2.8" display. So I have a couple of options to make transportable, battery-powered control of the Pi. My aim is to make a Headless Pi, but reality is I'll probably have to go in and tinker with stuff anyhow.

I also have some options for my eventual goal of playing mp3s off a USB stick. Unfortunately, the plug-and-play options -- aka various flavors of Kodi -- aren't easily compatible with the 2.8" display. So I'm looking now at either a lot of tinkering to get various third-party projects adapted to my particular hardware, or rolling my own. Either option is going to require a lot more time staring at the command line. And going deeper into programming for the Pi, too.