23 April 2012
07 November 2011
05 November 2011
07 August 2011
06 August 2011
03 August 2011
31 July 2011
19 July 2011
Video workflow for terrible AVCHD cameras
My friends and I in Ensemble Evolution had a great idea for our Piteå Percussion Repertoire Festival: “Let’s record ALL of the seminars and concerts!! We can just use the little camcorders from the school service centre.”
The result? About 140GB of messed up AVCHD MTS files and separate audio recordings. There are lots of problems with doing this much recording with these kind of cameras but for now I have a reasonable workflow for making something useful out of all the mess!
Problem 1 – capturing from the camera
If you can plug the camera directly into a computer, iMovie or Final Cut Pro (7) can usually import all of the recordings which takes a LONG time. In our case, we used three cameras which needed to be returned so I copied the contents of their hard drives onto my external drive to deal with later. As it turns out, iMovie won’t import from the copied file systems and FCP will sometimes using Log and Transfer. One of the three cameras worked with FCP and the other two were no good. So I had to do something else!!
Problem 2 – joining split MTS files
If you dive into the file system of the Sony cameras I was using, you find lots of huge .MTS files. These are the videos saved in AVCHD format! Unfortunately, each recording was split up into 2.12GB chunks… (FAT32 maximum filesize attack… hurr durr). Luckily, you can join them together using “cat” in terminal.
compy:STREAM charles$ cat 00000.MTS 00001.MTS 00002.MTS > joined.MTS
(It’s easy to see where each scene ends, because the last chunk has a filesize of less than 2.12GB.)
Now, MTS chunks are back together as they were meant to be and they can be played back in VLC if you want to check them out. BUT, they won’t play in Quicktime so you can’t import them to iMovie or FCP the way they are.
Problem 3 – fixing AVCHD for Quicktime
The MTS files are a perfectly normal video format (H.264 with AC3 sound) but Quicktime doesn’t know what to do with them. I use Remux (free) to repackage the MTS files into an mp4 file with AAC audio (since I’m replacing the audio later anyway…).
It’s not exactly quick to use remux on a 12GB file, but it’s a lot faster than transcoding into mp4 using Handbrake.
After remuxing the file you can play it in Quicktime and import into iMovie FCP or anything else easily! YAY!
Lots of the finished videos are going up on our Vimeo page now!
13 July 2011
Posterous exporter for Toto
I’ve been experimenting a bit with a cute blogging engine called Toto and wanted to migrate my Posterous posts so I wrote a little script in Ruby to download them all and format them in a Toto-appropriate way.
This script uses the posterous gem just to retrieve each post and put it in a YAML text file that Toto can understand. At the moment there are a few problems…
- Since YAML uses “:” as a control character I had to remove any colons from titles and replaced them with dashes… I wonder if there’s a way to preserve them so that the text files are still human-readable?
- The posterous gem only seems to get one page of posts at a time since my blog has 19 pages, I just ran my downloading method for each one.
Anyway, here’s the script! Maybe someone will chime in and tell me all the things I’m doing wrong.
#!/usr/bin/env ruby require 'posterous' require 'toto' Posterous.config = { 'username' => 'username', 'password' => 'password', 'api_token' => 'api_token' } include Posterous @site = Site.primary Dir.chdir( "~/src/posterousparser" ) def saveposts(pagenumber = 0) @site.posts(:page => pagenumber).each do |e| timestamp = e.display_date yyyy = timestamp[0..3] mm = timestamp[5..6] dd = timestamp[8..9] title = e.title.gsub(":", "-") slug = title.strip.slugize filename = "#{yyyy}-#{mm}-#{dd}-#{slug}.txt" puts "Writing #{filename}...\n" file = File.new("#{filename}", "w") file.puts "---\n" file.puts "title: #{title}\n" file.puts "author: #{e.user["display_name"]}" file.puts "date: #{dd}/#{mm}/#{yyyy}\n" file.puts "timestamp: #{e.display_date}\n" file.print "tags: " e.tags.each do |a| file.print "#{a["name"]} " end file.puts "\n\n" file.puts "#{e.body_full}\n" file.puts "\n" file.close end end puts "Downloading posts now!" for i in 1..19 do saveposts(i) end30 June 2011
cool things at NIME2011
I went to NIME2011 in Oslo a few weeks ago, it was a really fun opportunity to catch up with some contacts in computer music and interactive media and to see what’s going on in the research world at the moment. Here’s a (non-exhaustive) list of things that stuck in my mind
Satellite CCRMA.
Two CCRMA-lites (Edgar Berdahl and Wendy Ju) presented their ideas about using [Beagleboard][beagleboard] (tiny computers on a board) to teach interface design. Broadly, they thought that the longevity of DIY music interfaces and other physical-computing projects is really held back by being tethered to a computer that is often used for other tasks. Their answer is to add a Beagleboard to the Arduinos they already use to create a self-contained system for running sensors, making and processing sounds and even doing video output and computer vision.
I was kind of skeptical about the idea until their talk… the thing which really got me was they’ve setup a Linux distribution for the Beagleboard which can run Pd patches or any other common computer music language. It seems like they’ve really got the whole process for setting up the board with a patch worked out and there were a few projects in the demo sessions from their class.
Now it’s just a matter of time before I crack and buy one of those boards…
I realised watching their talk that CCRMA is really a special place for this kind of stuff to happen and develop REALLY quickly. The two presenters clearly have a lot of passion for making it happen and must have put a huge amount of work into getting the kinks out of their system, the institution supports them figuring it all out and by the time NIME rolls around they’ve taught one class using this technology and are preparing a new version for the summer course and next semester’s students. I think it’s very rare in this field to have a place where this stuff can proceed so rapidly… great teachers, supportive institution and lots of students to test it on.
HIDUINO – MIDI enabled firmware for Arduino UNO
Some really cool work here. They’ve written a firmware for the Arduino UNO so that it can work as a driverless MIDI interface (and maybe one day to send OSC as well through network over USB!!). This will make a big difference in the quality of work that Arduino hackers can produce. It totally sucks to mess around with software to convert serial to MIDI, much easier and more elegant to go straight to the useful protocol (yes, often MIDI is more useful that OSC…).
“The Shells” by Alex Nowitz
A really compelling performance by this guy who sings and controls a computer using handheld controllers in the STEIM “The Hands” style. The controllers themselves had a really cute stand that also had a tiny display connected to his Mac Mini (offstage). It’s bizarre and embarrassing how refreshing it is to see people really getting deep into interface design that doesn’t require a laptop on stage… just moving the mac mini offstage and having a tiny display makes a huge difference to the potential for stage presence.
Sergi Jordà
Sergi Jordà (of Reactable fame) gave a great keynote presentation discussing his career in art, HCI and now product design. One comment he made about Reactable that struck me was (something like) “after the first paper, we haven’t been to NIME, because we’ve been focussing on making the product better, not creating new interfaces to write papers about”. From what I can see, NIME gets a huge number of papers about prototype style interfaces, instruments and performances and many fewer papers about really mature, successful and high quality projects. I think there’s probably an interesting story to tell about how a research project Reactable becomes a system that you can ship off to a museum and trust that it will actually work when set up by an amateur.
I also noticed that his earlier work in cross-artform performance with networked interfaces and interactive elements was kind of similar to my own work with Last Man to Die. Except his was CRAZY SCARY.
Strike on Stage
Chi-Hsia and I gave a demo of our Strike on Stage system which is about a year old now. I was actually a bit surprised by how good the reception was, lots of people asking about the details and interested in how the performance works. I thought that the NIME crowd might have been a bit fickle about older presentations especially since we actually performed the piece at NIME2010 in Sydney. I think the demo is actually MORE fulfilling than more prestigious paper presentations because you can physically and musically explain design decisions and how everything works.
25 June 2011
29 May 2011
Speaker noise instrument
I went to Nicholas Collins' "hardware hacking" workshop at NIME2011. It was SO FUN.
16 May 2011
some thoughts on grants
Some thoughts about grant writing and funding…
About more than just chasing money
Writing grants and applications is an opportunity to clarify the concept of your work before going to the trouble of creating and presenting it to an audience.
Usually you have to:
- explain your goal
- explain the steps to get there
- explain why you can achieve those steps
- work out a realistic budget
Good grant applications ask you specific questions to help you drill down to actionable steps and demand that the budget is set out in a standard way. Bad applications ask crazy airy fairy questions and let you slip by without nailing down a budget, specific goals or steps. I hate bad applications.
Grant writing and the real world
As it turns out, all this application writing actually trains you to create better projects and how to pitch them. Out in the big, bad, world, there are times when you need to pitch ideas without the comforting framework of an application. The same rules apply, you need to explain a clear goal and show how you can achieve it with a realistic budget.
When grants go wrong.
I think there are two big camps for funding rounds: those where 20% or 30% of applicants are funded and those where only one or two are funded out of many.
In the first case, you mainly lose by not selling your project well enough. With hindsight I can see some of my rejected applications had one or more of:
- bad/boring concept
- too broad scope (better to break into sub projects and apply for funding for only one)
- bad argument that I could achieve the result
In the second case it’s possible to lose for no reason but the preference of the funding board, if they have five great projects but only one grant, they just have to choose whichever they like better or whichever is a better match to the aesthetic goals of their organisation. So, you can lose despite having an amazing application. It sucks.
I think best comfort here is to see that there are always more opportunities for project ideas to come to life and sometimes you can’t see them until the application is written and you have a clear idea of the parameters of the project. Rather than think “there’s always next year”, think about where else this idea could go, even outside the world of formal funding applications.
15 May 2011
How Fitting is Fitter's Workshop?
14 May 2011
Crowdfunding musical projects
21 April 2011
05 April 2011
iOS networked metronome proof of concept
Somebody asked me whether it was possible to have a metronome synchronised between a bunch of iPhones... it turns out it is!
I made this little demo with Pd and RjDj, the computer controls the tempo and sends a message on each beat to the iOS devices which beep and flash a visual cue accordingly.
It works pretty well, but there are a few problems that I'd have to address in making it ready for a performance... first of all, it's annoying to set up the IP of each iOS device in Pd, but the netsend object doesn't seem to support UDP broadcast. Secondly, there's some occasional problems with latency messing up the nice steady rhythm on the devices. Experience tells me this could get worse in a performance venue with lots of wires and walls and things to mess up the Wifi signal. I'm sure I could think of something to fix it.
I wonder if it would be better to make a production version as a native iOS app? RjDj is probably easiest from a distribution standpoint, but it's a complex app to accomplish a simple task...
28 March 2011
performance process is iterative!
1. Rehearse
2. Performance
3. Performance
4. …. and so on, where each performance gets better each time until you're awesome.
Now I actually think that it's more like this: 0. Create opportunity and concept
1. Development and Rehearsal
2. Performance(s) and Feedback
3. goto 0. This whole process actually needs to be repeated for the performance to grow! After a performance or a series of them, I need to step back and reevaluate the work from the ground up and give myself the opportunity to weed out things that sucked and change A LOT of the conceptual work if necessary. I think that the extra words in my new process reflects how I've changed since finishing university in 2009 (also since teaming up with visual artist). At uni, the opportunities for creating works were always obvious, a recital, a thesis, etc. In the non-academic world, you have to make your own and the concept for a performance project is significant to how an audience will react to it. "Percussion Recital" is a label, not a name. Feedback is another huge thing which has changed since I left uni in Canberra. Feedback in a class is usually from an expert in the same field as you. Feedback outside of school is either from a lay audience or from an expert in a different field from you (i.e. I've often had dramaturges or visual artists talking to me about my musical performances). Sometimes it's hard to listen to these opinions because they might not see that you made certain decisions because of the musical/historical context or tradition that you belong to. I think it's SUPER important to try REALLY hard to understand what they are saying for exactly the same reason. PS, for me, development and rehearsal are kind of the same thing, rehearsing a work informs how it is composed and so I can't expect to nail down a composition before rehearsals start.