Laptop Orchestra: A Sonic Experience from The State Press on Vimeo.
The State Press, Arizona State University’s daily newspaper, did a video profile on LOrkAS, featuring our performance at this year’s EMERGE festival. I feature briefly, talking about LOrks, and conducting Dan Trueman’s Drone and Ge Wang’s Crystalis in the show. The video also features current president Courtney Brown and founder Diana Siwiak talking about the origins and importance of laptop music.
My multirotor building has been on hiatus for the past several months while prioritizing the dissertation and a series of challenging personal circumstances (Ryan’s move count this year: four). It’s Spring Break next week, which means time to procrastinate on work and build cool stuff. I finally got around to fabricating the Baseflight breakout board I’ve been playing with in Eagle for months. It was cut using an LPKF S63 Protomat PCB CNC machine.
The microcontroller is Timecop’s STM32 Mini r0 dev board; the sensor is an MPU6050 gyro/acc breakout board. One of the significant differences between this rig and my old MultiWii solution (Arduino Pro Mini + breakout board) is that the STM32 Mini does not output 5v when USB powered. This means that the MPU6050 is not powered, and as a result, Baseflight cannot be communicated with via serial. I need to throw this setup on a JTAG and look at what’s actually going on in this state. The STM32 Mini does not enter the “flashing red-green LEDs, no sensor connected” loop, but also does not respond to serial input. Supply +5v from a bench supply, however, and all is well.
If you just want a multirotor flight controller, I highly recommend Timecop’s Naze32 (full flight controller, includes magnetometer and barometer) or Naze32 Acro (gyro/acc only), by the way. I chose to roll my own system with the STM32 Mini so I could have an excuse to design/fab a board and experiment with different sensors and outputs, but I’m making extra work for myself.
A journal article on which I am lead author was just published in the ACM Transactions on Multimedia Computing, Communications, and Applications. If you have an ACM membership, or are affiliated with an organization that provides ACM access, you can view and download the full text on the ACM Digital Library.
This is a proud day for me, and I am extraordinarily grateful to my advisor, Aisling Kelliher, as well as my collaborators Yu-Ru Lin and Hari Sundaram. NextSlidePlease is the biggest, most interesting research projects I’ve worked on, and in a lot of ways, my baby. I’m happy to see the results of these studies going out into the world. I couldn’t have got this far without the support of these collaborators, and of many more friends and colleagues behind the scenes. To my collaborators: thank you all. To my readers: I hope you think this is as cool as I do, and I would be happy to talk about collaborating with others to build these ideas into something even more awesome.
You can find more information about NextSlidePlease, as well as links to the project’s other web presences, deeper in my website.
Telephone Tango – Laptop Orchestra of Arizona State – Nov. 19, 2012 from Courtney Brown on Vimeo.
The Laptop Orchestra of Arizona State (LORkAS) is an electronic musical ensemble in the mold of the Stanford (SLOrK) and Princeton (PLOrK) Laptop Orchestras. I was a founding member of the ensemble in 2010, and have contributed to a few pieces. We recently had the opportunity to perform a piece I helped create, Courtney Brown’s Telephone Tango, at the Arizona State Composition Studio’s first 2012 recital. Courtney composed the percussion score; I wrote the original user interface and network code; Brent Brimhall also contributed to the UI/UX.
From a technical perspective, the piece is running a hybrid client-server / peer-to-peer architecture based on Open Sound Control over UDP. The main app running on each player’s machine is built in Java, using the Processing APIs.
A central server keeps track of the players’ IP addresses, and stores the first version of each measure. The server transmits the first score, and a list of IP addresses, to each client. The client displays the score to the player, and records the player’s performance (quantized to sixteenth measures).
A Cinder application running on each player’s machine, developed by Courtney, uses onset detection to sense when each percussion instrument is struck. Java sound is challenging to do well, so we opted to use a dedicated C++-based app for stability/robustness/speed. The onset detection app communicates with the Java client via OSC over UDP, sent to the loopback address.
After each measure is completed, the client pops the next IP off the list of IPs delivered with that measure by the server. The client sends the current player’s version of that measure, plus the remaining list of IPs, to that IP. Thus, the slowly-mutating structure of the “Telephone” game is maintained.
So, John Fass has posted some scans of Jean Malaurie’s radial diagrams of inuit genealogy. Apparently these are the first examples These are some beautiful examples of hand-drawn radial genealogy diagrams. The technique has been picked up by plenty of others in the time since, though. Seeing this makes me thankful for GraphViz and similar tools, though — far easier and more convenient to write an algorithm to do this kind of layout once than to painstakingly design and implement it on paper, by hand.
Edit: John left me a comment clarifying that these are not the first radial genealogical diagrams in general, but for the specific group being studied. Mea culpa — I’ve edited this post to reflect that. The original wording remains, struck through, for posterity.
The Blender Institute has released its next Open Movie project, “Tears of Steel!” I snagged the torrent and watched it on my lunch break. As with all the other Blender Institute open movies, it’s a short (12 minutes and change), but still quite visually impressive. Even more visually impressive when you consider that Blender, the 3d graphics software behind all the visual effects, is free and open source. I’ve been using Blender for about eight years, on and off — not in any professional capacity, but its come in handy for a few projects.
It’s extremely exciting that these kind of rotoscoping, motion-capture/motion-tracking and compositing tools are available, for free, with source you can inspect if you feel so inclined. A few years back, these kind of capabilities would’ve required tens of thousands of dollars worth of software. Now it’s something we can experiment with “at home.” Of course, you still need live action video to take advantage of many of these features, and that’s not something that scales to “near-zero marginal cost” with digital distribution the way software does, but even so!
I’m reading a lot of critiques of the story on YouTube and around the internet. I agree that there are some missing pieces, but that’s kind of de rigueur for shorts. It could be improved, but I don’t think “it could be improved” makes what it is any less impressive, especially in terms of software and visuals.
A friend of mine has put together a quick guide to build an STM32-capable gcc toolchain on OS X, with OpenOCD debugging integrated into the Eclipse IDE. It’s in the Readme for his fork of Baseflight (a 32-bit ARM port of MultiWii). Without further ado: linkage!.
This is exciting because it makes building/debugging a more serious flight controller that much more approachable.
This is a video that’s been making its way around the internet — timelapse photography from various platforms on the International Space Station, of Earth. There’s a ton of visually interesting stuff here, but honestly it just gives me goosebumps. There’s a healthy political conversation to be had about whether or not we need to put people in space, but I am not going to argue with beautiful things like this.
The title of the post references the poem Coyotes by Mark Jarmin, by the way. I can’t find an author-sanctioned posting anywhere, so google it if you want the full poem.
MAKE Blog linked this morning to an incredibly cool project called “V Motion.” They’ve built a performance instrument with two Kinects and wall projections that makes the movement artist’s control of the musical interface an integral part of the audience’s experience of the music/performance.
One of the things that bothers me about a lot of interactive performance work is that sufficiently advanced technology is indistinguishable from good stage management (to borrow a turn of phrase from Arthur C. Clarke). Put another way, if a performer is very skilled at controlling/responding to an interactive system, it will appear to the audience as indistinguishable from a situation where the output of the system is non-interactive, and the performer is carrying out well-rehearsed and choreographed actions in synchronization to cues. How do you circumvent this challenge, and sell the interactivity of a system in a compelling way? One way is to involve audience-members rather than trained professionals, so those people experience the system themselves. That’s the direction I’ve taken in a lot of my recent experimental work, but presents challenges of its own in terms of staging, and doesn’t really lead to virtuoso performance in many cases (more on that later). When the parameters call for a traditional performance, what can you really do? If the audience sees more than one night, and there’s some variability in the performance, that does sell the idea that the performer is really in control, but who pays to see the same show twice?
You could make the case that a similar principle holds here — it
One of the neat side-projects I’ve been playing with is building a homebrew quad-rotor helicopter based on the MultiWii Copter project’s firmware. My initial build uses a Micro Quad / Fun-Sized Quad laser-cut frame from Blue Sky R/C and a Bob’s Quads Super Simple Shield flight computer, which is a very simple (as the name suggests) PCB that breaks out the required pins from a SparkFun Arduino Pro Mini for the RC receiver, sensors, and ESCs.
My first flight controller used a Nintendo Wii Motion Plus gyro board, but I recently purchased and built up a second FC using a 10-DOF IMU from eBay. For anyone who wants to follow in my footsteps, you an buy your own here (though I can’t guarantee that eBay link will be around forever).
I had a bit of difficulty working out the proper orientation for the sensors in the MWC code, so I’m posting my config.h’s defines here:
#undef INTERNAL_I2C_PULLUPS
#define L3G4200D
#define ADXL345
#define ADXL345_ADDRESS 0x53
#define BMP085
#define HMC5883
#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = X; accADC[PITCH] = Y; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = -Z;}
#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = -X; magADC[PITCH] = -Y; magADC[YAW] = -Z;}
Note that I’m using the DEV 20120622 version of MWC; these defines ought to work on other post-2.0 Developer snapshots as well, but you may need a different I2C address for 2.0 and earlier due to a change in how MWC handles I2C addresses.
I’ve included a photo of the quad, to reference when working out the orientation of my board relative to these defines: the orange props are forward, and the IMU board is situated with the barometric pressure sensor towards the front, and the components facing up.
Don’t forget to add I2C pull-up resistors, since the IMU does not include them on-board. Using the Super Simple Shield, I just ran 3.5k resistors between the SDA and SCL lines and VCC. Also note that in my defines above, I’m using #undef INTERNAL_I2C_PULLUPS because the ATMega328′s internal pull-ups don’t play nicely with the I2C standard, and can lead to some nasty communications issues.
With this setup, the quad is flying well. I have some magnetometer glitches to sort out, though. Who’d have thought? Putting a sensitive device that measures magnetic fields within 5″ of four brushless motors might be a dicey proposition.