9/10 of the time, the MIDI signals generated by my various gadgets are going into a laptop anyhow. And as I gain confidence in programming, I think it is easier to write client-side software than to try to do everything on the embedded processor of a black box.
This seems like it is going to be the form of my DuckNodes. On the Node end, LiPo battery and charge circuit, monitor/feedback LEDs, XBee. On the master end, Xbee node with FTDI adaptor plugged into a USB port -- and the rest is software.
(That's the actual hardware in the picture there; one Xbee inside the television remote, one inside the duck, with the latter connected by USB cable to the Processing sketch visible on the desktop.)
This is a bad time for me to be buying parts. So this will have to do to construct the prototype DuckNode; a Modern Devices accelerometer, XBee (not XBee Pro), and AAA batteries. I need to read up on the chip, though, to find out the voltage tolerance and so forth. But for the nonce I'm working on the software layer, and for that my XBee-equipped Easy Button is sufficient.
Just as a refresher; the XBee is an implementation in a convenient package of the Zigbee standard, part of the whole 802.15.4 standard and protocol. In plainer language, a 2.4 GHz digital radio transceiver designed for low-power, low bandwidth data transmission for remote sensing, medical monitoring, home automation and the like.
The XBee Series 1 or Series 2 costs about $20-25 a node and has an effective range of about 30 meters. The XBee Pro (same two series), is a bit more of a power hog as well as nearly twice the cost, and can do 100 meters reliably.
These are digital transceivers; not only can they communicate bi-directionally, they can also report back RF power received, nodes discovered; they can be re-programmed wirelessly; and they can be configured in alternate transmission topologies -- such as in Mesh form; where each node communicates with neighbor nodes, passing along signals until they at last reach the hub.
Via the ubiquitous FTDI chip, an XBee node can be made to show up as a serial COM port device on a personal computer. Sparkfun and Adafruit both offer easy-to-use "Explorer" boards that do just that; connect the XBee in the board's socket to your computer. At which point you can communicate through or (using the AT command mode) with the XBee from your computer.
Terminal mode will work. It is just a COM port, after all. But so can a number of software development packages that can take a serial input; Max/Msp, for one. Pure Data, I suspect. And Processing.
So this week's adventures are to develop a more robust software package to receive data off my XBees.
Turns out Rob Faludi's XBee API Library for Processing is wonderful. It took me a little puzzling to understand how it was organized, but now I can properly decipher the whole frame of an XBee transmission (or, rather, what an XBee reports down the serial port when it gets a transmission from another node).
Now that I've got a computer running on (shudder) Mountain Lion, I have an OS under which Apple (grudgingly) finally brought Java up to version 5. Which means the MIDI functions which were broken since around 10.4 are finally working again. Which meant that the first Processing library I tried -- The MIDI Bus -- worked like a charm.
So now I have a framework that properly interprets just what the remote XBee node is sensing, and executes desired MIDI commands: sending them into the internal bus (at the moment I'm just instancing an Aria player to react to the MIDI inputs.)
But I want a more robust program. I want to be able to adjust to different environments, for instance. Right now the COM port identity is hard-coded.
So yesterday's exercise was learning how to create a set of radio buttons that displayed all available COM ports (aka listed the serial ports). And that meant trying out some of the GUI libraries for Processing.
This is truly a place where I wish I was writing in pure Java or, better yet, straight C in Apple's own development environment. Because then I could just bring in the standard Aqua GUI instead of having to create buttons from near-scratch in a graphics-oriented programming environment.
The Intaglio library worked, but I didn't like the way it looked. So I switched over to G4P. Which is very powerful, but strangely documented. I still have not figured out how to interpret their extensive but hard-to-read documentation. And the examples are no help. Tthis seems endemic in Processing; that instead of simple example programs, what is supplied by the library writers are show-off programs with multiple function calls and loops and hundreds of variables, making it really hard to drill down to what the actual library functions do.
For instance; the GButton function in G4P creates an instance of a button. It takes five or six variables (I can't understand exactly what the doc is saying here). They are identified as "float1, float2, float3..." Which is to say; no idea what the variables actually stand for.
After basically trial and error I figured out the first four floats specify a rectangle in the graphics space (this is actually quite common in Processing) and they do so in the standard Processing order as well. Whether they will take the more advanced meta-variables that allow a scaleable window, I don't know yet. More experiments.
But the example programs use round buttons. How? And there is a way to tie the buttons together as radio buttons -- to group them so only one can be selected. How? I really wish there was a more readable doc on this software somewhere. The best I've found so far is random posts on the Processing forum asking "How do I do this?"
I am more than half-tempted (since there is a great example in the core Processing examples) to write my own GUI functions. Just so I understand how the heck they work, and can do the basic things I need to do with them.
(Especially since the default look of the G4P library reminds me way much of the "Okuda-grams" from Star Trek, the Next Generation. Which means if I use that library straight, I'll have to fight a probably futile fight not to design the entire interface in LCARS style. Animation and all. But it is Processing after all. If there is anything Processing wants to do, it is drawing colored rectangles in the program window!)
In any case. The current step is being able to select the desired COM port on the fly, thus allowing the program to adjust for different computer setups. The next step would be to have the same flexibility in MIDI routing, including the ability to create a MIDI output that can be recognized and selected by downstream software (instead of the way I'm doing it now, which is hard-coding the software to open up an existing MIDI device from a device list).
For a simple duck program, a nice function would be the ability to select a sound file (using a standard file dialog) and play that -- thus cutting MIDI, and other external software -- out of the loop completely. This could be useful for those show where I only need a single sound to play on remote command, such as a doorbell, a "Wrong!" buzzer, or a Universal Remote Control. This is actually how the first "Duck" program worked, via the minim library (with the sound file compiled into the stand-alone ap).
The real heavy lifting is going to be when I move from pushbutton to accelerometer. There is where I'll have to figure out how to massage and filter a complex sensor data stream in order to extract specific motion cues. And at the moment I'm pretty blank on how that is going to happen. My guess is that there are Processing libraries already out there. Perhaps Java libraries -- but, heck, I haven't even quite figured out how to use straight java libraries within the Processing environment!
There's gonna be some heavy programming over the next week or two, I can tell that much. And at some point I still want to learn Blender and DAZStudio. And of course Pure Data....
No comments:
Post a Comment