The Fugue

I'm porting Aeolus to OS X. In the process I'm learning how CoreMIDI works. Naturally you get to hear my opinion on the matter.

CoreMIDI seems like a decent framework, actually. It is callback-based, which is good. It has a pretty reasonable design; physical devices and virtual devices alike communicate with eachother in the same way. They each have endpoints—source endpoints and destination endpoints.

It all looks well and good on the surface, but there's some problems. The first problem is arguably a feature. You can create input/output ports and connect sources/destinations to those ports from within your application. This allows you to make a cute or complicated dialog box where the user can select the MIDI (virtual) device(s) she wants to use. Sounds reasonable right? And so it is, and I wouldn't argue against this ability.

The badness comes in when you consider that every application has to duplicate this functionality. It would be much better to have an external patchbay for connecting applications together. This would be more powerful and flexible and free up application developers to not worry about it. They just have to create the endpoints and then they're done.

Alas, OS X proper has no such patchbay. "Yes it does, silly. It's called Audio MIDI Setup" you say. That's the most infuriating thing—Audio MIDI Setup lets you route between devices in just the sort of way I'm talking about, but it only works for physical devices. Someone needs to be shot.

Luckily, some guy named Pete wrote a MIDI Patchbay. It's serviceable, if quirky and ugly. He also wrote a simple software synthesizer called SimpleSynth (also quirky and ugly) that does what something in OS X (e.g. QuickTime Player) should already be doing: accept MIDI input and use the QuickTime music synthesizer to render it. Kudos to Pete for filling in the gaps, and I'm sorry for calling your children ugly.

While I'm complaining about patchbays, I'm still dumbfounded that JACK doesn't seem to have a command-line application for patching things together. I'm thinking something akin to aconnect for ALSA MIDI, though of course for JACK it would be for audio and MIDI both. qjackctl is absolutely marvelous, and I wouldn't use anything else given the choice, but sometimes you don't have qjackctl handy and it might be quite difficult indeed to get it. This was the case for me the other day. I had the latest greatest JACK installed from source, but qjackctl (which I finally managed to figure out how to build using the QtMac binary, whose qmake refuses to output a real Makefile but instead an XCode project) was choking on it. So I had to downgrade to Jack OS X and rebuild qjackctl (it's still an immense improvement over JackPilot). This is depressing because the newer version of JACK is much more friendly to the CLI user on OS X. The version in Jack OS X 0.76 still requires some ugly workarounds (which JackPilot helps you to do). The latest version of JACK (0.109.2) Just Works™ when you type jackd -R -d coreaudio. So I'm still starting JACK with JackPilot, which I then summarily quit in favor of qjackctl.

Once upon a time I was on a quest to get Ogg Vorbis working on a Mac. I tried the QuickTime Components project and it worked for awhile. Then it broke with QuickTime 7. Truth be known, it never worked all that great before, though it did decode the music. Then I found VLC and never looked back.

Today I learned that somewhere in the interim Xiph.org filled the gap. Now you can download XiphQT, stick XiphQT.component in /Library/Components, and you're off and running. This is precisely how the issue should have been addressed in the first place, and I'm glad it finally was, whenever it was. I'm also happy to have been ignorant of the fact for so long, since I despise iTunes for other reasons, and this tells me I've lived without regular iTunes abuse for a long hapy time.

JACK is a low-latency audio server, written for POSIX conformant operating systems such as GNU/Linux and Apple's OS X.

If you're doing serious audio work, JACK is a beautiful thing indeed. I had a problem getting it going on the MacBook. I didn't have any trouble with it on the iBook, so either JACK changed, or a recent OS X update changed things, or just the fact that the MacBook has both a line in and a microphone canged things.

This is the error I was getting:

$ jackd -d coreaudio
jackd 0.102.20
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with POSIX SHM support.
loading driver ..
Default input and output devices are not the same !!
Cannot open default device
Cannot open the coreaudio driver
cannot load driver module coreaudio
no message buffer overruns

You can see the thread on LAU for more details, but the short answer is you need to create an aggregate device in the Audio MIDI Setup panel. Open it up and go to the Audio Devices tab. Then go to the Audio menu and choose Open Aggregate Device Editor. Add ye an aggregate device with all the inputs/outputs, and JACK will just work. Not only that, but it will have access to all the available inputs and outputs.

Announcing the latest version of hearnet: the (in)famous little JACK toy. The name may bring back memories of your favorite lunch lady, but the sound of your own network traffic will move you in ways that she never could have hoped to move you. I hope that's a good thing.

This release sports filter expressions (a la tcpdump) and the ability to drop privileges and run as a normal user, and therefore play nice with the other JACK apps in your playground.

Enjoy, and don't get any hair in your network.

My GAANN fellowship will be sending me to New Orleans in November for the International Computer Music Conference (ICMC). I'm pretty psyched about this. I've never been to an academic conference, and I've certainly never been to a conference about Computer Music. It's going to be a blast, and it's going to be very informative. Hopefully I'll be able to network with some people in the field working on research similar to my own (which will begin in earnest in January, since my coursework is (almost) done after this semester). There will be Computer Music conferences, and I'll be sure to catch some good old New Orleans Jazz too.

I haven't asked yet, but I'm hoping GAANN will send me to the Linux Audio Conference in Berlin next year, too.

I get the impression that most users of MIDI sequencers step record. At least, the writers of the sequencers pay little attention to live recording. For evidence, I cite the abundance of tracker sequencers available for Linux, and the three major sequencers for Linux (IMHO) which all fall short in the relatively simple task of accomodating people like me who prefer to record things live: Rosegarden, Muse, and Seq24.

Live recording is not complicated. You need a few basic features, and you need to make them accessible from the keyboard without touching the mouse. Here's an excellent UI model (that makes me drool):

And here's a list of those basic features:

• FF, REW, Stop, Play, Record
• Replace and overdub modes.
• Punch
• Loop
• Metronome
• Lead-in of 2, 1, or 0 measures. My old Roland JW-50 from 1992 did a great job with this. You had the option of no lead-in but you also had the option of key-triggered recording. That is, you press record, and the thing starts recording the moment you start playing. This is extremely useful.
• Track muting and solo
• 16 tracks
• Variable speed (percent of tempo) for slow and fast recording.
• Undo

That's it. Most sequencers have some or perhaps even most of these features, but leave out essential aspects such as no mousing, replace recording, no lead-in, and not crashing. Rosegarden goes a step further and makes the simple things that you take for granted difficult as well (but it does everything else under the sun and it's hard to justify not using it).

Seq24 is unique in its failure because it is oriented at realtime performance. Note that word, "performance". It could perhaps just as easily be good at realtime recording if it tried, and then in spite of its loop and pattern-based approach it would still be an excellent sequencer for us non-pattern junkies. (Sequence a Bach organ fugue in a tracker, I dare you.)

If I have the honor of speaking to someone who is writing or improving a sequencer, please consider the keyboardists and take my thoughts into consideration. Believe it or not, the lack of these basics will drive a keyboardist crazy just as fast as mousing will drive a CLI junkie crazy. Which is quite ironic as most step-recording Linux sequencer developers are probably CLI junkies.

I have a laptop and I often use it at home, on the couch. I have a workstation on the other side of the room that my wife frequently uses (which is one of the reasons why I mostly use the laptop), which has decent speakers. I like to listen to music. I think you can see where I'm going with this.

In the past we've used various media players. The one that worked best for remote control was xmms with a homebrew xmlrpc client I made, and now that I have lirc working that would be another option for remote control. But my wife kept closing xmms and xmms is lame anyway. I got into quod libet for a little while but even though there's several ways to control it apart from the gui, it's still not very remote friendly.

Von and I have kicked around the idea for a better music player many times, and the other day I had an epiphany: it should be a sort of stereo daemon, with clients connecting over the network and driving it. I've learned that most good ideas I have have already been had, so I searched a bit and sure enough, mpd. mpd is nifty, wholesome, and flexible. Your wife can't close it, you can control it with simple command-line, ncurses, gtk, qt, etc. clients (still need a good osx client, but the ncurses one is good enough for a cli junkie like me). If I have music playing and she wants to stop it, she just has to fire up her client if necessary and hit stop. No fuss, no excuses. If she's closed her client and left the room and I want music I don't have to stand up, futz around with ssh, nohup, and DISPLAY, or even think two thoughts. I just fire up my client and hit play. Highly recommended.

The Thingamagoop (as featured on Music Thing) is a work of art. It's ingenious. It's hilarious. If it could it would eat chunky bacon. Be sure to watch the video.

It's official! I am one of the recipients of Google's Summer of Code grant. That means I get paid $4500 to improve Ardour according to my proposal over the summer. Combined with the GAANN fellowship I've received this means I can spend most of the time this summer writing code for Ardour and studying for quals.

My proposal was to modify Ardour so that plugins can be applied to regions instead of just tracks, both for realtime processing and bounced to disk. This is a feature I have sorely missed in Ardour, as it is an important tool for making electronic music and musique concrete efficiently. The other half is to add undo/redo serialization of the current undo system to allow unlimited undo across program instances.

I'm really excited for this opportunity. It will be my first serious involvement with a big and important open source project as a developer. I've often told myself I needed to get involved with one, and now I have an ideal opportunity to do just that.

There are two other SoC recipients for Ardour. One is adding basic MIDI recording and playback, and the other is doing a Windows port.

Ladies and Gentlemen, I bring you ruby/audio 0.1.1. This is primarily a bugfix release, but you fill find a few documentation and feature enhancements as well. Enjoy!