Technology may be about the next Big New Thing, but as with music making in general, making music with tech is for many of us a lifetime vocation. So, it’s welcome news to find that time-tested tools, maturing over decades rather than months, are enjoying greater use than ever before. We saw Pure Data (Pd) attracting new interest as the embeddable libpd version allows use in a range of development environments and mobile platforms. Now, it’s about to be Csound’s turn.

Of course, before we get to that, if you’ve got an iPad 2 or “3″ (aka “the new iPad”), you can more or less skip this entire article and start making wild new granular sounds on your tablet. (Sadly, the original iPad is excluded here because it’s a resource-intensive application, though owners of that tablet – and other mobile devices – have plenty more to anticipate in Csound world.)

csGrain is a multi-effects processor that works its sonic-mangling magic live on sound, making use of something called “SyncGrain,” a real-time granular synthesizer. You can record from a mic or import tracks from the iTunes library (including, of course, your own music), or even use an included sample loop. csGrain then processes those sounds via a rich set of sonic tools, either live or to a recording, with sharing via AudioCopy, AudioPaste, email, and Dropbox. You also get setting randomization and a range of live effects, too. If you’re unsatisfied by the “finger against bathroom mirror glass” feeling of the tablet, you can connect an external MIDI input.

And, of course, it sounds amazing:

All of that is nice enough, but the bigger news is how this is all possible – and what is yet in store. Think Csound running everywhere, including learning about the tool and coding with it directly on an iPad.

csGrain uses Csound, the composition and sound design language that traces its roots back to the first-ever digital synthesis languages developed by pioneer Max Mathews. (It’s worth noting that Max’s ideas inspired the work of Miller Puckette on Pd and Max/MSP, too, meaning these are “all in the family,” as it were. Some even argue the model had an indirect influence on modular synths.)

csGrain is the first of a series of apps using Csound, including a massive, promising, everything-you’d-ever-want-with-Csound-on-an-Ipad app, covering documentation and code. This isn’t just an attempt to “cash in” on a geeky sound tool in the midst of the App Gold Rush — far from it. The application is as much a teaching opportunity as product. You’ll be able to use the application and its documentation to learn more about the sound processing technique, and discover the Csound code that makes the app tick. For some, it could be a first introduction to Csound, without having to be enrolled in an academic class. And for developers and sound artists who do want to make their own Csound creations, an upcoming SDK will unlock the power of Csound on other platforms (iOS being just one). That brings the power of “run anywhere” portability to text-based language Csound much as libpd has done for the graphical-patching tool Pd.

This image of a developer build of Csound Touch should be enough to set Csound fans’ hearts racing. (Okay, not a huge segment of the population at large, but I’m fairly certain most of them read this site.)

Developer Dr. Richard Boulanger, who has been a driving force behind almost every element of Csound’s recent development from the stuff under the hood to the documentation and the community, is now taking that sonic energy and applying it here. (And I do mean energy: sonic whiz “Dr. B,” as he’s affectionately called by his students, practically bubbles with enthusiasm and ideas. I’ll have what he’s having.)

He tells us that even in its first day, csGrain has made a big impact – no small task for an App Store inundated with volume and an application most would consider to be pretty niche in appeal.

The launch of csGrain has been pretty exciting. At the App Store, on day one, in the Paid Music Apps Catagory, we reached the rank of #8 (out of 4000+ paid music apps). We had over 957 people view the csGrain video at the Boulanger Labs site, and we were contacted by Richard Devine and Jordan Rudess with praise, congratulations and advice. We got some pretty great reviews at the App Store such as this one…. (I have no idea who this is by the way… which makes it even cooler….

“csGrain is a must-have effects powerhouse for the iPad. The sounds, usability, and musicality of the instrument are at least on par with the Moog apps, but the the potential for extension and customization far surpasses anything else. If you want to blow your mind in two seconds flat with this app, just press and hold any of the parameters (esp the sync grain ones) and a randomization window pops up, change the parameters and get instantly out of this world sounds. I really like the integration with Dropbox and AudioPaste functionality. And while you don’t need it at first, the manual is very well written for when you want to dig deeper. My only complaint is that the app is not yet in Retina-display, but I am sure that will be coming soon. Another nice feature improvement would be to augment the midi capability, which is already awesome, to allow for automatic learning of cc messages based on input like the way Ableton Live works. All in all, this is most powerful effects application on the iPad. Good job!”

I should also direct owners of the first-generation iPad to Richard’s explanation of why you can’t have the app:

It really doesn’t work on iPad1. It’s optimized for iPad2 and the new iPad. In particular, the stereo granular processing is both efficient and amazing, but… it’s also pretty heavy for the iPad1 and we would get some
breakUps in the audio on that platform – so we just made if for the 2 and the new.

But let’s get to what’s coming next. Dr. Boulanger gives us the full scoop. I imagine him sounding like Vince, the Slap Chop guy (and with good reason):

[Last week] was the release of csGrain (one of Boulanger Labs’ focused/targeted “spin-off” apps) and there are others coming over the next few months. But Csound Touch – which is coming in about 1 month – is ALL of Csound on the iPad…

The Csound for iOS API and SDK will be offered in the next day or two with all sorts of working models…
It will blow you away… how “easy” it is to develop audio apps with Csound as the DSP engine.

our .csd files are all offered with the apps.

One will be able to incorporate Csound into their own apps, games, whatever.

csGrain is just ONE huge .csd file – running under the hood… and there is a button there to see the code and it’s in the manual that is included too.

- we are sharing many tricks right there. But there are also tons of tricks shown in all the models that come with the SDK

Csound Touch IS Csound – all of Csound – for the iPad.

It is built upon and synchronized with the latest version of Csound5

It supports the realtime “rendering” of any Csound “.csd” file.

It can render .csd files from within the Csound Touch App or from the Internet.

It includes realTime “Console Output” (for diagnostics and progress monitoring) and supports “OFFline Rendering” for the realization of the most complex and demanding of “orchestras and compositions.” (For instance, if you wanted to create a sound with ten thousand oscillators and five hundred reverbs and two thousands filters it’s not a problem. This is Csound… all of Csound… and with Csound the only limitation is your imagination!)

Csound Touch supports Realtime MIDI control of any Csound-based MIDI instrument.

Csound Touch supports Realtime iPad/GUI Control of Csound Instruments via custom OnScreen Sliders, Knobs, XY controls and a Piano Keyboard.

One can Save to Disk or Render to the speaker or any pro audio interface in RealTime or once can do both Simultaneously! Jam and Capture! Remix and Record.

Csound Touch supports Interapplication File Transfer on the iPad Import/Export via DropBox, Email and AudioCopy.

To get you started with Csound; to inspire your creative spirit; and to support your study and exploration of Computer Music Composition, Software Synthesis, Signal Processing, Algorithmic Composition, Physical Modeling, and so much more…
the Csound Touch App includes:

Chapter 1 of Boulanger’s “foundational text” published by MIT Press – The Csound Book

The “classic” Boulanger Csound “Toots” from the Csound Manual

Boulanger’s “Mastering Csound” Tutorials

and there’s more!

We include the latest Csound FLOSS Manual (and all the Floss Instruments)
We include the Canonical Csound Reference Manual (and all the Manual Instruments)

and even more….

Selections from Boulanger’s Csound Instrument Catalog (30 years of Csound Instruments)
Selected Csound Compositions from the Boulanger Collection and The Csound Mailing List

Selected Algorithmic/Generative Compositions

A diverse and useful assortment of Dr.B’s favorite DSP Instruments
A varied collection of Dr.B’s favorite MIDI Instruments

A collection of OpenSource Audio Samples from the OLPC Sound Sample Archive.

Of course, this isn’t just about iOS: Csound is now in one form another either available or coming soon to Android, Ableton Live (via Max for Live), Max/MSP, standalone desktop applications, and the Mac AudioUnit plug-in format. I agree when Richard calls it “The Csound Renaissance of 2012.”

By the way, I think Richard has given those of us working on Pd, too, a real sense of what we could do with that tool (as well as an excuse to play with Csound anew). He tells us:

PS…. The Pd Rennaissance is also very very wonderful – the new book, the new code, the new possibilities…. all extremely exciting. After reading your blog on bit ago, I ordered the book and am very inspired by this initiative as well. So…. all cool and extremely important.

I couldn’t agree more.

So, once again, the timeline for the Revolution:

Coming soon (in a month)

Csound Touch – all of Csound on the iPad! Run any opcode, run any orchestra, run any composition. Run the entire Csound Book, Csound Catalog, Csound Manual. It all works and it’s all there!

and the a few weeks after that….

More Csound Apps such as:

csSpectral – Realtime vocoding, convolution, and spectral processing.

csFuzz – a rack of guitar effects.

csVoice – a vocal synthesizer, harmonizer, processor.

csGen – algorithmic, probabilistic, and generative composition systems.

csModel – a collection of Physical and Physically Inspired Models.

csClassics – a collection of synths based on the classic techniques – FM/AM/RM/WaveShaping/Granular/Additive/Etc.

The Revolution will not be televised, but it will be at:
http://boulangerlabs.com

You can find csGrain on our exclusive, multi-platform Apps section:
csGrain @ apps.createdigitalmusic.com

An, as always, don’t miss the central repository for all things Csound:
http://www.csounds.com/

We’ll have an interview with Dr. Boulanger later this week, so if you’ve got questions for him, ask away!

Users want more: that much is clear. But for years, Reason has famously (or infamously, depending on your point of view) resisted plug-in formats as a way of extending its production environment. At the moment, plug-ins have been dominate largely by Avid (RTAS), Apple (AU), and Steinberg (VST), as open source alternatives have failed to gain wide commercial traction. Those formats apparently didn’t make the cut with Reason.

That changed officially tonight. Reason’s rack is open to third parties, via something called Rack Extensions, previewed and available by summer for all Reason users. What you’re getting is not so much a new plug-in format as a new set of ideas about what a plug-in should be, in the form of a way of making add-ons for Reason alone.

The ability to get more out of Reason’s rack will clearly mean more for lovers of Reason, who at last will get some favorite sonic toys and tools without switching hosts. But how exactly do the specifics work? I spent some time with Ernst Nathorst-Böös, CEO of Propellerhead, as well as other developers working on the program to try to understand what it’s all about, and trying strange new green sauces known in Frankfurt. (Non mood-altering substances, mind. Just stuff you put on potatoes; don’t read too much into it. German cuisine.)

Before we get to that, though, here are two obvious take-aways for other plug-ins. To me, the benefit for the Reason community is pretty clear. But I think even for Propellerhead, the best thing that could happen here is if other plug-in formats follow the lead. Plug-in formats in general could work better than they do. It’s frustrating that they’ve made little progress since their introduction in regards to some obvious shortcomings, over a range of years. (Don’t believe me? Ask almost any plug-in developer, anywhere.) There are two obvious elements of the Propellerhead announcement that could mean something to competing plug-in formats (AU and VST in particular). Propellerhead aren’t the only ones complaining about them.

Note that given the nature of this being a fresh announcement, we haven’t yet fact-checked this with Propellerhead, and some statements here are interpretive or speculative. And, of course, some stuff is still in the works as this is developed. We’ll cover it as it evolves.

1. Plug-ins shouldn’t bring down hosts. One of the most important point Propellerhead made was widely misunderstood. The idea is this: when a plug-in crashes, the host shouldn’t crash with it. Now, the developers of Reason are obviously very proud of the stability of Reason, but that isn’t the issue here. However stable or instable your host is, the notion is that a plug-in shouldn’t be the reason that host crashes. Some effect you downloaded shouldn’t send your whole session toppling to the ground. Various forms of sandboxing can prevent this. We’ll have to test the Reason solution in practice, but in principal, I know of no reason every plug-in couldn’t support this basic notion. And even if you’ve seen Reason crash, as some commenters have said, the idea here is that a plug-in won’t be the cause.

2. Plug-in developers ought to be able to sell their stuff right in the host. This is a no-brainer. Set aside the obvious success story of Apple’s App Store on iOS and Mac. Plug-in developers have an impossible time these days just selling their work (or, indeed, even giving it away). It’s kind of bizarre that in the Internet age, no other host makes it easy to find and try out the work of other developers. (I was going to give an exception, but … there isn’t one. Seriously. What the heck?)

It’s pretty easy to make an extended argument for either of these ideas without talking about the Reason announcement. And I’m not trying to sell Reason here: believe me, I’d like to see other plug-in formats advance, too. Reason might want that, as well, since they rely on that same developer ecosystem. (Translation: they need devs making enough money to spend the time to keep making plug-ins … for anyone, not just Reason.)

As for Reason, here are some answers to frequent questions and comments from readers.

What will it cost? When can I get it? It’ll be free for existing Reason users, available by end of Q2 (beginning of summer, more or less).

Which add-ons will be available? So far, all we know is the developer list: KORG, SonicCharge (of uTonic and Synplant fame), Peff (Kurt Kurasaki), Softube, and Urs Heckmann (u-he). I also saw iZotope in the crowd, but make of that what you will. Props aren’t saying much more than that; other developers may be involved but aren’t yet public.

Will there be an SDK for any developer? I got a clear answer from Ernst on this: yes. Anyone will be able to download the SDK and make add-ons. There are a couple of caveats. First, you have to have an established business entity (in the EU, with a VAT ID / outside Europe, just some legal entity). Second, it’s just not ready yet. What we saw today was a technology preview, but Propellerhead says they’re eager to open this up to other developers; they’re just not quite prepared to handle that process yet. We don’t yet know to what extent the store you see in Reason will be curated or how, and I wonder if free add-ons might get around the need for a publishing business. What I can say is, there won’t be a developer fee.

Will hardware DSP be supported? Not at this time, or evidently in the forseeable future. Ernst emphasized that Propellerhead feels the current multi-core engine is sufficient. So, no Universal Audio add-ons — but remember, if you really want that, you can just ReWire Reason into a host.

Will you be able to make open-source plug-ins? This seems possible, given you can run DSP code. Your code is your own. I didn’t have time to get an official answer on this; I think it’ll be easier to look at once we can see the SDK.

Can you have UI elements? This came up in the press conference. There are some limitations in the “first release,” say Propellerhead. But there was an impressive demo from SonicCharge with a nice, animated visual display for Bitspeak; suffice to say, you won’t directly port VST UI code, but plug-in devs can work with what Propellerhead is giving them. It’s not so much having to deal with having a new plug-in format as having to work with some new UI requirements – and, quite frankly, that’s a potential issue with any plug-in that has any UI at all. On the upside:

Can you use Reason back-panel routing tools and the like? Yes. You can do all the CV routing and automation and other good stuff a conventional Reason device would have.

These are just more Combinator skins, yeah? No. We’re talking low-level DSP – which also means the DSP portion can be ported really fast. Propellerhead said Softube compiled in 15 minutes – for both Mac and Windows. Most of the time you’ll now wind up investing in UI. (That chuckling sound you hear from developers is because this is generally the case with plug-ins.)

But I can do this with existing plug-in formats. Not quite. There are several elements missing. First, Reason will have an integrated store for this stuff, which also means the ability to move between users, computers, and operating systems more seamlessly. Second, existing plug-ins don’t do things like true host-integrated undo. (Ernst gave the ugly example of tweaking a knob in a plug-in, hitting undo, and undoing the last step – inserting the plug-in – making the whole thing disappear.) Third, and perhaps most importantly, you don’t get sandboxing features in any current plug-in format, meaning a misbehaved plug-in can theoretically crash your whole host.

What’s in it for developers? A 70/30 split — developer/Props — just like Apple’s iOS and Mac stores. And it’s free to join the developer program, so there’s nothing to lose but, uh, time.

But this is just proprietary tech. What experience does Propellerhead have with third-party developers? Oh, just these little things called ReWire and (loop format) REX – which, along with Steinberg’s VST really led the way as far as third-party, cross-platform formats. (REX arguably had a lot to do with the rise of looping software.) Each of these have been used in multiple operating systems and hosts, and require dealing with developers. This is much bigger, of course.

How does this help me collaborate? Propellerhead brought this up with a selling point, so I followed up. Basically, the scenario is this: you’re sharing a track with another Reason user. They don’t have the Squidoodlidoo plug-in you purchased. They can use a 30-day demo, and try it for free. (Otherwise, they have to buy the plug-in, too, naturally.) Also, Ernst tells CDM that the store will maintain every back version of every plug-in. So if you need a previous version, you can revert to that on a set. Reason itself can still open, in version 6, files created in version 1.

So, why would I use an existing plug-in format, if this is The Future? Probably because there’s a host you like better than Reason, or you have one of the many plug-ins that won’t yet support this new thing. But you knew that, right? The payoff here is clearly if you like working in Reason and want more flexibility.

Why a new format? Actually, I’ll editorialize on this one. The kind of integration with Reason here just wouldn’t work with any plug-in format – we’re talking routing control voltage in and out via the back of the rack, integrated automation, and a UI that seamlessly blends with Reason. It’s not a question of formats; you have to write a plug-in for Reason or none of that is possible. As for why existing plug-in formats don’t do some of the things Reason’s tech here does, that’s easy. No one has actually proposed a plug-in format that does that, a handful of vendors control existing formats in wide commercial use (Apple, Steinberg, Avid), and efforts to build a new standard haven’t gotten traction. So, in the meantime, if you want these ideas in practice, you have to build them in your own software, which is what Reason has done. If you want these ideas elsewhere, let’s see it.

Got more questions? I’ll append answers here if I can find them. Expect more once we hear more on what’s actually available to add onto your rack (for users) and once we’re closer to having stuff ready for a wider audience of developers (for you coders). No images or video yet – I know we still owe you a look at the new iOS app – but that’ll get posted when ready.

More details, and ugly speculation about whether or not I was wearing pants, in the live event coverage:
http://createdigitalmusic.com/2012/03/propellerhead-announces-mobile-app-figure-live-announcement-coverage/

Apple yesterday described their iPad as “this magical pane of glass that can become anything you want it to be.” So – how about making mobile devices into what you want it to be?

With the help of author Peter Brinkmann and publisher O’Reilly, we’d like to give you a taste of Peter’s new book, Making Musical Apps: Real-time audio synthesis on Android and iOS. Imagining that a lot of you are especially curious about iOS, we’ll include the chapter on how to get started with development. It really gives you a sense of how easy this can be; the challenge is, as it should be, coming up with musical ideas. And Apple did say that they thought that technology was at its best when it was “invisible,” not when it was “inaudible.” So let’s make it make some noise.

(Android developers, libpd actually got its start on Android and runs quite well even on very primitive Android handsets, so consider this a sample; the full book – and the libpd site – include loads of examples on the Android side, too. In fact, because libpd works basically identically on the two platforms, it’s a great choice for making cross-platform development easier.)

In this excerpt, Peter covers:

• How to set up your development environment
• Starting a project with Xcode, and including Pd
• How to make a Pd patch run in your app
• Making the Pd patch and your UI connect with each other (here, from the app’s UI to Pd; the book covers both directions)

In fact, in just a few pages, you’ll have a working guitar tuner for iOS. Have a look:

Read it on CDM’s Scribd page:

Making Musical Apps (Excerpt: How to Build a Music App for iOS)

Direct PDF download link, hosted by CDM (please don’t link to this file directly):
Making Musical Apps (Excerpt) [PDF]

I’ve read an advance copy of the whole book, and my review is simple: if you’re curious about this stuff, get this book. Peter’s style is friendly and precise; no technical detail is left out, and yet those details aren’t overwhelming. The book can be accessible to those new to development, which is essential for a title that’s likely to be read by people who are used to Pd, but dipping their toes into Java and Objective-C for the first time in order to get their patches running on a device.

Ready for the full book?

Get a printed copy on Amazon:

Or read the Kindle edition:

For multi-platform epub, mobi, and PDF formats, head straight to the O’Reilly page:
Making Musical Apps [shop.oreilly.com]

http://libpd.cc/read-the-book/

Speaking of making the ephemeral tangible, as artist Andrew Spitz tells us, “it’s a fun process to map something that is so fleeting as a sound to a physical object.”

That’s what he does in a new collaboration with Andrew Nip of the Copenhagen Institute of Interaction Design in Denmark. It’s a simple process – and that’s a good thing, as it means anyone with access to a laser cutter can get in on the fun. Using software written in the open source, design-friendly coding language Processing, your voice message becomes a waveform, and then that waveform becomes a series of discs in paper, which, strung together, produce a three-dimensional sculptural object.

The results are quite elegant; I suddenly want to string these around my flat. From the project description:

Paper Note creates a tangible waveform from laser cut disks of paper. The user records a message, a sound or loads up music, and the system analyses the sound to map each moment to a corresponding slice.

This project was made with Andrew Nip at CIID. We programmed it using Processing. Each Paper Note is made up of around 450 stacked disks of paper. The louder the volume at a specific moment, the bigger the disk. Our algorithm samples the right amount of information from the recording to scale the physical waveform to the size of around 14cm.

Paper Note ~ A Tangible Paper Waveform {+ generative}

By the way, Andrew Spitz has over a dozen terrific videos on this sort of physical computing and sound and vision projects on his Vimeo account:
https://vimeo.com/soundplusdesign

Digital: disposable, identical, infinitely reproducible. Recordings: static, unchanging.

Or … are they?

Icarus’ Fake Fish Distribution (FFD), a self-described “album in 1000 variations,” generates a one-of-a-kind download for each purchaser. Generative, parametric software takes the composition, by London-based musicians-slash-software engineers Ollie Bown and Sam Britton, and tailors the output so that each file is distinct.

If you’re the 437th purchaser of the limited-run of 1000, in other words, you get a composition that is different from 436 before you and 438 after you. The process breaks two commonly-understood notions about recordings: one, that digital files can’t be released as a “limited edition” in the way a tangible object can, and two, that recordings are identical copies of a fixed, pre-composed structure.

Happily, the music is evocative and adventurous, a meandering path through a soundworld of warm hums and clockwork-like buzzes and rattles, insistent rhythms and jazz-like flourishes of timbre and melody. It’s in turns moody and whimsical. The structure trickles over the surface like water, perfectly suited to the generative outline. At moments – particularly with the echoes of spoken word drifting through cracks in the texture – it recalls the work of Brian Eno. Eno’s shadow is certainly seen here, conceptually; his Generative Music release (and notions of so-called “ambient music” in general) easily predicted today’s generative experiments. But Eno was ahead of his time technically: software and digital distribution – both of files and apps – now makes what was once impractical almost obvious. (See also: Xenakis, whom the composers talk about below.)

You can listen to some samples, though it’s just a taste of the larger musical environment.

Fake Fish Distribution – version 500 sampler by Icarus…

12 GBP buys you your very own MP3 (320 kbps). Details:
http://www.icarus.nu/FFD/

The creators weigh in on the project for Q Magazine:
Guest column – Electronic band Icarus on whether algorithms can be artists?

The conceptual experiment is all-encompassing. Just to prove the file is “yours,” you can even use it to earn royalties – in theory. As David Abravanel, Ableton community/social manager by day and tipster on this story, writes:

“As a sort-of justification for the price, all Fake Fish Distribution owners are entitled to 50% of the royalties should the music on that specific version ever be licensed. A very unlikely outcome, but at least it’s sticking to concept.

I spoke with Ollie and Sam to share a bit about how the mechanism of this musical machine operates. Using Ableton Live and Max for Live, each rendition is “conducted” from threads and variables into a sibling of the others. The pair talk about what that means compositionally, but also how it fits into a larger landscape of music and thought. Of course, you can also go and just experience your own download (first, or exclusively) to let the music wash over you, an experience I also find successful. But if you want to dive into the deep end as far as the theory, here we go.

CDM: How is the generative software put together? What sorts of parameters are manipulated?

Ollie: The basic plan to do the album came before any decision about how to actually realise it, and we initially thought we’d approach the whole thing from a very low level, such as scripting it all in the Beads Java library that has been a pet project of mine for some time. But although we love the creative power of working at a low level, the thought of making an entire album in this way was pretty unappealing. We looked at some of the scripting APIs that are emerging in what you might call the hacker-friendy generation of audio tools like Ardour, Audacity, and Reaper, but these also seemed like a too-convoluted way to go about it.

Even though Max for Live was in hindsight the obvious choice, it wasn’t so obvious at the time, because we weren’t sure how much top-down control it provided. (As a matter of fact, one of the hardest things turned out to be managing the most top-level part of the process: setting up a process that would continuously render out all 1000 versions of each track.) Although it was quite elementary and unstable (at the time), [Max for Live] did everything we wanted to do: control the transport, control clips, device parameters, mix parameters, the tempo … you could even select and manipulate things like MIDI elements, although we didn’t attempt that. 

So we made our tracks as Live project files, as you might do for a live set (i.e., without arranging the tracks on the timeline), then set up a number of parametric controls to manipulate things in the tracks. Many of these were just effects and synth parameters, which we grouped through mappings so that one parameter might turn up the attack on a synth whilst turning down the compression attack in a compensatory way. So the parameter space was quite carefully controlled, a kind of composed object in its own right.

We also separated single tracks out into component parts so that they could be parametrically blended. For example, a kick drum pattern could be spilt into the 1 and 3 beats on the one hand, and a bunch of finer detail patterning on the other, so that you could glide between a slow steady pattern and a fast more syncopated one. So loads of the actual parameterisation of the music could actually be achieved in Live without doing any programming. Likewise, for many of the parts on the track, we made many clip variations, say about 30, such as different loops of a breakbeat. The progression through those clips — quantised in Live, of course — could also be mapped to parameters.

Finally, by parameterising track volumes and using diverse source material in our clips, we could ultimately parameterise the movement through high-level structures in the tracks. So we could do things like have a track start with completely different beginnings but end up in the same place. We did this in Two Mbiras, which is probably the track where we felt most like we were just naturally composing a single piece of music which just happened to be manifest it a multiplicity of forms. In that sense, this was the most successful track. Some of the other tracks involved more of an iterative approach where we didn’t have a clear plan for how to parameterise the track to begin with, but that fits with our natural approach to making tracks. At one point, we wondered if we could just drop a bank of 1000 different sound effects files into an Ableton track, to load as clips. To our glee, Live just crunched for a couple of seconds and then they were there, ready to be parametrically triggered. So each version of the track MD Skillz could end on a different sound effect.

The Max software consisted of a generic parametric music manager and track-specific patches that farmed out parametric control to the elements that we’d defined in Live. The manager device centred around a master “version dial”, a kind of second dimension (along with time), so you could think of the compositional process as one of composing each track in time-version space.

We used Emanuel Jourdan’s ej.function object, which is a powerful JavaScript alternative to the built-in Max breakpoint function object, and wrote some of our own custom function generators and function interpolation tools to interact with it. Using the ej.function object, we composed many alternative timelines to control the parameters, and then used the version dial to interpolate smoothly between these timelines, resulting in a very gentle transition between versions. I.e., version 245 and 246 are going to be imperceptibly different, but version 124 and 875 will be notably different (we quickly broke from our own rule and started to introduce non-smooth number sequences into some of the tracks, so for example in Colour Field two adjacent versions will actually have quite different structures). We spent some time making it well integrated into Live so that once we really got into the compositional process it would work smoothly and be generally applicable to all of the different ideas we wanted to throw at it. That said, it’s a few steps of refinement from being releasable software. 

Pictured: the master controller device, very minimal, just a version dial and a few debug controls. Double clicking on bp_gui leads to the other figure, a multitrack timeline editor, with generative tools for automatically generating timeline data using different probability distributions.

How did you approach this piece compositionally, both in terms of those elements that do get generated, and the musical conception as a whole?

Sam: Since 2005, we had been working a lot in the context of performance, not only as Icarus, but with improvising musicians through our label / collective Not Applicable. This is reflected in the records we put out both as Icarus and individually during that time, which increasingly used generative and algorithmic compositional techniques as structural catalysts for live improvisations. (As Icarus: Carnivalesque, Sylt and All Is For The Best In The Best Of All Possible World. Individually: Rubik Compression Vero, Five Loose Plans, Nowhere, Erase, Chaleur and The Resurfacing Of An Atavistic Trait). Our performance software was made using Max/MSP and Beads and we started by crafting various low level tools that would loop and sequence audio files in various different ways, giving us control parameters that were devised around musical seeds we were interested in exploring.

In many respects, our approach was very similar and partly inspired by Xenakis’ writings in Formalised Music, although the context is obviously very different. These low-level tools were augmented by various hand-crafted MSP processing tools which used generated trajectories and audio analysis as a method of automating the various parameters that effected the sounds themselves, the logic being that an FX unit as a manipulator of sound is in some way loosely coupled to the musical scenario it is contextualised in. In both cases above, the idea was to step back from performance ‘knob twiddling’ by using the computer to simulate specific types of behaviour that would control these processes directly (hence the reason why we have never used controllers in performance).

Our search for different methods of coupling our increasing parameter space led us to develop various higher-level control strategies at Goldsmiths and IRCAM respectively, culminating in autonomous performance systems built in the context of the Live Algorithms for Music Group at Goldsmiths College. The autonomous systems we developed used a battery of different techniques to effect control, from CTRNNs and RBNs to analysis-based sound mosaicing, psychoacoustic mapping and pattern recognition. This work resulted in us being commissioned to put together a suite of pieces for autonomous software in collaboration with improvising musicians Tom Arthurs and Lothar Ohlmeier called “Long Division” for the North Sea Jazz Festival in 2010. The challenge of putting together a 45-minute programme of autonomous music really forced us to think more strategically about how it was possible to structure musical elements within a defined software framework and how they could vary not only within each individual piece, but also from piece to piece.

The most obvious inspiration for how we might do this ultimately came from reflecting on what it is we do when we perform live as Icarus. The experience of working up entirely new live material and touring it without formulating it as specific tracks or compositions proved to be an ideal prototype not only for Long Division, but also ultimately for FFD. Here, in a similar sense to the work of John Cage, large-scale structure and form became a contextually-flexible entity, which meant that for us it became to a far greater extent derived from the idiosyncrasies of the performance software we developed and keyed in by our own specific way of listening out for certain musical structures and responding to them in either a complementary or deliberately obstructive fashion (or perhaps even not at all). Creating these two pieces (‘Long Division’ and ‘All Is For The Best In The Best Of All Possible Worlds’) gave us the conviction that we could devise musical structures that were both detailed enough and robust enough to benefit positively from some level of automated control.

Therefore, when we came to start working on FFD, the main question we had to ask ourselves was; within the music making practices we had already been working with, what were the tolerances for automation within which we were still ultimately in control of and ultimately composing the music we were creating? In the end, the framework we set up was comparatively restrained; the generative aspect of each track was always notated as a performance via a breakpoint function and therefore able to be rationalised by us, the variation between different versions of the same track was done using interpolation and is completely predictable and incremental and finally, the entire space of variation is bounded to 1000 versions, meaning that the trajectories of the variation never extend into some extreme and unrealisable space.

More notes on the album:

Web: http://www.icarus.nu
RSS: feed://www.icarus.nu/wp/feed/

Last.FM: http://www.last.fm/music/Icarus
Discogs: http://www.discogs.com/artist/Icarus+(2)

SoundCloud: http://soundcloud.com/icaruselectronic
Twitter: http://twitter.com/#!/birdy_electric

Myspace: http://www.myspace.com/icaruselectronic
Facebook: http://www.facebook.com/pages/Icarus/132324596558

CREDITS

Music, Software, Scripting – Icarus (Ollie Bown and Sam Britton)
Mastering – Will Worsley, Trouble Studios
Artwork – Harrison Graphic Design

Icarus gratefully thank the following for their support of the FFD project

The PRSF Foundation (UK)
STEIM (Netherlands)
Ableton (Germany)
The University of Sydney (Australia)
Emmanuel Jourdan (France)

Turning music and sound into three-dimensional worlds often yields something that fields like a trip through space. But this feels like a real trip. Through pulsing, glowing starfields, “Versum”‘s audiovisual movements are brain-bendingly transformative. Artist Tarik Barri has created an integrated world of sound and image that makes the interface and the compositional realms seamless. It seems as though this really is a musical universe, through whose harmonies of the spheres you can fly like. Boldly going, indeed.

Ingredients: Max/MSP/Jitter, Processing, Java, SuperCollider, GLSL [the 3D shading language], and … some serious skill and time, I imagine.

The work has been in development for some years (not surprisingly, given the results). But it surfaced again as we brought up the 3Dconnexion SpaceNavigator hardware as a practical controller for 3D. See Create Digital Motion:
Look at Me, I’m Flying: SpaceNavigator Hardware + Blender

Tarik’s work resurfaced after a presentation in the UK. Reader janklug writes:

I’m just back from the M4_u Max/MSP/Jitter conference in Leicester (was great, btw), where Tarik Barri presented his project ‘Versum’, both as an installation and as a performance.
The user (and in case of the performance, Tarik) navigates through this incredible 3D-space-sequencer-universum with the help of a SpaceNavigator; glowing objects floating in this space produce sound, and as you approach them, they even give this nice doppler effect…
It was totally amazing to be able to float between pulsing rhythm-planet-objects and shiny drone-beams; navigation was easy and natural. Tarik uses a combination of Processing and Max/MSP; don’t know which one the SpaceNavigator is connected to.
Having tried this, I immediately ordered one; I think it also could be a great interface for M4L…

More information:
http://tarikbarri.nl/projects/versum
PDF documentation [2009]

Significantly, it’s really the act of flying that controls the music. That remains interactive, but it’s the movement through the three-dimensional space that determines what you hear. As the artist explains:

This virtual world is seen and heard from the viewpoint of a moving virtual camera with virtual microphones attached. This camera, controlled in realtime by means of a joystick (or any other kind of controller) moves through space, similar to how first person shooter games work. Within this space, I place objects that can be both seen and heard, and like in reality, the closer the camera is to them, the louder you hear them. So when the camera moves past several visual objects, you simultaneously hear several sounds fading in and out. Consequently, the way the camera travels past them actually causes melodies and compositional structures to be seen and heard.

The visual position of each object coincides with the panning of its sound: objects to the right of the camera will also be heard on the right, and those behind the camera will be heard from behind in case a surround speaker setup is used. This principle also applies to the Z-axis, meaning that sounds can be heard coming from above and below if the speaker setup supports it.

That’s the essential question, to me, when looking at 3D environments for music. What about the dimensionality will interact with the music? Is it something spatial, or will there be other sorts of interactions? (New Zealander-turned-Berliner Julian Oliver worked extensively with game engines, for instance. One solution for him was modifying the “gun” in those games to be an implement for doing things in the space, turning swords into plowshares after a fact by making the gun produce music rather than kill virtual entities.)

So, now you’ve seen some of the technical demonstration. But Tarik uses his work as an environment in which to make audiovisual performances. Here’s what some actual live playing looks like, in a beautiful, meditative piece called “Eleven”:

In fact, the biggest challenge to me of a piece this awesome is that you want an immersive environment, not just the small, rectangular screens that are often all festivals and venues can afford.

Holodeck, anyone?

More:

Add this to the Internet of Things: imagine data recording scratching and scratch performances.

Technologists Jamie Wilkinson, Michael Auger, and Kyle McDonald propose a new way of storing scratch moves as data. They’re not just working in traditional ways, either: they’re hacking turntables and optical mice and cameras, and imagine not only recording performances, but having machines recreate scratching. (Robots!) And they want your help. Kyle writes:

i’m going to be leading a group at art hack day ( brooklyn, january 26th-28th www.arthackday.net/ ) about scratch markup
language, a tool for recording performances from turntablists.

this describes the general idea and who we’re
looking for. we need everyone from web designers/developers, to
hardware hackers, coders and musicians. if you’re interested, or know someone who is interested, contact me or join the google group groups.google.com/group/arthackday/

(We cover the awesomeness that is Graffiti Markup Language on Motion, which goes further to explaining why this sort of data storage can be powerful and enabling.)

All is described – rather bizarrely – in an image. (Can we have plain text, please? It is, at least, a pretty picture!)

I’m not sure how everyone who owns an iPad uses it for music, but I find myself strangely drawn, more than anything else, to analog step sequencers. With MIDI connections – via a special interface or a standard USB MIDI interface connected via adapter to the tablet – you can even drive hardware. For me, the app of choice has been Little MIDI Machine. Developer Chris Randall has a new application in the analog-style sequencing category, though, called Phaedra.

If you haven’t grabbed it already, you have until the New Year to get it for US$4.99 before the price jumps to ten bucks. And you get an impressive array of features:

• Multiple buses, with 32 steps max each
• Programmable note, velocity, gate time, and two MIDI CC outs for each step
• Send or receive MIDI Clock for sync
• Use MIDI hardware (via Core MIDI), other apps (using “background MIDI” or OMAC), or your computer (networking via a MIDI Network Session

Phaedra for iPad [iTunes Store Link; you'll need iOS 5.0]

I wanted to know more about the creation of Phaedra. Developer and musician Chris Randall, known for his work with boutique plug-in maker Audio Damage, released this under a new moniker, Naughty Panther, which does iOS and MIDI development. Chris has been known to mix old and new, as with his musical use of the Apple II. Here, he gives us some insight into how he went through the design process on this new tool.

CDM: How do you sketch out the UI on a project like this? Paper and pencil?

Chris: Normally I just make notes in a little Field Notes notebook as I think about them — I carry one everywhere — then once I have a clear mental image of what I want to make, I just bust it straight out in Photoshop (or, for skeuomorphic interfaces like this one, a combination of Photoshop for the panel and 3D Studio Max for the knobs and buttons).

What inspiration did you consider as far as hardware?

Adam sent me the page for the Moon Modular 568 “Sequential Trigger Source” and quipped that it would make a fun iPad app, and I kind of ran with it. (Their site is a frame-a-thon, but ’tis here: http://www.lunar-experience.com/home.html) As you can see, the UI for Phaedra closely follows the Moon Modular design. The functionality diverges quite a bit, though. Once I had the initial look, I just started adding features I personally thought would be nice in a step sequencer. Then the beta testers had some more input. And now that it is out, I’m getting a ton of great feature requests from the users. The next update will have some cool tricks in it, provided I can figure out how to code them.

What hardware would you recommend for connecting MIDI?

The best MIDI I/O situation for Phaedra is an Alesis iO Dock. Hands down. I have tested it with a half dozen MIDI interfaces via the [Apple] Camera Connection Kit [for connecting driverless USB MIDI interfaces], and they all work fine except that $5 cheap one that people buy from Amazon, which unsurprisingly, has problems. Phaedra also automatically creates a virtual port and connects to all virtual endpoints running on the iPad, so it can drive NLog Pro, Animoog, whatever. And it also is [Apple MIDI] Network Session aware, so it can just work over wi-fi.

I’m going to add OSC output as an option in the next update, I think. I’m still thinking about how to implement that, but it seems like it would be handy, and then Phaedra’s abilities would be greatly increased.

I’m also adding trigger outputs via the audio ports, so you can use Phaedra to clock an external modular sequencer like Makenoise René, or a pre-MIDI drum machine. I’m giving it 48-ppq clock for Korg drum machines, 24-ppq clock for most every other drum machine, and arbitrary rates from 16-ppq on up to 1-ppq for driving modular sequencers and your Monotribe. This should be handy, and will be sample-accurate in line with the MIDI clock output.

See also Chris’ blog entry on the app at Analog Industries:
Some Cool Shit

First revealed last month, PreenFM is an open source hardware synth. As the name implies, it’s an FM synth, with some very serious specs: up to six-operator FM synthesis with some nine algorithms, up to 4-voice polyphony (depending on algorithm), glide, selectable LFOs, modulation matrix, and preset banks with SysEx support. It’s all usable via a display and MIDI support.

It’s also fully open source hardware; whereas early efforts often had commercial restrictions attached, PreenFM is free for use under the GPLv3 and Creative Commons. And it’s got a unique platform under the hood: the open source LeafLabs 32-bit development platform gives this some serious horsepower. It’s very much in contrast to the ultra-inexpensive 8-bit brain of our own MeeBlip synth; think of the MeeBlip as an exercise in what you can do with a little two-stroke engine versus the V8 muscle in this. (The creator says the MeeBlip helped inspire his creation – yes, synths are multiplying!)

You may have glimpsed the PreenFM making the rounds online, but I got creator Xavier Hosxe to tell us more of the gory details and share some sounds.

CDM: So this is all based on the Leaf platform?

Xavier: Yes it’s built around a LeafLab board.
I coded a first version on the Maple [development board]; then when they announced their “Maple Mini,” I realized it was going to be very easy to plug it into a PCB.
I’m not directly connected to [LeafLabs]; I participated in the forum and learnt many things from the team.

They are very friendly and helpful.

What was it like working with the Leaf?

The LeafLabs boards uses an ARM Cortex-M3 microcontroller.

It’s a 32-bit chip runing at 72Mhz that can do 32-bit multiplication in 1 clock cycle, has 128Kb of flash [memory] and 20Kb of RAM. That seems very few but it’s not, PreenFM software uses 92Kb for the moment.

LeafLabs provide a Linux/gcc toolchain that allows to develop in your IDE of choice… Eclipse in my case, which is very confortable.

They also provide a strong bootloader and some libraries that worked perferfeclty for my needs : Usart (Midi), I2C (EEPROM), LiquidCrystal (LCD).

What will you get in the PreenFM kit?

All you need to build yourself a complete synth: PCB, screws, resistors, ICs, audio/midi jack, box, 20×4 LCD, encoders, knobs, buttons… even an USB cable [for power].

You’ll also get a Maple Mini board with PreenFM soft preloaded. The Maple Mini is easily updatable, and you can experiment lots of different things with it.

PreenFM C++ source code is available on GitHub. It’s easy to read and modifiable. If you want to see your name to welcome you on the boot screen, go ahead

To build the kit, you only need a soldering iron and some solder.

There will be 2 differences with the photos you can see on the site: the final PCB will be blue (I should receive them next week). [Ed.: See the photo in blue at top; the orange one is included here for variety! -PK]

Xavier also sends along some welcome news:

Here is a sound I can get with my soon-to-be-released StepSequencer feature in PreenFM.

This is a single voice of a simple 3-oscillator voice. 1 very slow LFO + 2 * step sequencer routed to the modulation indices.

PreenFMStepSeq by cdm

Here’s a sound sample:
PreenFM 1 by cdm

http://www.preenfm.net

In a marvel of DIY engineering, one intrepid user of the tracker-made-modern music making environment Renoise has reconstructed the basic elements of the Ableton Live interface. With quantized clip launching on channels and even a crossfader, it’s unmistakably a copy of what Ableton does. I don’t think you’d dump your install of Ableton for this; the whole reason you’d want a feature like this is really if you prefer other elements of Renoise that are different from Live. But as a proof-of-concept, it’s pretty extraordinary. (Ableton users, the ball’s in your court: someone want to make a tracker in Max for Live?)

mxb has more information on the Renoise forum:
Cells! Preview

We love the bleeding edge, but as mxb notes, “this is still at a very early beta stage; if anyone has any suggestions or feature requests, [they should] make them in the thread on Renoise forums.”

All of this is possible because of Renoise’s powerful scripting environment.

The Cells! video above is a bit primitive – mxb says it’s a result of poor screen capture software, which is also responsible for sync disappearing – but you get the idea. mxb has also built a four-oscillator synth called ReSynth, and previously-mentioned sample import.

http://tools.renoise.com/users/mxb [all of mxb's creations]
http://tools.renoise.com/tools/resynth