on Unity2D and llvmpipe, and the differing approaches of fedora and ubuntu

Ubuntu’s Unity desktop invites comparisons to GNOME 3 for a bunch of reasons, but one important similarity is their reliance on hardware OpenGL support to power their visual animations and effects. In their first releases, both desktops used “fallback” modes to handle systems without OpenGL support, but in Ubuntu 11.10, Unity is available for those systems using a new project called Unity2D.

I think Unity2D is not just a terrible idea, but also another example of the new direction that Ubuntu is taking that makes me wonder if it’ll be my distribution of choice for much longer.

Not so unified

Unity2D removes the reliance on OpenGL by avoiding it entirely: it’s a rewrite of Unity from the ground up, based on the Qt toolkit and using the Metacity window manager instead of Compiz. While it looks and feels much like standard Unity, it’s an entirely separate codebase, and keeping the two in sync as features are added will require a substantial amount of extra work. Perhaps the Ubuntu developers have the resources needed to keep up, but it seems like a very shortsighted approach to me.

GNOME 3′s current fallback desktop is definitely a hack, too — it cobbles together a UI that looks a bit like GNOME Shell using the panel and related components that have been ported from GNOME 2. It has neither the flexibility of GNOME 2 nor the elegance of GNOME 3, so it’s not a particularly compelling experience, but the Fedora developers plan to make the full GNOME Shell experience available for nearly everyone in Fedora 17, using some very cool technology.

Software OpenGL with llvmpipe

OpenGL isn’t inherently limited to systems with hardware acceleration; Xorg actually provides a software implementation of OpenGL by default whenever hardware support is unavailable, but its performance is far low to handle desktop effects. However, a new software renderer, called llvmpipe, aims to change that. By using LLVM, a generic virtual machine that produces optimised x86 or AMD64 code on-the-fly, and utilising multiple CPU cores, llvmpipe performs far better than the standard Xorg renderer.

The gains are impressive: running Quake III Arena at 800×600 on my dual-core laptop, Xorg’s renderer managed 3.9 FPS, while llvmpipe managed a fairly playable 34.9 FPS. While that only makes llvmpipe about as fast as my old Matrox G400, that’s okay — it just has to be fast enough, and for GNOME Shell, and even the odd game, it definitely seems to be. llvmpipe has actually been used as the default software render in Fedora since Fedora 15, but it’s only in Fedora 17 that it supports all of the OpenGL features required to run a compositing window manager.

GNOME Shell on llvmpipe

GNOME Shell running without hardware acceleration on Fedora 17, using llvmpipe

I tested the Fedora 17 development packages (aka “Rawhide”) in a KVM virtual machine, and it worked fairly well; logging in revealed a complete GNOME Shell desktop, and while it was a little choppy, it was definitely usable. I’d definitely expect it to be faster on an actual PC, especially with a mutli-core CPU. The Fedora developers have plans to improve performance, too, by optimising llvmpipe and disabling some minor effects.

So, on the one hand, we have Fedora working on key infrastructure that will improve the Linux desktop experience for all users without hardware OpenGL acceleration, and on the other, we have Ubuntu developers throwing effort away on a developmental dead end. Ubuntu has copped flak before for not contributing to Linux development, but I don’t generally buy in to that argument — “contribution” isn’t something you can measure just by analysing commit logs or counting lines of code. Canonical can pay its developers to do whatever it wants them to do, but increasingly, it seems that the effort they’re expending is pushing Ubuntu in a direction I’m not sure I want to follow.

It’s hard to elaborate on exactly why I feel that way — I think it’s really down to little things, like insisting on forging its own path with Unity, the increasing number of built-in monetised services, and their sleazy dealings with Banshee (be sure to read the comments on that one!). Maybe the result is a great OS for a lot of users, but for me, Ubuntu is slowly drifting away from being the OS I want it to be.

wednesday reading list

I’ve mentioned Mixing Secrets for the Small Studio a couple of times now — it’s a great read, and I’m learning a lot from it, but mixing is just a part of making great music. Finding inspiration, getting ideas down, and then developing those ideas in to complete tracks are the real challenges, but there’s some great advice online for doing just that.

It was an article on Create Digital Music that reminded me about those challenges today — it contains seven “tips for creative success”, and they’re all right on the money. They talk about making use of what you have rather than focusing on what you think you need, and the importance of spending time on the music and having fun rather than sweating over tiny bits of finesse that no-one will notice anyway.

Some of the most enlightening posts I’ve ever read about making music come from general fuzz, a producer of some excellent (and free!) downtempo electronica; his “lessons” posts are a fantastic read. Some of his points relate specifically to music, and electronic music in particular, but many of them relate just as well to any other creative pursuit.

He covers a lot of ground: the value of finding your audience rather than relying solely on friends and family for feedback, of waiting before releasing new work rather than pushing it straight out, of actually finishing something, even if it’s not “perfect”, and of not getting disheartened by the fact that no-one will care about your work quite as much as you do.

I think that last point is particularly important. It’s great to make things that others enjoy, and to take joy from that, but if you’re not creating for yourself first, enjoying the process as much as the result, then you’ll ultimately end up frustrated.

new music update

A few months ago I posted that I was working on new music using Ardour 3, and I’m glad to say that my new track is now all but finished. Working with Ardour 3 was a bit nervewracking at times, as you’d expect when testing alpha software — there were several times, in fact, when I couldn’t even open the project’s session due to one bug or another. It all held together somehow, though, and after many bug reports and fixes, I definitely feel like it’s helped

The new track is a bit of a downbeat, ambient-ish thing, with some lo-fi sounds mixed in with some glitchy elements. I definitely put Ardour’s MIDI features to the test: there are MIDI tracks running out to my Blofeld and to Hydrogen, along with LV2 synths (Calf Monosynth and Linuxsampler), along with automation of CC parameters on the Blofeld and automation of plugin paramaters on Calf Monosynth. I’ve done quite a bit of effects automation as well, particularly with the bitcrushing Decimator plugin.

There’s even a VST plugin in there now; I had been beta-testing Loomer Cumulus, using it as a standalone synth, but with Ardour’s new VST support I now have it running within Ardour directly. Cumulus is somewhere between a synth and an effect: it lets you load a sample, and then trigger its playback using granular synthesis with varying paramaters, altering the starting point, pitch, and playback rate, among other things. You can define up to eight sets of those parameters, and then trigger those via MIDI keys. It can turn all sorts of sounds in to eerie textures, but it can just as easily take a drum loop and turn it in to a wonderfully glitchy mess, which is exactly what I used it for.

I’m pretty sure the track is done, but I don’t want to release it just yet. I plan to sit on it for a few days at least, while I read more of my copy of Mixing Secrets for the Small Studio, but I like the idea of putting together at least an EP with a couple of other tracks and releasing them all at once. That might not be practical if it takes me four months to finish each track, though, so I may post the individual tracks here when they’re ready, and then do an official Bandcamp release once they’re all done.

it’s here! native vst support in ardour 3

Ardour 3.0 is still in alpha, but it gained a substantial new feature last week: support for native Linux VST plugins. It’s a feature that’s been on wishlists for a while, but it’s become more important over the last year or so, as the number of VST synths for Linux has increased. The big drawcards are the commercial synths — Pianoteq, discoDSP Discovery, and the various Loomer plugins, for instance — but more open-source VSTs are appearing now too, such as the TAL synths, ported from Windows by KXStudio developer falkTX in his new DISTRHO project.

The new features use the unofficial Vestige VST headers, which means that Ardour avoids the need for users to download the official Steinberg VST SDK and build Ardour themselves. Having said that, the new VST support is a build-time option that’s disabled by default, but I’m hoping that it will be enabled by default, and available in the official binary builds of Ardour, before the final 3.0 release.

Ardour 3 SVN, running the Loomer Cumulus and TAL-Dub-3 native VSTs

As handy as this is, there has been some discussion about whether or not native VST support is a good thing. VST isn’t a particularly elegant plugin system, and given Steinberg’s licensing restrictions, it’s always going to be harder for the developers of hosts like Ardour to deal VST with than other plugin formats, such as LV2. I would hate to see this VST support discourage developers from working with LV2.

Realistically, though, it’s hard to expect commercial plugin developers to embrace LV2, on top of the effort already required to bring their plugins across to Linux. Indeed, now that Ardour has joined Qtractor and Renoise in supporting VST plugins, the size of their combined user bases might encourage more plugin developers to offer Linux support.

I hope we’ll see more ports of open-source Windows VST plugins too, but for anyone developing a new open-source synth plugin, or working on a plugin version of an existing standalone synth, LV2 makes much more sense. Regardless of how open-source they may be, VSTs that rely on Steinberg’s headers will never be allowed in to distributions. With David Robillard’s new LV2 stack, which is already in use in both Ardour and Qtractor, LV2 is a fast, reliable, and highly capable standard, and its use will only increase, regardless of what happens with native VST support.

a week-and-a-half with GNOME 3

I’m as surprised as anyone to admit it, but I’ve spent the last using GNOME 3, and it hasn’t been too painful — in fact, I’ve had no trouble remaining productive in it. I’ve definitely missed some of GNOME 2′s features, but it’s definitely been a more pleasant and productive experience than my time with Ubuntu’s Unity desktop after the 11.04 release.

A lot of people have reacted poorly to GNOME 3, and I can understand their frustrations. I’m not sure why I haven’t had the same experience, but perhaps my time with Mac OS X has something to do with it — I’m already used to using the Expose-style overview in the GNOME Shell, and to having Alt-Tab work on an application-level. There’s a new key combo for switching between the windows of an individual application; it defaults to Alt and whatever key sits above the Tab key in your locale (Alt-` in my case). It still took a bit of adjustment, but I was soon zipping between windows and launching applications without any dramas.

GNOME Shell's overview provides quick access to your applications and windows

The GNOME Shell cheat sheet covers a lot of the less obvious functionality built in to the Shell. I do find some of the hidden functionality a bit silly — having to hold Alt to reveal the “Power Off” menu item, for instance — but it still doesn’t take long to come up to speed.

I will add one caveat to my comments: I’ve been using GNOME 3 on my laptop, where (as I remarked a couple of posts back) I spend most of my time using Firefox, Chrome, Thunderbird, terminal windows, and a text editor. I haven’t used it with JACK and my regular assortment of music tools yet, so I’m still not sure how it’ll handle that workflow, or if its greater use of video hardware is going to cause any latency issues.

A quick reality check, nine years in the making

One thing I can’t help but feel in the release of GNOME 3.0 is a sense of history repeating; after all, it’s not the first major release of GNOME to slash away at the desktop’s feature set and remodel the remains based on design principles put together by a core team of developers.

Red Hat Linux 8, with the then-new GNOME 2.0. I'd forgotten how much like a browser Nautilus looked

GNOME 2.0 had substantially less functionality and configurability than the 1.4 release that preceded it, and it imposed a set of Human Interface Guidelines that described how user interfaces should be designed. I think you’d have a hard time finding someone today who’d claim that those changes weren’t for the best in the long run, but at the time, the streamlining was considered too extreme, and the HIG was controversial.

I think we forget just how much was missing in GNOME 2.0, partly because it’s been so long, but mostly because all of the really important features have found their way back in. To remind myself, I took a look back in time: I installed Red Hat Linux 8 in a VM and fired up its default GNOME 2.0 desktop.

The configuration dialogs in GNOME 2.0 did actually cover some options that are currently missing in GNOME 3, such as font and theme settings, and its panels had greater flexibility than the GNOME Shell’s single top panel, thanks to the bundled selection of applets. However, there were surprisingly few applets that provided functionality that hasn’t been incorporated in to GNOME 3 in some way.

Even this minimal window settings dialog from Red Hat 8 wasn't an official part of GNOME 2.0. A complete window settings dialog was added in the next release, GNOME 2.2

Leafing through the release notes for the subsequent GNOME 2 releases showed how quickly some of its missing functionality came back, and just how much the desktop has been polished over the years. While GNOME 3 throws away the visible desktop components, there’s a lot of GNOME 2 still in there, from the power, disk, sound, and networking management infrastructure through to its many tools and utilities.

GNOME 3.0 is a little different from GNOME 2.0 in that it changes the basics of navigating your desktop, and the developers have so far resisted requests to relax those changes. I’m still sure that it’s going to improve rapidly, though, and I do think that its developers will take the various criticisms on board. I don’t expect any dramatic design reversals, but I do expect improvements and refinements that will make GNOME 3 a viable option for many of the users that find it frustrating today.

switching back: the 2011 macbook air

UPDATE: I’ve just posted some updates on the state of Ubuntu on the 2011 Macbook Air.

With my old Dell laptop starting to suffer some physical wear and tear, I figured it was time for an upgrade. I couldn’t find a solid PC laptop that fit my needs, particularly in terms of portability and battery life, so I made a potentially controversial decision — I chose the brand-new 13″ Macbook Air. I won’t be using it for music-making, but after using it for work over the last week, I’m definitely happy with my choice.

I had sworn off Mac laptops for a few reasons: Apple’s power supplies and slot-loading DVD drives have always given me trouble, and my Macbook Pro ran very hot at times. Thankfully, the new power supply design seem less fragile, the Air has no DVD slot to worry about, and while it does howl a bit when working hard, that’s preferable to getting super-hot.

It’s also surprisingly quick — its 1.7Ghz i5 CPU outpaces even my 3Ghz Core 2 Duo desktop, and the SSD makes everything feel snappy. The Intel video isn’t brilliant, but it’s fast enough for most indie games, and even for a bit of Civilization IV or Left 4 Dead 2 on low-quality settings.

The Air’s fixed hardware is definitely a departure from my easily-serviceable old Dell, but it does help it to fit both a powerful system and a lot of battery in to a very light and slender frame. I wouldn’t want it to be my only computer, but it’s great as a portable extension of my desktop and home network. I’m sure I’ll have to give up the whole machine if it ever needs repairs, but with Time Machine backups configured (using my Ubuntu file server), I don’t really have to worry about losing data.

Mac OS X is, well… it’s Mac OS X. It has its advantages: it’s very well tuned to the hardware, making the most of the multi-touch trackpad, resuming from suspend in a second or so, and lasting a good seven hours on battery with a light load. It’s also great to have access to things like Steam. On the other hand, it’s still a bit annoying as a UNIX compared to Ubuntu, the Mac App Store is a shambles, and having to hack the OS just to stop it opening iTunes when I press my keyboard’s “play” key is completely asinine.

However, the reality is that I spend 99% of my working day using Firefox, Chrome, Thunderbird, a text editor, and a bunch of terminals, and Mac OS X meets those needs just fine. (For the record, I’ve been using TextWrangler and iTerm2.)

Ubuntu on the 2011 MBA

Ubuntu running, in a fashion, on the 13" 2011 Macbook Air

The Air can run Linux, too, though it’s not terribly usable yet. The trackpad works in mutli-touch mode after some hacking, but there’s no power management, and the Intel driver doesn’t work with the built-in display, so you’re stuck with unaccelerated 1024×768 video. The wireless works, too, which makes it unique among current Mac laptops, though only in 2.4Ghz mode.

I generally think it’s a bad idea to buy a Mac to run Linux, since the hardware is odd enough to cause these kinds of problems, but it’s always nice to know that I can run it if I need to. There’s a thread on the Ubuntu forums with all the details, and one post in particular that has a script to install patched keyboard and trackpad drivers.

some early ardour 3 impressions

Ardour 3 is now in alpha, and I’ve been poking at it for a few days now; in fact, you may have noticed some bits of Ardour 3′s GUI in the screenshot from my last post. It’s still quite crashy, as you’d perhaps expect from an alpha, but that seems to improve with each new release. In fact, going back to Ardour 2 already feels uncomfortable, because the Ardour 3 interface just feels nicer to work with, even before you consider all the new features.

The MIDI functionality takes a little getting used to, but once you’ve learned a few keyboard shortcuts you can quickly jump between working with MIDI and audio at the region level, and working with the individual notes within regions. I still think I’d be more comfortable if the piano roll was in a separate window, but once you’ve resized your MIDI track and adjusted the range of notes it displays to match your needs, it’s really quite easy to draw in notes with the mouse.

Being able to manipulate notes easily with the keyboard is great, too; once you’ve learned the appropriate shortcuts, you can move between notes and edit their pitch, duration, and velocity using the keyboard. Editing velocity in general is a bit strange, though, since there’s no velocity ruler — velocities are represented just by note colour, though hovering the mouse over a note will tell you its velocity value.

I did run in to a few problems beyond simple crashes, but I’m still pretty confident that Ardour 3 will be pretty solid by the time of its final release. I’m not sure it’ll eclipse other sequencers, like Qtractor, in that first final release, at least not in some ways (I do like having a velocity ruler, for instance). That’s just fine, though — Ardour 3 works just as well with external sequencers as Ardour 2 ever did, and its features extend far beyond simply adding MIDI.

back from the break

It’s a new year! I’m back at work this week, after too short a break, but I decided to keep my leave days up my sleeve for later on in the year rather than use them now. It’s always problematic heading off at the same time as other people, anyway, so I’d rather wait until I can take time off while others are around to cover me as much as possible.

It wasn’t a long break, but it was good, even though I didn’t feel great for much of it. I was hoping to get the track that I’m working on finished by the end of 2010, and that didn’t happen, but I had time to relax between hanging out with friends and catching up with the family. I also got some great Xmas loot — as well as a bunch of fun stuff, including Thinkgeek’s synth T-shirt (with actual working synth keyboard), a super-cute Android plushie, and some totally awesome GLaDOS core module plushies (which talk!), I got the very practical and awesome Korg nanoKONTROL MIDI controller, which I’m sure I’ll talk about more in the future.

Last year’s New Year’s resolution of sorts was to write at least one proper song with lyrics, and while I didn’t quite get there, that is what I’m working on at the moment, so it’ll definitely be done by the end of this year! I did release four tracks and one cover, though, so I think I did okay. I still don’t have lyrics finalised for the new track, but the backing track arrangement is mostly done now, so once I have the lyrics it should all come together pretty quickly.

some daw notes: mixing in qtractor, and testing ardour 3

So far, I’ve been using Qtractor for all of the recording and sequencing on the track I’m working on. As an exercise, I’m going to try to stick with Qtractor throughout the mixing process, too. I’ve used different synths and sequencers on different tracks over the last 18 months, but everything has been recorded in to Ardour at some point, so I think it’ll be good to put it aside for one track to see how the other half live.

I’m certainly happy recording MIDI in Qtractor, but it doesn’t yet feel as robust as Ardour for recording audio. It’s working fine, though, so I might get over that initial feeling once I’ve used it a bit and built some confidence in the fact that it’s not going to keel over at random. One thing I haven’t found a way to do, though, is to use a shared reverb bus, as I do in Ardour (as discussed in my last tutorial). It hasn’t been a problem yet, since I’m not using much ‘verb yet, but it will definitely be a problem if I decide to use a convolution reverb later.

Qtractor's new quantise dialog, with percentage options

One very nice thing that’s landed in Qtractor SVN is percentage quantisation, which lets you bring your MIDI notes just part of the way towards being perfectly quantised; it’s a great way to tighten up the timing of a recorded MIDI part without completely eliminating those nice, human timing variations. I described it to Rui on the LinuxMusicians forum the other day, and to my surprise, he had it written, working, and committed to SVN by the very next day. Now that’s service!

Ardour 3′s non-MIDI improvements

I’ve also been testing Ardour 3 from SVN, and I’m very, very happy with how it’s coming along; both its stability (ie: its ability to run for more than five minutes without crashing) and its reliability (its ability to do what you tell it to do in a consistent, repeatable manner) have increased dramatically over the last few months. My good friend (and guitar/drum extraordinaire) Stuzz gave me a link to a list of Ardour 3′s new features, which is an excellent read — going through the new features, which are all described in great detail, it quickly becomes clear that there’s a lot more to Ardour 3 than just MIDI sequencing.

Internal sends to aux buses make shared reverbs even easier in Ardour 3

One thing I noticed quickly is that it handles reverb buses very well. Setting up the bus is much the same as it is in Ardour 2, but once it’s there, adding sends to your tracks takes just a few clicks, and each send has a tiny gain slider next to it in the track’s effects list, so you can adjust your send gain straight from the mixer. The sends are also given meaningful names, now, so you know which bus they’re sending to at-a-glance.

Another nice change is what’s being called the matrix router, which is used whenver you need to connect Ardour’s inputs and outputs (audio or MIDI) to external apps or devices. The dialog for this in Ardour 2 was a bit cumbersome, and I know more than a few users that used an external tool like Patchage to connect things to Ardour. The matrix router, while initially a bit of a confusing sight, makes it much easier both to see what’s connected to where, and to change those connections.

…and the MIDI stuff, too

MIDI editing is done a little differently than in some other apps, but it’s not totally dissimilar to apps like Qtractor, and it follows Ardour’s audio editing model very closely. MIDI regions work much like audio regions — you can copy and drag them around and trim them to length with ease. By default, copying a region makes a “linked” copy, so editing a region changes every copy of that region; if you do need to edit one specific copy of a region, you can “fork” it to create a duplicate that can be edited independently. Speaking of editing, it happens inline — that is, within the main Ardour timelilne window, rather than in a pop-up — which seems odd at first, but it works well enough once you expand your track vertically.

Editing the contents of a MIDI region in Ardour 3 SVN

You can use instrument plugins, too. When you create a MIDI track, it starts with just a MIDI input and output, but if you add an instrument plugin it spawns a matching set of audio outputs, which can be routed just like the outputs of a standard audio track. It also has the best automation implementation I’ve seen on Linux; Ardour’s traditional plugin automation works on instrument plugins on MIDI tracks, and you can also draw automation curves for MIDI CCs. One catch right now is the lack of DSSI support — Ardour only supports LV2 plugins for now, along with VSTi plugins in VST-enabled builds, and AudioUnits on OS X.

Paul Davis wisely warns in his description of Ardour 3′s MIDI features that since this is Ardour’s first attempt at MIDI sequencing, we shouldn’t expect Ardour to necessarily to everything as good as, or better than, other apps that have been working with MIDI for years, and I think that’s very fair. I don’t expect people to dump Rosegarden and Qtractor en masse just yet, since there are certainly features that Ardour 3 lacks. Overall, though, I think he and his team have done a brilliant job, and I think Ardour 3 will have more than enough MIDI functionality to cover most of my projects.

blag updates

Over the last few months I’ve been trying hard to add more detailed and interesting content to this site, beyond personal opinions and the usual ramblings; essentially, I’ve been trying to treat this whole blogging thing with a bit more professionalism, and I hope that comes through in my writing. With that in mind, I’ve been making some changes to the site itself as well. Most of the changes are minor, such as adding a “related posts” feature, and the “recent posts” box over on the right, but there’s another, more significant addition to that right panel: ads.

I’m just serving some Google ads, as you’d see on a lot of other sites — I hope they’re subtle enough not to be annoying, and I hope they’ll be relevant and interesting, but given the various niches this site inhabits, I’m not completely convinced of that yet. You can consider this a trial, since if they haven’t done a lot after a month or so of being on the site, I’ll likely ditch them. I’m also looking at Amazon’s affiliate program, which might be a better fit for me given how often I discuss audio hardware.

Ultimately, I write this content because I want to, not because I think it’ll make me rich. It’d be nice to make a few bucks here and there to help with hosting costs, but I don’t want to do it at the expense of my readership or my credibility. If anyone has any thoughts on what they do and don’t find acceptable, or any experience in working with either Google or Amazon, I’d love to hear it!