Pure Data is a wonder: a free and open source environment for creating your own musical and multimedia creations with graphical programming, from Miller Puckette, the original creator of Max. You can produce everything from interactive sequencers and drum machines to synths to video performance tools by connecting patch cables visually, and you can run on virtually any platform, from BeagleBoards and Rasberry Pi to Mac, Windows, and Linux desktop. Via libpd, you can target other development languages and environments, embed engines in games, or work with Android and iOS.

It’s so important, in fact, that CDM invites Hans-Christoph Steiner, one of the key developers of Pd-extended, to give us a tour of what’s new. (Note: because Pd-extended includes various additional objects or “externals” that Pd Vanilla lacks, you should be careful when building patches for libpd. What I like to do is use Pd-extended as my editing environment, then double-check patches by opening them in Vanilla to make sure I haven’t accidentally used an object that’s not part of the bare-bones version. I can then substitute an object, copy an abstraction, or if necessary build that external.) -Ed.

The Pd-extended 0.43 release has been brewing an extra long time, about 18 months now, mostly because there are lots of big improvements. We wanted to make sure we got it right, so your patches all work, but the improvements all shine, so its taken a while. It’s now solidly beta, so we’re looking for testers. Download a beta build to try here:

http://puredata.info/downloads/pd-extended/releases/0.43.1

First off, the pd-gui side of Pd has been rewritten from scratch. The focus for most of the recent work has been on the editing experience, making your patching experience as productive and flexible as possible. To give some background, Pd has always been made up of two programs: pd is the core engine and pd-gui is the GUI. Since basically all computers now come with multiple CPU cores, this means that pd-gui will usually run on a separate CPU core than pd, so they don’t step on each other’s toes. pd can entirely take over its own core. If you want to make your patch use more CPU cores, then check out the [pd~] object introduced in the last release, but fine-tuned in this one.

There are so many ideas for making a better editing experience in Pd; this release makes big strides to address the editing experience. There are new features like Magic Glass, Autotips, Autopatch and Perf Mode, all available on the Edit menu.

• Magic Glass lets you magically see the messages as they pass through the cords. Just turn it on and hover above a cord, and you’ll see the messages as they go by. You can even look at signal/audio cords.
• Autotips gives you tips about what an object does, what its inlet expects, and what comes out of the outlets.
• Autopatch mode automatically connects objects as you create them.
• Perf Mode, is a mode for performance that makes it harder to accidentally close windows that are part of your performance.

A whole new Pd Window

The Pd Window is also majorly overhauled. First of all, it’s fast. Much much faster than the old one. You can now print thousands of messages per second to the Pd Window and still edit your patch. No more will an accidental dump of info cause the GUI to freeze up (well, okay, maybe if you send 10,000 messages/second, but that is way too many). There are also five levels of printing messages to the Pd Window: fatal, error, normal, debug, all. If you are only interested in fatal errors, switch the Pd Window to 0 – fatal, and you’ll only see the worst problems. You want to see every single message to debug? Switch to 4 – all, and you’ll drink from the firehose.

There is also the new log library, which lets you easily send messages for those different levels. And all messages logged with the objects from the log library are clickable: when you Ctrl-Click or Cmd-click (Mac OS X) on the line in the Pd Window, it’ll pop up the patch where the message came from, and highlight the specific object that printed it. That even works for many messages from other objects, as well.

The Pd Window also includes very basic level meters for monitoring the input and output levels. And for those who want to play with the GUI in realtime, you can type Tcl code in the Tcl entry field, and directly modify and probe the running GUI.

Customize the GUI with Plugins

One thing that you can do now is customize the GUI using GUI plugins. You can change all sorts of colors, some fonts, and many behaviors. Want to create a new object when you triple-click? Try the tripleclick example plugin Want to make the patch cords disappear when you leave Edit Mode? Check out the “only show cords in edit mode” example. Those are the simple ones. There is also Tab Completion, a search engine for the docs, a category browser for the right-click menu, a buttonbar for creating objects, and more.

You can find many GUI plugins in the new section of the downloads page as well as documentation for making your own. (What kind of GUI plugin will you write?)

Write Pd objects in more languages

Traditionally, Pd objects are written in Pd (abstractions), C and some in C++. This new release includes two “loaders”, Lua and Tcl, which allow you to write regular Pd objects in either Lua or Tcl. Pd is not the best for processing strings, so if you need to do that, you can now easily use Lua or Tcl, both very easy scripting languages for working with strings. Lua is often used for OpenGL work, so you can also run Lua objects to work in conjunction with Gem. Also, the Tcl loader lets you write GUI objects in pure Tcl, no C needed.

Multi-processing, Pd-style!

The [pd~] object now works out of box. In case you missed the introduction of the [pd~] object in the last release, we’ll introduce you now. [pd~] is Pd itself incapsulated into an object. You can run any patch inside that instance of Pd, the difference is that the Pd in the [pd~] object runs in a totally separate process. So if your computer has multiple CPU cores, which basically all computers do these days, then the Pd process inside the [pd~] object will run on a separate core. This means you can have a heavy Pd patch spread across multiple cores or CPUs. Or for people who work with video and audio together, you can have one instance for video running at a normal priority, then another instance for audio running at a high priority to make sure there aren’t clicks in the audio caused by heavy video processing.

Autotips, generated from help patches

This release also provides a new “autotips” feature to provide instant information about objects and their inlets and outlets. It is one of the first new developments to showcase all of the meta data that is now included in all of the help patches. (Check out the [pd META] subpatches.) When you hover above an inlet or the object itself in Edit Mode, you’ll see a short text description pop up on the lower left corner. But, of course, using a GUI plugin, you could customize how they are displayed to make it how you want to see it. If you want to add autotips to your object, then just add a [pd META] subpatch to your objects’ help patches, and fill out the description, etc. Voila! They’ll have instant information.

What’s next?

The core pd process still handles a lot of the GUI stuff, but we are working on splitting that out for the 0.44 release. That is a big chunk of work, but it will also bring big gains. In particular, it means that it will be possible for people to write their own GUIs for Pd, covering not just the display of the patch, but also the editing, and everything else. You like OpenFrameworks, Python, iOS, JUCE, Qt, etc.? Write your own pd-gui using the toolkit of your choice. That’s the idea at least. That will take a solid chunk of work, so we are looking for people to join that effort.

Try it yourself:

http://puredata.info/downloads/pd-extended/releases/0.43.1
http://puredata.info/downloads/pd-extended

Where to learn Pd:

Resources to start learning

-Hans-Christoph Steiner for CDM

Electronic music making has had several major epochs. There was the rise of the hardware synth, first with modular patch cords and later streamlined into encapsulated controls, in the form of knobs and switches. There was the digital synth, in code and graphical patches. And there was the two-dimensional user interface.

We may be on the cusp of a new age: the three-dimensional paradigm for music making.

AudioGL, a spectacularly-ambitious project by Toronto-based engineer and musician Jonathan Heppner, is one step closer to reality. Three years in the making, the tool is already surprisingly mature. And a crowd-sourced funding campaign promises to bring beta releases as soon as this summer. In the demo video above, you can see an overview of some of its broad capabilities:

• Synthesis, via modular connections
• Sample loading
• The ability to zoom into more conventional 2D sequences, piano roll views, and envelopes/automation
• Grouping of related nodes
• Patch sharing
• Graphical feedback for envelopes and automation, tracked across z-axis wireframes, like circuitry

All of this is presented in a mind-boggling visual display, resembling nothing more than constellations of stars.

Is it just me, or does this make anyone else want to somehow combine modular synthesis with a space strategy sim like Galactic Civilizations? Then again, that might cause some sort of nerd singularity that would tear apart the fabric of the space-time continuum – or at least ensure we never have any normal human relationships again.

Anyway, the vitals:

• It runs on a lowly Lenovo tablet right now, with integrated graphics.
• The goal is to make it run on your PC by the end of the year. (Mac users hardly need a better reason to dual boot. Why are you booting into Windows? Because I run a single application that makes it the future.)
• MIDI and ReWire are onboard, with OSC and VST coming.
• With crowd funding, you’ll get a Win32/64 release planned by the end of the year, and betas by summer (Windows) or fall/winter (Mac).

I like this quote:

Some things which have influenced the design of AudioGL:
Catia – Dassault Systèmes
AutoCAD – Autodesk
Cubase – Steinberg
Nord Modular – Clavia
The Demoscene

Indeed. And with computer software now reaching a high degree of maturity, such mash-ups could open new worlds.

Learn about the project, and contribute by the 23rd of March via the (excellent) IndieGogo:

http://audiogl.com

There are plenty of reasons to consider free software tools as part of your toolchain for music making. They might fit your budget, give you needed flexibility, allow you to use a tool driven more by development needs than commercial ones, give you tools that would otherwise lack proprietary commercial niches, allow you to run (via Linux) on a wider variety of hardware or with greater low-latency performance, or allow you to contribute more directly to a project, from documentation to actual development. And increasingly, they don’t mandate some sort of philosophical choice, either – I routinely use free software tools on the proprietary Mac OS, and use commercial, proprietary projects (Renoise) on Linux or (Harrison Mixbus) to make free projects more powerful.

What usually holds people back from free software projects is, simply, not knowing where to begin. Software in general can overwhelm with choice; free software, often, doubly so.

Fortunately, some software gurus have jumped into the legwork so you don’t have to. I have some of my own thoughts on how to put this together, but first I wanted to share the input of these esteemed colleagues. These aren’t all Linux-only – many run on Windows and Mac, too – but if you are looking for a way to put together a robust studio on Linux, they’re a great start.

Webcast, Software Picks, Knowledge Databases

If you like real-time feedback, today, you can join Red Hat’s Adam Drew in a live webcast for “Open Your World,” entitled “Making Music with FOSS.” [Free and Open Source Software] It runs at 11:00a Pacific / 2:00p Eastern, and will be archived. (I’ll update that link here.)

Learn to make open source music–Register now for a webcast with Adam Drew

Warning: I just discovered that this thing pops up an annoying survey that assumes you use JBoss. (And, heck, CDM is indirectly a Red Hat customer – the whole site runs on RHEL.) Trying to tell it you don’t use JBoss makes the whole survey fail. I’m going to try to schedule something separately, as this is … more than a little ridiculous for a music-making survey, and sadly shows Red Hat’s blind spot in regards to end users.

Day job in tech, night job in music making – yup, that’s the M.O. of quite a few people around this community.

I asked Adam for his top picks, and he explained he would demo:

• JACK / qjackctl (the GUI for JACK), the tool for interconnecting audio, MIDI, and sync between applications
• Hydrogen Drum Machine
• Ardour, the terrific, all-free DAW
• Rakarrack, a free guitar effects tool set for Linux (one new to me, in fact!)
• ZynAddSubFX, probably the most capable free standalone soft synth – ugly, but very powerful, and a candidate for a “desert island” synth.

For additional resources, there’s a superb guide on the Fedora site (one that Ubuntu actually might mirror). It’s Fedora-focused, but the advice often applies to other distributions:
Fedora 14 Musician’s Guide

Adam himself operates the FOSS Audio KBase, full of articles on configuration and individual software programs. It’s about the most productive guide I’ve seen:
FOSS Audio KBase

Adam has some more philosophical thoughts:
Webcast preview: Free and open source software for music production [opensource.com]

And you can check out Adam’s music (CC-BY-NC-ND) and Linux-oriented personal blog. I tend to be more pragmatic about some of these issues, so I’m not endorsing all the opinions on Adam’s blog, but it’s a compelling read, and often comes with useful practical advice. (Mainly – I disagree with two points, one, I don’t think it’s entirely fair to say that proprietary DAWs lack interoperability, and two, I’m far more pragmatic about the future of Android as a platform, mainly because I think it’s currently the best bet for the distribution of free software on mobile. Oh, I don’t trust Google, either, though – that’d be silly.)

Picks from Dave Phillips of Linux Journal

Last weekend, I had the pleasure to meet Dave Phillips for the first time. Dave, an Ohio-based musician and teacher, is bar none the most invaluable writer when it comes to free software and music-making on Linux. His series for Linux Journal in particular is a must-read.

Dave and I joined Columbia’s Brad Garton at Virginia Tech to do a bit of teaching, a bit of playing, and to enjoy the hard work of the Linux Laptop Orchestra. I’ll cover more of that soon, but in the meantime, I took some notes as Dave walked through a current take on the software for Linux that most excited him.

His picks:

• Ardour, naturally
• Ardour 3, the next-generation update to Ardour that at last adds MIDI support (and beautifully executed). Dave noted that you can and should install Ardour 3 alongside the stable Ardour, so you can test both. There are even pre-built alpha binaries, so there’s really no excuse: you could be up and running in less than the time it took to read this. (See a much earlier story from Dave on testing 3.)
• Harrison Mixbus: It’s not free software, but it is now Linux-native and supports Linux plug-ins, and it’s built on Ardour (and, in turn, contributes back to Ardour). As Dave put it, Mixbus is a mind-boggling value “from a company that thinks of a budget console as costing $100,000.”
• IR: LV2 convolution reverb. The work of Tom Szilagyi, IR is a brilliant, no-nonsense plug-in for powerful convolution effects; LV2 support means it runs beautifully in hosts like Ardour 2.8.x and higher and Renoise. I’m really grateful to Dave for turning me on to this one. woo, tangent has a nice blog entry on the plug.
• LV2, generally. Dave credits the evolving state of LV2, and the work of its principle developer, David Robillard, for a lot of innovation in free software and Linux audio. I’m surprised LV2 hasn’t gained more attention, in fact – it might be the best bet yet to finally help plug-in developers escape the shadow of formats like VST. But that’s probably a topic for another article.
• RubberBand Audio Processor Powerful time stretching tool, now on Linux, Windows, and Mac OS. Available as a library, too, if you’re a developer – or just use it to mangle your audio files as an end user. Someone has already ported it to Renoise.

The focus of Dave’s presentation, though, was one tool so deep, it could easily be your only tool, for the rest of time. AVSynthesis couples visual output in OpenGL with the veritable Csound sound and composition engine. It includes built-in sequencing capabilities, basic sound generators (themselves written in Csound), envelopes and modulation, the powerful MatrixSynthMod instrument, MIDI control, and effects (phasers, choruses, filter, waveguide filter, and so on). There’s shader support on the graphics side, too. The result: based on built-in building blocks or, if you’re adventurous, your own code, you can produce 3D audiovisual musical-eye candy performances. I hope we’ll take more look at this soon; the one question that came up repeatedly – and that Dave couldn’t answer yet – was what the workflow might be for adding your own Csound creations. (The package itself is built in Java.)

More information:
http://www.avsynthesis.net/
AVSynthesis: Blending Light and Sound with OpenGL and Csound5 [Dave in Linux Journal]

AVSynthesis Tour 1

Composing With Csound In AVSynthesis [Dave in Csound Journal]

Lest you think we’re all a bunch of “neckbeard” Marxist free software revolutionaries, though, Dave – who’s had drinks with Stallman on occasion – was also full of questions about Mac OS and curious about it for his own music making. I think largely we’re all technologically curious; if anything, the only people I’ve met who have gotten really emotional are the people who mistrust free software, perhaps because they just need to loosen up and accept that something really can be free.

But as with proprietary software, I think the biggest danger with Linux and free software is that you can become overwhelmed with choices rather than focusing on music. That’s part of why I find these choices so appealing: deep, capable, well-designed, and rock-solid, I’ve found them to be eminently musical. Some of the best demonstrate that free software can provide choice – not, as many believe, only compromise. And I see absolutely no reason that they can’t coexist with other popular proprietary options in your studio. You may not be ready to leap into Linux, but especially given that by now you’ve likely accumulated either extra machines or machines that can easily dual-boot, there’s no reason not to add these free tools to your arsenal.

Got favorites of your own? Let us know; I’ll continue to feature this stuff in coming days.

Musicians and artists now have the power to fuse visuals, sound, and interaction, to make a spectacle, an album, and a game all at once. But with the blank canvas of three different media before you, what form should that fusion take?

Space shooters with pounding electronic beats behind them have cleared some of the way. Now it’s ambient music’s turn. In the game Osmos, you become a mysterious particle, floating amongst gravity wells in various fields of material. By carefully navigating, applying just the right vector force to move through the shifting landscape, you merge with other particles and escape to safety.

http://www.hemispheregames.com/osmos/

The move from “shoot stuff” to “move” or “eat” seems to be rising in popularity, with games like fl0w and Spore’s initial “cell stage” encouraging nonviolent navigation. To me, there’s something happening to the zeitgeist, perhaps a renewed awareness of cosmic (micro- or macroscopic) being, and of movement that draws on free-floating physics.

Even amongst a wave of games in this mode,when you actually play Osmos, you realize that it is something different and special. The design makes ingenious use of different kinds of movement and pacing through its different modes, at one point calling upon you to hurtle around a black hole, then move at nearly imperceptible speeds through a seemingly impossible-to-traverse petri dish of massive particles. No less than a shooter, it connects to the id and survival instinct. Pac-Man, the most successful arcarde game of all time, and one of the few that sucked in men and women in equal measure, was noted for its emphasis on eating as the mechanic. Consuming stuff appeals to everyone.

Of course, this is on a music site, and with good reason: what makes Osmos work is that Osmos is musical. It’s immediately beautiful and delicate, a perfect aesthetic union of the texture of the music and the on-screen arrangements of particles. More importantly, the music is woven directly into game play, providing subtle cues for dangers, and underscoring the pace of gameplay. You can only solve a level by managing speed and motion, and the music helps provide both the literal indications of speed and help your head get into the right zone to lose yourself in the world. If blips in early arcade games helped create a zone of play trance, now we have spectacular ambient soundtrack of music by Loscil, Gas/High Skies [Microscopics], Julien Neto, and Biosphere.

The music isn’t simply a beautiful soundtrack to the game. The game really feels like an extension of the world of the music. Put it all together, and something magical happens in this $10 game: you hear the music in a new way.

I spoke to the lead designer behind the game, programmer/animator Eddy Boxerman, along with musical-sonic collaborator Mat Jarvis aka Gas aka High Skies.

Peter: I found it amusing that some of the game press have stumbled around looking for a name for a new genre here, the "eat other stuff" category. To me, the basic game controls could be traced back to early titles like Asteroids. What are the games that have inspired you, either specifically or generally?

Eddy: Some people are dubbing the gameplay type as "eat ‘em up", as opposed to the classic "shoot ‘em up". But it’s true, the physics/controls have more in common with classic games such as Asteroids and Gravitar. The only "modern" game that otherwise influenced me was Katamari Damacy. It’s funny: when I sent out the first prototype to friends, I was concerned they would think the game was too similar to Katamari. That’s when I heard about flOw, which I’ve tried to steer stylistically clear of ever since. I guess it’s an archetype though, and the comparisons have been inevitable. As for Spore, Osmos was about one year into development when I saw the first preview footage of its "cell stage". On top of that, I learned that Will Wright had hired Brian Eno to do the music! I definitely had a "why should I bother?" moment at that point. But here we are, a couple years later, and I think we’ve managed to put out a unique game with a great mix of gameplay, sound, and visuals.

Peter: Ha – well, I’m glad you “bothered”! One thing that I think is really unique about Osmos is the gravitational mechanic. How did this come about?

Eddy: I was (and probably still am) a sci-fi kid. And when I read about real phenomena like colliding galaxies, retrograde planets, and the like, my mind goes to stange and wonderful places. That said, the Spacecraft Dynamics course I took during my engineering degree definitely played a large part in putting those mechanics and levels together. Thanks, Professor Misra!

Peter: How are the physical mechanics of the game constructed? This is essentially two-dimensional vector math, yes? Were there refinements you needed to make in order to keep performance up, or to keep the levels playable?

Eddy: That’s a big question! But yes, essentially it’s 2D vector math, though we make use of some 3D math (including quaternions) on the particle systems. The majority of the physics is quite simple though — first year bachelor’s stuff: F = ma, conservation of mass and momentum, gravitational laws, basic time integration, etc. We follow the spirit of the laws, but not always the letter. For instance, if you look at the Earth’s solar system in its entirety, you wouldn’t even see most of the planets; that doesn’t make for a very playable game though. As such, we took many liberties when it comes to scale, constants and exponents in the equations. The majority of the work was in the tweaking of those values to make the game /feel /good.

Peter: How did you prototype the game? What was the process of evolution like? Were there any failed attempts along the way?

Eddy: I put together the first prototype starting from a NeHe OpenGL tutorial. I added some basic physics, mouse controls, some highly unoptimised collision detection code, and voila, I had something to play with. After that, I immediately integrated [cross-platform 3D audio API] OpenAL, as the game was just begging for sound and music. I then hunted for some good sounds (discovering freesound.org in the process), put together a simple looping song (my first rough and humbling attempt to create digital music), and sent it out to a few friends. I’ll make that version available for free someday… when I’m feeling brave.

As for failed attempts, there were tons of shelved experiments and features that were cut. One interesting problem was the difficulty curve of the gravitational levels. In fact, the first gravity levels looked a great deal like the "Warped Chaos" levels do today: several free-floating Attractors in a sea of regular motes. I found it incredibly difficult, however, to make a "beginner" version of those levels. If the gravity was too weak, the Attractors had little apparent effect; too strong, and the level became incredibly difficult. I stuggled with this for a long time, until I hit on the idea of putting one, immobile Attractor in the center, with everything else orbiting around it. This allowed for the creation of systems with strong gravity effects, but long-term stability. It seems so obvious now, especially given the example of our solar system, but it wasn’t back then. In the end, these are some of the coolest levels in Osmos — practically its "signature" level type. Moral of the story: necessity really is the mother of invention.

Peter: What is the visual engine like? The sound engine?

Eddy: As I mentioned, I bootstrapped from a NeHe tutorial, but that’s all been replaced at this point. It’s now a homegrown engine using OpenGL. It doesn’t make any use of pixel/vertex shaders, so it runs on a wide variety of hardware. The majority of our texture work is done in Photoshop.

[The sound engine is] a wrapper we’ve built around OpenAL. At a basic level, all we ever do is mix and adjust the gain and pitch of our sounds and music. This allows us to run on generic sound hardware. But we do make extensive use of those "effects", and it’s possible to get a great deal of variety and feedback with them. In the end, it’s all about the quality of our sound sources, and the algorithms that adjust and smooth the gain and pitch of each.

Peter: For pitch shifting, were you able to do that natively in OpenAL?

Eddy: Yes, OpenAL supports pitch shifting at the software level. I ported our sound engine to use DirectSound at one point, and found that it’s pitch shift range is rather limited. We reverted back to OpenAL.

Peter: One thing that really strikes me about the game that is its use of pacing. Even without the obvious technique of allowing the user to control speed, there’s this extraordinary contrast between levels that require you to move quickly, that require you to anticipate the rate of movement along a vector of other objects, or that require you to move almost imperceptibly slowly. Was this an early goal, or something that evolved out of developing the game concepts?

Eddy: It evolved from the game concepts themselves. We tried to fully explore the fundamental controls and game space of Osmos, and converged on a number of interesting regions and structures that were fun to play with/in. Some people actually "complain" that the pacing of the game isn’t consistent across levels — some are fast, some slow — but that wasn’t our goal. In a sense, we’re merely presenting the results of a great deal of research and exploration into the space, with our sole requirement being that the levels are fun and interesting. We wanted it to be a game of concepts and understanding, not speed. The addition of time-warping allowed us to break free from that, expand our scope, and include a much larger variety of levels, as some have both fast and slow moments in them; we wanted the player to be able to control the pace and difficulty to their level of comfort.

Peter: Connecting the action to music, how important is the use of music in conveying time?

Eddy: I think pitch-shifting the music and sound effects helps players track time-warping in an inutitive way. Without these aural cues, the mental connection would be incomplete. That said, I sometimes test the game without sound, and it’s totally playable — just much less immersive.

Peter: At what stage did you involve the musical element? How was that relationship established?

Mat: Eddy first contacted me two or three years ago about using one of my tracks on Osmos (“Gas – Discovery”). He sent me a basic alpha version where the game was literally flat circles on a plain background, but even back then with the simple graphics and no sound it was compelling. I think it was at this early stage that I sent him a copy of another High Skies track, “The Shape of Things to Come,” which he also used a section from. It wasn’t too long later that he sent me a version of Osmos with most of the music that made it to the release version and it all just complimented each other beautifully.

Eddy has done a great job choosing music that compliments the game and graphics, and they also compliment the music. I think he’s done a great job overall as well, keeping his vision consistent for the look and feel of the Osmos world. Even though some of the levels are quite varied; some are quite chilled, others fast paced, nothing seems out of place. He has created a new world that’s both microscopic and macroscopic.

Peter: The musical and sound effect elements really do blend effortlessly. Mat, I know you made substitute sounds – how did this help blend the aesthetic?

Mat: I made the rebound noise when you bounce off the walls/ boundary. The original sound was quite hard and metallic with a lot of reverb, and I suggested a softer echoey sound. There was nothing wrong with the original, but it made the boundary feel quite hard and cold like being in a metal tank. I sent Eddy some analogue samples, using a [vintage Roland keyboard] Jupiter 6 with varying delays/ echoes. Because the tones are so pure and tuned, Eddy pitched them slightly to fit with the various keys of the different music.

Eddy: In general, it was a matter of searching and experimentation for the "right" set of sounds that fit well together — which can be a lengthy but rewarding process. Once integrated, minor gain and pitch adjustments helped fit it all together.

Mat provided the bounce sound, as well as the continuous absorb/being-absorbed sounds. The other sounds were created/shared on freesound by the users Elektrocell, fran_ky and Jovica. (Check out the Osmos credits in the readme.html for details.)

Peter: I recently spoke to Crystal Method, and while they’ve done some notable game scores, they actually said they wouldn’t want their music to be placed in a game context at which the speed changed, that it’d lose something. This seems like the opposite of that. Now, maybe it’s easy to take for granted with ambient music as opposed to something beat-driven like Crystal Method, but do you think there’s something special that allows this music to be adaptive in that way?

Mat: I think that in the right circumstances music with drums could work well and may even highlight the time-shifting more. Of course with the wrong game and wrong music it could sound terrible too.

Eddy: It’s a delicate issue. Out of the context of the game, I think it would seem wrong. There were also some pieces of music I tried which didn’t lend themselves well to this kind of manipulation, and which didn’t get included as a result. But with these songs, and everything working together in-game, I feel the whole experience is stronger as a result. I’m just glad Mat and the other artists agreed — or at least… didn’t object.

Peter: Hey, I think if you can write music that sounds good played at a different speed, that’s nice.

Osmos seems to me a musical experience, in that the sense of the music is transformed by the visuals and the interaction with them. Do you think it’s possible that audiovisual interfaces could go even further in terms of their impact on the music?

Mat: Yes, it almost seems as though Osmos creates a world for the music to exist.

I’ve always liked music visualisers like the Processing and Cymatics stuff, they’re quite compelling to watch how they react to the music, so it would be interesting to go the other way; by manipulating/ sculpting abstract shapes which then modify or even create sounds and music, especially using the new controllers like the Wii, [Microsoft’s] Project Natal and Sony’s Motion Controller instead of the mouse.

Eddy: I totally agree with Mat. Yes, please! More feedback between music, visuals and interactivity — in all directions. I’d love to experiment more on all of these fronts. In general, I think games such as Audiosurf and Auditorium, while great, have only begun to scratch the surface of what’s possible. Interactive musical "toys" such as [Nintendo/Toshio Iwai’s ]ElectroPlankton or Dub Selector are another great direction; and Rock Band Network is about to expand the market in a huge way. It’s exciting!

Peter: Along those lines, this is obviously a new take on music distribution in a way that goes well beyond what titles like Rock Band have done. Are there other cases in game history that to you have done that? Is there potential in these new outlets, outlets that are more accessible to independent developers (Steam, Direct2Drive, Xbox Live Arcade, iTunes App Store), to really change game development?

Eddy: Wow, that’s another big question. Really, I just felt the music was such an important part of the experience in Osmos that we should show the artist and track names during the game. But now that you mention it, I can’t think of another game that has done this, besides games like Rock Band where the song /is/ the game/level. That said, one way I’d love to push this evolution is to "augment" music videos with interactivity: ie. into music video-games. (The term "game" could be used rather loosely here.) Everyday Shooter does this, though Jon Mak actually created the music /for/ the game in that case — which rocks — but collaborations could lead to some really amazing things in this direction.

Peter: Eddy, Mat, thank you. Whether it’s in the form of a game or an audiovisual performance, we’ll certainly continue to explore these areas. And – hint, hint – Osmos 2, with multiplayer? Just a thought.

Osmos Trailer from hemisphere games on Vimeo.

Processing 1.0 has finished final release status. Why that matters, on Create Digital Motion:

Processing: Revolutionary Creative Coding Tool Now 1.0, No Longer Beta

In my mind, it’s certainly one of the most unusual betas in creative software history. Why this is important for music:

• Recent versions of Processing include the very stable and wonderful Minim audio library
• Processing makes an excellent tool for creating unusual graphical front ends for music, with tools like Reaktor, Pd, Max, SuperCollider, ChucK, Ableton Live and many others handling sound (more on that in a story tomorrow)
• Updates make Processing far more predictable and flexible across platforms, particularly when using new versions of Mac OS, Windows, and Java
• Better, more stable OpenGL rendering makes your software look fantastic, and this is a lot of the change that’s happened in recent builds

But it’s better to show that rather than talk about it. Stay tuned. Look at me: still talking when there’s science to do!