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

For years, since the launch of Ableton Live, many have waited for a worthy rival, something that combines production and live performance for music users. Live isn’t without alternatives – Renoise, for instance, has earned some fans, though it isn’t necessarily built for live performance. But few provide the same real-time workflows.

Bitwig, based in Berlin as is Ableton and featuring some Abletronic veterans, today took the wraps off its own Bitwig Studio. The good news is, it’s looking as though it might shape up to be a viable tool for DJing, performing, and making music. The bad news is, in a market already crowded with lots of similar tools vying for your attention, the first release will look more familiar than radical. That is, it looks and works a whole lot like Live. There’s an Arranger view, a clip launching view with scenes, a tray on the bottom with effects and instruments (they’re even called Devices, like in Live). The screen layout, and even specific interface widgets and channel strip arrangements are all straight out of Live.

It’s not just a little like Ableton Live, either – it’s in some cases a direct clone. Nested drum machine Devices, for instance, work in a way that I’ve never seen out of Ableton Live. A channel strip similarity or two is almost inevitable; here, though, lots of little details add up to something that feels like Ableton, but didn’t come from Ableton.

What that means to you may depend on what you want: whether you just want an improved Ableton alternative that works like Live, or whether you want something more fundamentally different from Live as an alternative.

If you want “Ableton Plus,” Bitwig does take on features Ableton is missing. For instance:

1. Linux support. In fact, right out of the gate, this could quickly be the answer for Linux users waiting for something they could use without booting to Mac or Windows.
2. Proper multiple document support. You can share content between projects in Ableton, but here you can actually open and freely exchange media with multiple files at once.
3. Mix audio and MIDI on the same track. Tracks are content-agnostic.
4. Per-note automation, with the mixed MIDI and audio, promises more detail-oriented editing.

Those are three significant breakthroughs. And it looks like there are lots of tweaks and improvements throughout the tool, many of which I’m sure we’ll hear about as people begin testing the beta. (One nice example: a vertical pane lets you view arrange and clip launching views simultaneously.) Multi-monitor support, while present in many tools, is sorely lacking in Live but available here. Plus, as some readers note, you do get 64-bit support, though that seems an advantage over Ableton that won’t last long.

The challenge is, as a new entrant to the market, your first obstacle is telling a story about what you are. And here, there seems a missed opportunity to make a first impression as something truly different, rather than something “similar, but better.” Ableton Live 1.0 when it was released was a significant departure from what had been seen before. So, too, were the first trackers, the first audio+MIDI DAWs, and the first graphical sequencers. Bitwig Studio isn’t that kind of breakthrough – not yet.

Not that being different is easy, or even always desirable. Amidst so many things users want, and so many expectations they have about how things will work, it’s tough to do something genuinely new without simply confusing everyone and driving them away. But it has happened – Ableton Live’s original release being a notable case. One question is whether you make some sacrifices to release the most significantly-different tools initially, or whether you choose to cover the basic bases to provide a workable solution from day one, and the Bitwig devs seem to have chosen the latter.

The most interesting features remain on the horizon. LAN multi-user jamming and multi-user production are both on the roadmap – features we’ve seen in other tools, but which have yet to catch on. And there’s an integrated modular system that lets you build your own instruments and effects with graphical patching – something seen in various forms from Buzz to Max for Live, but one that could use a fresh take in integration with the tool.

In the meantime, we’ll have to hear from beta users whether Bitwig is something worth a look. You can sign up now:
http://bitwig.com/bitwig_studio.php

We’ll be eager to hear what you think.

Pics:

But whether you’re in the US or in one of the many other parts of the world where we count readers, let’s pause to consider what makes us thankful.

I’m immensely thankful to have the opportunity to make music. I find it’s always worth reminding myself of that, and reminding to fight for the time to do it, to keep myself sane. Highlights for me so far in 2011: playing a friend’s grand piano in Brooklyn on a wintry-feeling March day (the samples of which make up the performance Saturday), spending Hurricane Irene jamming on a Mono/Poly with King Britt and Rucyl Mills, firing up Pd and getting lost in granular samples on a gray day in Berlin, assembling a track in Reason or Ableton in a hotel room… these are the sort of moments where, all at once, you find under almost any circumstances you can reclaim your sense of center and happiness, and give everything else clarity.

I’m also, and I don’t get to say this enough, unbelievably thankful for the readers of this site and some of the print projects I do. As a professional writer, writing is not a claimed right, but a privilege granted at the pleasure of your readership. Then, on this site, I get the gift of being able to see the inventions and expressions of people around the world. And yes, even getting criticisms and hearing people argue with what I say is a terrific motivator, one I don’t take for granted, especially when print writing remains largely without feedback. For me as a musician, it’s come to be part of who I am – not only my personal output, but all this input, having the chance to write about what’s happening. It doesn’t conflict with being a musician; it’s an essential element of that process for me.

I’m so grateful, in fact, for these two things, that I feel I can always do more.

And more is coming. I’m thankful that after a lot of work behind the scenes, there are new possibilities that lie ahead to expand upon what CDM does. And yes, as some readers or residents of Berlin have worked out, I’ve personally for the last few weeks been in the capital of Germany and not the city of New York. You may also have met Marsha Vdovin, who came onboard earlier this year as Business Development Manager and who has already moved forward what CDM can do and how it can grow.

Also, as of this morning, delays suffered by our open source MeeBlip project are at last coming to a close, beginning with new shipments of the MeeBlip micro and all-new firmware for all models, available now on GitHub. (We’ll have a full update on the MeeBlip project next week, as everyone gets back from the holiday.)

Most importantly, I’m working now on plans to completely rebuild Create Digital Noise and give readers and like-minded artists the community they deserved, instead of the failed experiment we got. If you’re interested in being part of that conversation, get in touch; otherwise, more on that very soon.

But it’s those things for which I’m thankful that motivate all of this. And I’m thankful, as always, not so much for what lies in the past or somewhere off in the future, but what is halfway-done and in process, partway through the story, which is where I find the really good stuff lies. In that spirit, here’s a documentary that deals with the notion of delivering in beta, and getting things out the door – something that goes as much for music as it does for inventions, I think. (As it happens, director Gabriel Shalom and photo editor/titler Patrizia Kommerell are sitting next to me in a hotel lobby as I write this.)

What are you thankful for? Let us know – or have a look at ten music technologies I gave thanks for last year.

Max 6 in Public Beta; For Home-brewing Music Tools Graphically, Perhaps the Biggest Single Update Yet

Just because a music tool fills your screen with tools and options doesn’t necessarily make it easier to realize your ideas. From the beginning, the appeal of Max – as with other tools that let you roll your own musical tools from a set of pre-built building blocks – has been the blank canvas.

Max 6 would appear to aim to make the gap between your ideas and those tools still narrower, and to make the results more sonically-pleasing. The reveal: it could also change how you work with patches in performance and production. I was surprised when early teasers failed to impress some users, perhaps owing to scant information. Now, Max 6 is available in public beta, and the details are far clearer. Even if Max 5 was the biggest user interface overhaul in many years, Max 6 appears to be the biggest leap in actual functionality.

It’s what I’d describe as a kitchen-sink approach, adding to every aspect of the tool, so there’s almost certain to be some things here you won’t use. What could appeal to new users, though, are I think two major changes.

More visual patching feedback and discoverability. First, building upon what we saw in Max 5, Max’s approach is to provide as much visual information as possible about what you’re doing. It’s probably the polar opposite of what we saw earlier this week in something like the live-coding environment Overtone: Max’s UI is actively involved with you as you patch. There are visual tools for finding the objects you want, then visual feedback to tell you what those objects do, plus an always-visible reference bar and rewritten help. This more-active UI should make Max more accessible to people who like this sort of visual reference as they work. No approach will appeal to everyone – some people will find all that UI a bit more than they like – but Max’s developers appear to be exploiting as much as they can with interactive visual patching.

Multiple patches at once. New objects for filters and data, a 64-bit audio engine, and low-level programming are all well and good. But the change that may more profoundly impact users and workflow is be the way Max 6 handles multiple patches. Max – and by extension Pd – have in the past made each patch operate independently. Sound may stop when you open a patch, and there’s no easy or fully reliable way to use multiple patches at once. (Compare, for example, SuperCollider, which uses a server/client model that lacks this limitation.) That changes with Max 6: you can now operate multiple patches at the same time, mix them together with independent volume, mute, and solo controls, and open and close them without interrupting your audio flow. (At least one reader notes via Twitter that you can open more than one patch at once – I’d just say this makes it better, with more reliable sound and essential mixing capabilities.) Update: since I mentioned Pd, Seppo notes that the pd~ object provides similar functionality in regards to multiple patches and multi-core operation. This has been an ongoing discussion in the libpd group, so I think we’ll revisit that separately!

One upshot of this change: some users have turned to Ableton Live just to host multiple patches. For users whose live performance set involves Ableton, that’s a good thing. But it could be overkill if all you want to do is bring up a few nifty patches and play with them. Now, I think we’ll start to see more people onstage with only Max again. (Check back in a few months to see if I’m right.)

Here’s an overview of what’s new:

• Discoverability: A “wheel” makes the mysterious functions of different objects immediately visible; Object Explorer makes them easier to find, and new help and reference sidebar keep documentation close at hand.

• 64-bit audio engine

• Open multiple patches, solo and mute them, open and close them without stopping audio, mix audio between them with independent volume, and take advantage of multiple processors with multiple patches.

• Low level building blocks: You don’t get new synth objects, but you could build them yourself. New low-level data-crunching goodness work with MSP audio, Jitter Matrix, and OpenGL textures

• More JavaScript: An overhauled JavaScript engine makes JS scripting faster and more flexible, and there’s a proper text editor with syntax highlighting (though, of course, you may still prefer your own).

• New visuals: Vector graphics and “HTML5 Canvas-like” UI scripting (though to me it’s a shame this isn’t just the HTML5 Canvas). There are also massively-expanded Jitter powers, but those are best left to our sister site Create Digital Motion.

• Filters: New filter-visualizing tools for audio filter construction and manipulation.

• Dictionary data type and associated objects let you describe information in a more structured way (all kinds of potential here from control to composition)

• Projects now let you organize data, media, and scripts in the manner more associated with conventional development environments

• What about Ableton? No news on that front, but I expect more soon. Max for Live users will at the very least get the advantages above, since Max for Live is really Max inside Live.

Looking over all that Max does, I have to say, I’m really amazed. I wonder if computer musicians ever pause to consider how fortunate we are. Even if this isn’t the tool for you, its availability – compounded by the availability of a range of other tools – is itself worth reflection.

Max is a program that shouldn’t exist, doing a number of things it shouldn’t do, for a user base that shouldn’t exist, doing things they shouldn’t be doing.

It doesn’t make sense that you could maintain a commercial project for this kind of audience, that you’d wind up with something this mature and powerful that had a continuous lineage stretching back to the 1980s. It doesn’t make sense that musicians would embrace such a tool and produce invention. The only explanation is sheer love.

Then, even as Max reaches new heights, some of the alternatives you have for making your own music tools are simultaneously growing by leaps and bounds. They provide very different approaches to music making (compare Overtone and SuperCollider, or Pd and libpd, or AudioMulch, or new Web audio tools). There really aren’t many fields that have this kind of choice, free and commercial, in their medium. In science and engineering, there’s private and public funding, producing some amazing tools but nothing with this kind of meeting of power and accesibility. There’s just something about music.

The fact that Cycling ‘74 can maintain a business model – just as open source projects maintain volunteer contributions – is a testament to sheer passion and love for music, and a commitment to perpetually re-imagining how that music is made from an atomic level up. There was a wonderful piece on C creator and UNIX co-creator Dennis Ritchie, whom I remembered yesterday, that observed that what he did was to do what others said couldn’t be done. From Max itself to what people make with it, I think that fits nicely.

So, have a look at the public beta, and let us know what you think. The release of Max 6 has caused more people to ask what this means for Pd and other tools, or even whether to patch things from scratch at all, but I’ll leave that question to a bit later. (I do have my own opinion about which tool fits which circumstance and user, but that’s best left to a separate discussion.) For now, you can try Max yourself and see what the fuss is about. If it doesn’t fit your means of music-making, know that you have a wide array of other options – pre-built to low-level code to old-fashioned tape-and-mic approaches, and everything in between. Go out and listen and see what you discover.

http://cycling74.com/downloads/max-6-public-beta/

Didier Dambrin, FL Studio’s original creator, has a new synth entitled Harmor that looks like one to watch. There’s a beautiful crop of new synthesizers this season that could have you yearning for a winter spent with long nights somewhere deep in the Northern Hemisphere, producing new music – see also, to name just one, Cakewalk’s Z3TA+ 2. (Both Harmor and Z3TA+ 2 are Windows-only, so time to boot up the PC or, Mac users, update that Boot Camp partition.) VSTi and native FL Studio support; US$149 but on sale this month for $99.

For some reason, releasing any synth right now involves demonstrating that the kids can make their wobble bass and dubstep with it, but I trust synthesists out there to do other things, too.

Introducing Harmor

Okay, I kind of buried the lead, but I wanted to give the synth its due.

Don’t want to boot into Boot Camp to run FL Studio?

This beta might interest you:
FL Studio for Mac Beta-Testers Wanted [Image Line forum]

Yes, you see that right: it’s FL Studio, aka Fruity Loops, running on the Mac platform. Synthtopia wonders if Hell froze over, but not so fast. Image-Line said they’d never build a Mac version of FL Studio. And they haven’t. The magic here is possible through Codeweavers Crossover, a commercial proprietary technology built on the open source tool WINE. Codeweavers already offers a standalone product that lets you run a variety of Windows (and Linux) software on the Mac, based on the same tech that lets you run Windows software on Linux. Here, Image-Line reports that there’s some additional customization and testing and tweaking that lets this run without further intervention on your part. (WINE can work beautifully, but there are various compatibility wrinkles with specific software – Image-Line and Crossovers have evidently worked specifically on making FL Studio function properly.)

WINE, the underlying technology, is an emulator but not in the sense of a virtual machine, which is how most Windows compatibility tools are implemented. It’s actually a re-implementation of Windows APIs. See WINE myths for more. That means that, once fully tested, FL Studio can run as well on the Mac as on Windows. What you won’t get is Mac-native APIs, meaning the resulting software won’t behave terribly like a typical Mac program. But FL Studio, like much music software, tends to behave in its own way, anyway, so I don’t actually believe that’s a huge deal. Updated: I realize I should say that compatibility issues or unpredictable behavior can be a big deal; I’ll be interested to see if the Mac experience can replicate the Windows experience or you’ll want to still reboot.

If you want to give this a try – and help ensure the quality of the release – beta testers are wanted. See the forum link above.

Teenage Engineering’s hotly-anticipated synth / music-making hardware OP-1 finally got an official release last week. Early stocks promptly sold out, but new waves of deliveries should refresh availability. We’ll have more from TE on the launch and the instrument soon.

In the meantime, you can thank early-adopter Ludwig Mueller for being brave enough to post early experiments with the instrument. Ludwig is a proud owner of the beta release, one of a handful of people who signed up to get access to the OP-1 prior to its public launch – and even before functionality in firmware was entirely finalized. I’ve heard now from several readers who are beta users, and a variety of reactions to the instrument. Oversimplifying, they appear to break down to those who adore the OP-1′s restrictions and those who curse them (and those who do both). In the video at top, Ludwig shows off the process of layering beats and tracks; he not only plays the OP-1, but uses it as a production and composition tool. I asked him to share some further thoughts on how he likes his OP-1 — and what, exactly, it really is.

The OP-1 in short is a mixup of an [Akai] MPC, a pretty great synth, a radio, a mic, and a DAW [Digital Audio Workstation]. All of these components are rather limited looked at individually, but I guess what you can say here is that the sum is greater than its parts. It is the mixture of these parts and the device’s limits – recording is destructive, [so there's] no undo once you record two or more instruments on one track – force you to think ahead. But at the same time, the OP-1′s layout and abilities make you want to try out things you’d never consider in a DAW. So depending which takes over – your brain or your inner child – your results will vary from one extreme to another.

A thing that I really like about OP-1 is the fact that you can’t overtweak. In a traditional DAW, I’d EQ every track and add a little compression, etc., etc. On the OP-1, there’s no such thing. It either sounds good or it doesn’t – and if it does sound good, you keep going and building the track. At the end you turn up the mastercompressor, which BTW is quite amazing, and you’re done! Again: I love the mastercomp!

I can say that I finish a lot more projects / beats / tracks with the OP-1 than with a DAW. Granted, they feel more raw and have some hiccups here and there, but I’m willing to take that in exchange for the fun I have using that little device. And by now, quite often I actually prefer this rawness to the slick sound of my DAW tracks.

Of course there are times when I crawl back to the laptop, and do another track dissecting every element. But this doesn’t last for too long usually. With the OP-1, I can focus more on the music than on the technical side of things; it’s so immediate: No long boot up, loading programs, plugging in things. It’s just a switch and 5-second wait and you’re good to go. It also really fits the bill regarding the overall sound I want to achieve: it’s warm yet punchy. You can actually overdrive the output quite nicely using the mastercompressor within the unit. The achieved overdrive can be quite pleasing to the ear, I think.

I have heard many people say that TE should bring out an OP-1 iPad App. I am 100% certain that a touchscreen can not give you the same feel as a nicely-designed device with quality buttons and encoders.

Right now, I am on the latest OS (the one that is also available for download on TE’s site) and I didn’t have any problems at all since upgrading to that version.

If you visit www.soundcloud.com/yellow-tangerine there is a set on my page called “OP-1 Stuff”. All these tracks are exclusively OP-1 and nothing else.

Let’s give that OP-1 Stuff a listen, indeed:
OP-1 Stuff by YΞll❍W T∆ΠgΞriΠΞ

Thanks, Ludwig, for the thoughts. Plenty of design and workflow thoughts to chew over here, I think, even if you aren’t using an OP-1 – some of these same ideas about limitation can be applied to other hardware and even to software. So I’m curious to hear people respond to the musical ideas here, and not just the issues specific to the OP-1.

I welcome any reactions from OP-1 users — praise and criticism alike.

For the latest from Teenage:
http://now.teenageengineering.com/

Who says we should have only one set of assumptions when it comes to how music software should work? Renoise remains a vision of an alternate reality where mod trackers – musical editors with vertical, pattern-based views instead of horizontal, linear piano roll views – are our present and future. And Renoise keeps getting better and more modern, demanding less of a sacrifice from those coming from other music production tools while strengthening the unique elements of its musical workflow.

We get a first look at the new features here for Mac, Windows, and Linux users, as well as the inside story from the developers.

The new 2.7 release, released in beta this weekend, adds some changes that could dramatically improve working with this tool. Renoise 2.6 was all about hacking and developers; 2.7 is focused on musical utility. (Of course, that means the two combined is a nice one-two punch.) The new features are detailed in the video above, but here are the highlights:

• Smart sample slicing. It’s about time – you can now easily slice a sample using markers or transient detection, and instantly map them using either a keymap or Renoise’s pattern slicing. Yes, other tools have similar features, but slicing is actually more of a natural fit in Renoise, because of its emphasis on pattern triggering, integrated sampling, and fine-tuned edits. DIY instruments did some of this, but having it as an integrated feature is invaluable.
• Better sample keyzones. Renoise’s sampler now acts more as you’d expect a sampler, with the ability to map samples to velocity, key release and not just key press, and to stack and overlap sections. Again, a “traditional” feature takes on new meaning in the context of Renoise, because of Renoise’s advanced mixer routing and pattern triggering capabilities.
• Automation snapping and other tweaks. You can now adjust zoom, snap, and whether or not the edit position follows playback. I actually wish Ableton Live’s automation envelopes worked more like Renoise’s now do. It’s also very accurate, now with 256 steps of precision for each line of the pattern view.
• Multiband sends and more track DSP improvements. Multiband send — oh, yes, indeed, hello. I’m not sure why this isn’t more common, but this feature alone could make Renoise editing wortwhile for effect-loving users. There’s also better DSSI support for Linux users.
• MIDI input routing to individual instruments and tracks.

There are many other improvements, too: pre-count metronome (’bout time), undo/redo that doesn’t view each note played live separately, real-time rendering if you want it, new Lua bindings, and lots of usability tweaks. I’m also quite fond of the phase meter spectrum view you see at the beginning of the video.

Renoise requires some learning and adjustment if you’re used to more conventional editors, and it’s still better suited to production than it is to live use, though people are working on that. But to me, the sample slicing and sample mapping alone could put a lot of people over the top; they’re what has personally held me back from doing more production in Renoise instead of elsewhere.

Don’t forget, as the press release observes:

Renoise boasts full ReWire and Jack support, FX and instrument VST/AU/LADSPA/DSSI plug-in support, automatic plug-in delay compensation, multi-core load balancing, MIDI I/O, OpenSoundControl, audio recording, flexible audio output, graphical & numerical parameter automation, modular parameter routing, and much more.

I think it’s now probably the most complete music tool available on Linux, and even on Mac and Windows, has the most sophisticated native, built-in API for manipulation and customization and OSC control. On both Mac and Linux, by the way, powerful Jack control means that Renoise, Ardour and Harrison Mixbus, and Pd (Pure Data) can all play nicely together – an insanely-powerful combination of tools that you can get, incredibly, for under a couple hundred dollars.

If you’re a registered user, you can grab the beta right now. Release notes and download link:
http://www.renoise.com/release-notes/270

But the developers also have some reflections on Renoise that they wish to share with CDM. They actually did this, much to my delight, unsolicited, and they offer real insight and even usability tips. It’s great to get this right from the people working on the project.

Kieran Foster (dblue)

Known to plug-in enthusiasts for his fantastic, free Glitch plug-in for Windows, dblue has now joined Team Renoise.

Hi, my name is Kieran Foster. I was born in 1979 in the North East of England. I grew up with computers like the Sinclair Spectrum 48k and Atari ST, and have been fascinated by sound, graphics and programming since a very early age.

Why Renoise: I’ve used trackers exclusively my entire life, so Renoise definitely doesn’t feel like a niche product to me; it’s simply the only way of making music that I feel comfortable with.

As far as what attracted me to the project, it was a completely organic process that just kind of happened on its own. When I first became a registered user in 2003, I simply enjoyed using the software and felt proud to help support it. I later joined the community forums in 2004 and gradually became more and more active there, and found myself completely caught up in it all.

After using Renoise for so many years now and watching it grow, it’s obvious to me that’s there’s something very special and unique going on here, produced by a small team of very smart and creative people. It’s impossible not to be attracted to that and want to be a part of it somehow.

Ideas for the future: I’d like to see a more flexible clip-based approach to arranging chunks of pattern data and automations on a global song time line, making it easier to get an instant overview of your whole song, as well as quickly rearranging sections and experimenting with new ideas. This is one of the few remaining things that really bugs me about working with trackers these days, since it’s often a total nightmare to work with fixed patterns and keep track of where everything is. I will always love the tracker style of composing, but there’s definitely a lot we can do to modernise things and make it more friendly.

I’d also like to see a more modular approach to handling internal DSP effects and signal routing, with the ability to take complex, unmanageable chains of devices and combine them together into self-contained modules or ‘racks’ that are easy to use and only expose the handful of important parameters you actually need to tweak. It’s possible to create some truly incredible DSP chains in Renoise, but managing the huge number of devices and parameters involved can be rather daunting – especially when trying to share your creations with others.

Tips for new users: Don’t judge a book by its cover; Renoise may look insanely complex at first glance, but it’s really not that difficult to get to grips with. Be patient and you will soon fall in love with the incredible low-level approach to making music that only trackers can offer.

Become a master of the LFO Device!

Erik Jälevik

An early member of Last.fm’s development team, Erik is now a core Renoise developer.

Hi, my name is Erik Jälevik. Born and raised in Sweden, moved to the UK at a young and impressionable age, now in Berlin since about a year. Music has always been my main passion, but once I realised I wasn’t going to be able to make a living from making music or DJing, I decided to get a degree in computer science and embark on a career as a software developer. I’m in a lucky position in that I get to combine my passion with my profession.

Why Renoise: Last.fm certainly wasn’t mainstream when I joined, it was just a handful of guys in a rundown 2-room flat in east London. What it grew to become was part of the reason I left however. But what attracted me to Renoise really had nothing to do with its mainstream or niche status, I really knew next to nothing about the people behind it before starting working it. It was simply a case of thinking it was a great piece of software, and getting in touch asking if I could get involved.

I don’t think Renoise will ever be the perfect solution for everybody. And neither should it. It occupies a certain niche and provides a refreshing alternative to other computer-based music production software. Rather than heaping on shiny, new, big bang features, I’d like to gradually refine what we have, getting rid of all the little annoyances and limitations that are still there, and really make Renoise shine at what it does best, i.e. being a modern tracker.

Tips for newcomers: I’m all about workflow so here’s some (perhaps somewhat boring) tips that make life easier for me:

• Take advantage of the vast keyboard shortcut customisation options so you have everything at your fingertips. I have keyboard shortcuts set up to open all of the major tabs inside Renoise, for example.
• Forget about reusing patterns in the pattern sequencer, just always add new patterns into the sequence so that each pattern is unique, it saves a lot of headaches later on.
• Always set LPB to 8 and enable quantization to 1 line for new projects. I find that the most comfortable way to record with Renoise.

What think you, users? Those of you Renoise users trying the beta, we’d love to know what you think, and if you have any particular tips to share.

Max for Live, now into its second year, is a tool with an ambitious goal: take the custom music software creation, visual-patch-programming powers of Max/MSP, and put them inside live performance and production host Ableton Live. It’s not the only tool that allows you to hack your own instruments and effects, or customize how your music tool works – several hosts now offer scripting and patching options. But it’s both unique in its depth and breadth, and paired with the tool most popular with musicians for playing live, which puts it in a league of its own.

I personally like tools I feel are worth criticizing, and I think Max for Live fit that description. Members of the passionate Ableton and Max/MSP communities, perhaps most of all those who embraced Max for Live in their workflow, had some ideas of their own.

This week, Ableton is releasing the first batch of significant, non-bug-fix improvements to Max for Live since its release. You can try them right now in the just-unleashed 8.2.2 beta.

It’s not just about what Ableton is doing differently, though. Recently, Ableton also unveiled a set of guidelines for people making their own patches, with the hope of raising the bar and making patch publishing clearer and easier.

Daniel Büttner of Ableton offers his thoughts to CDM, including improvements to the Live API and the new “production guidelines” for people building Max for Live patches. It’s a detailed read, but I know we’ve got some hard-core patchers out there who will appreciate it. Daniel writes:

Max for Live has been around for over one year. As the community grew and produced more devices, we noticed the obvious weak points that every programmer was trying to work around, such as keeping parameter mappings intact.

A few months back, after Live 8.2 was released, we started working more closely with programmers in the community, listened to their problems and evaluated lots of devices. The two main issues we ran into were 1) limitations in the software that made it difficult to create reliable devices and 2) certain knowledge to program devices that work well in Live.

Top item on the list was the handling and persistency of mappings from a Max device to any Live parameter, which required clumsy workarounds. From what I have seen, the new persistent Ids allow programmers to reduce their Max code in a typical LFO by 60%.

live.object and live.remote~ now have an option “Save Mapping in Live Set” (Fig. 1)

Fig. 1: Save Mapping in Live Set better integrate Max for Live with your Live sets – a must for live performers, production.

Another improvement allows Max devices to observe the selected_parameter in Live via [live.path live_set view selected_parameter]. Max programmers can now build an intuitive Map mode into their devices (see example code below) or follow the user’s selection, which may be useful for certain hardware integration.

The Live API can now reach inside racks, so LFOs can be grouped with Live effects and saved as a preset.

Fig. 2: “This device” is a new Max object that makes it easy to design actions around a patch being opened.

A small feature that doesn’t show up in the changelog is a new Max object called live.thisdevice (Fig. 2):

“live.thisdevice reports two pieces of information about your Max Device. A bang message is automatically sent from the leftmost outlet when the Max Device is opened and completely initialized, or when the containing patcher is part of another file that is opened. Additionally, a bang will be reported every time a new preset is loaded or the device is saved (and thus reloaded within the Live application). A 1 or 0 will be sent from the rightmost outlet when the Device is enabled or disabled, respectively. Used within Max, live.thisdevice functions essentially like the loadbang object. The rightmost outlet is inactive in this case.”

The [live.thisdevice] helps timing in large devices to avoid sending values before the API has been initialized, etc.

Besides technical improvements to the software, we also want to share our knowledge with Max programmers to avoid common errors such as devices spilling into Live’s undo history or not recalling parameters correctly in a Live Set.

We’ve created a set of guidelines as a result of our own experience and known issues, a long evaluation of community devices, discussions with patch programmers.

Ableton Max for Live production guidelines [Ableton Forum]

I hope that everyone updates their existing Max for Live devices and takes advantage of these improvements as they make MfL devices a lot more reliable and fun to use.

The Production Guidelines offer lots of good ideas, including “pre-flight” checklists for technical details and presentation draw from months of experience with patches, compatibility notes for Mac and Windows, device latency, mapping, and the like. In fact, even if you don’t plan to distribute your work, it’s a great read.

Speaking of Guidelines, What About Licenses?

One issue Ableton have not handled is licensing of patches. This is likely a good topic for another article, but I can summarize my own recommendations, having talked to a range of developers and people familiar with open source software policy.

I would strongly endorse putting some sort of license document in your patches. The most important first step is, whatever your intentions for how your work is used, put it in writing. Legal agreements all begin with simply writing down what you mean; it’s when there’s an absence of information that misunderstandings most often arise. That doesn’t have to mean hiring a lawyer – thinking to yourself, then writing down, “hey, this is how I expect this to be used” is a good starting point.

If you want to release a patch to be shared and incorporated into other people’s work, the other good news is that there are licenses available that are tried and tested and do some of the work for you. That means other users can see a license with which they may already be familiar, and you don’t have to worry (as much) about the legal implications.

I understand the desire to apply “non-commercial” restrictions, but as I’ve written in the past, these provisions tend to be problematic. The problem is the lack of a clear line for what “commercial” is. If you simply don’t want others to reuse your work, you should consider traditional copyright – that’s your right as a creator. If you do want others to reuse your work and are simply afraid of abuse, the “ShareAlike” Creative Commons license and GNU Public License each require others to share any modifications you make. Those rules were created precisely because creators didn’t want to see their work appropriated by others just because you made them free.

The GPL is the license I’d recommend in this case, because it’s a mature, legally-tested license. It’s worth a read-through of the FAQ, because it clears up many misconceptions – for instance, you can charge for your (Max Patch, or other software), you can make commercial software, and the GPL requires others attribute you as well as release any modifications they make to a patch back to the public. That makes a lot of sense for the Max community, since it means the best of both worlds – other people can improve your patch, but they have to then release all those modifications, so you and others can benefit, and you can still sell your patch if you like.

Whatever you choose, I think it’s important to explicitly state your intentions. Then everyone knows the rules by which they’re playing. That doesn’t mean some people won’t disobey those rules, but I also fully expect the community to step in if they feel someone has failed to follow the rules. (We saw that happen on this site recently, of course.)

Disclaimer: these are my own opinions; I’m just adding them here as I think it’s an appropriate time to begin a conversation about this.

In the meantime:

Max Beta

8.2.2b3 is released as of this writing:
Current Beta Version: 8.2.2b3 (updated February 15, 2011) [Ableton Forum]

Changelog

** Improvements and feature changes **

(Note: Some of these changes require an update to the latest version of Max, find a download link above)

- Devices inside Racks can now be accessed via the Max for Live API
- Return tracks can now be observed via the Max for Live API

Live devices and parameters can now be much more easily mapped to controls in Max devices. And devices can safely be moved within a Live Set without breaking any existing mappings. The following
changes make this possible:

- There is now a simple way to observe the selected parameter via the Max for Live API, using “live.path live_set view selected_parameter.” This can be used to, for example, build a custom “map
mode” to quickly map parameters in your Live Set to controls in a Max device.
- Live objects like tracks, clips or parameters retain their identity (id nn) during operations like move, save/restore, cut/paste, delete/undo, the identity is global and can be communicated
via Max’s Send and Receive objects.
- live.object, live.observer and live.remote~ are now able to remember their target objects when Live sets or presets are saved and restored or when objects are moved within the Live set.

** Bugfixes **

- Holding a note while recording a MIDI clip and stopping the transport while the note is held would result in a silent note during play back

Have a test, and let us know what you think.

And I know a number of readers have complained this site has done a poor job of covering all the developments in Max for Live patches – yeah, uh, I am human, as it happens. So do let us know if there are patches you feel are especially important. A terrific resource:
http://maxforlive.com/

Trinity Audio Group and creative director Ronald Stewart have pushed the idea of a mobile music tablet since around 2005. I first saw what they were working on in the summer of 2006, as they readied a dedicated mobile DAW. But, at least from my vantage point, it’s really taken until now for some of the available hardware and software to evolve to the point that it could deliver on what they wanted to do. Products based first on Ultra-Mobile PC (UMPC) platforms and netbooks, while usable and more mobile than a laptop, required various tradeoffs. Linux software provided some significant power, but wasn’t yet an optimized experience for mobile use. I noted some of the promise, and shortcomings, in a review in late 2008 for Keyboard of Indamixx’s original Samsung hardware. (Keep in mind, this is all before anyone had heard of the iPad.)

Now, as they gear up for a 2011 release, Trinity have a new play to make a dedicated mobile music computer work. They’re offering a beta, starting now, for early adopters. I haven’t yet used the beta tablet, so I can only offer my personal perspective from my conversations with Indamixx.

There seems to be some confusion about what you get for the $699 price tag from an Indamixx 2 beta tablet. Engadget wonders why it tacks $200 on the price of the M1 Touch tablet on which it’s based. In fact, there’s more than $200 in bundled proprietary software, as well as customization of the free software. That makes Indamixx effectively a system integrator and the tablet a hardware/software bundle, rather than stock software. Synthtopia asks “does it matter,” as James Lewin argues for the greater “developer attention that the iPad has received.” That ignores the fact that what Indamixx represents – with one vendor’s customization work – is at its heart a Linux system. With compatibility with Windows VSTs, deep tools like energyXT, Ardour, Renoise, and LinuxDSP, and a host of free software like Pd and Csound, I’d say any Linux machine has an order of magnitude more music software developer hours behind it than iOS. That’s not to say it’s better or worse, but it is different: if you are musically productive in these more conventional tools, you may already have passed on the iPad.

The software bundle is the main source of value here, since the tablet you could buy separately. The beta includes various commercial, proprietary software, including file exchange support for Ardour, full copies of Renoise, energyXT, and superb plug-ins from LinuxDSP. There’s also software that, while free, could take a significant investment of time to set up, even for someone with some familiarity with Linux. That includes customization, tweaking, and configuration of the MeeGo Linux operating system, and packages for things like JACK setup. The beta also includes extras like access to a streaming server, accessories, and pre-installation of a multi-boot configuration. As Trinity has pushed before, one audio output option is HDMI, which provides multichannel outs without the need for a dedicated card (provided you have something to which you can connect HDMI on the other end).

I’m going to ignore the iPad versus Indamixx argument for now, tantilizing flame war bait as it may be. I think the software offerings are significantly different that people will have an easy time choosing. If you like the iOS apps, you’ll get an iPad. If you’re more productive in something like Ardour or Renoise, you won’t. If you want single-app experiences, you’ll go iPad. If you like interconnecting apps or using plug-ins, you won’t.

Instead, I think the question for the Indamixx 2 is how competitive other tablets may be. The “not-iPad” category now is small, but it may not remain so. Indamixx is betting big on MeeGo, but that Linux distro is relatively new and untested. The M1 Touch hardware features a capacitive touch input like the iPad, but I haven’t yet been able to use it myself, so I’m not sure how it stacks up in terms of display quality, touch quality, and overall reliability and performance. Many tech pundits, myself included, incorrectly predicted a slew of new tablets in 2010 to rival Apple’s, at least in hardware quality. But 2011 does seem a likely timeframe for new hardware. That means the question is whether you want to bet on Indamixx to customize your experience, or assume that you’ll set up your own Windows or Linux tablet.

Diving in on a beta now isn’t for the feint of heart. Trinity offers only 6 months free support for the system, and warns against “airing out” criticism publicly, instead asking for bug reports. (Support after six months is available for a fee.) I don’t see an indication of NDA, but I would like to see indications of how responsive Trinity is to criticism – and this is a significant investment of cash for something that lacks long-term support.

To me, the big competition for Indamixx 2 is likely to be, ironically, Linux and Windows themselves. Will Trinity’s solution rival your own Linux or Windows install in May 2011? And is the better solution for tweaking Linux – which, even with the addition of these proprietary apps, still depends mainly on free and open source packages like JACK and MeeGo itself – be Indamixx as a private vendor, or the free software community? The latter is a relatively open forum for participation, whereas Indamixx, in its beta, warns “no crybabies” in its invitation to beta testers.

What we need to see is whether Trinity can build on its work in this field to deliver a truly finished, polished product, and whether it can build the kind of support relationship with users, developers, and the press to make its solution viable. Laptops have that ecosystem, and Apple – love them or hate them – does with iOS. Now, we’ll see how Indamixx stacks up to what’s likely to become a more crowded mobile space in 2011. In 2005, Trinity was relatively alone in calling for mobile music systems based on Linux. By the spring, when it comes to the tablet space, we may be off to the races. We’ll be able to judge the finished product, and its rivals, then.

Beta site:
http://indamixx.com/indamixx2-tablet.html

Does the world really need another DAW / music production tool?

That thought has to at least echo a couple of times in the back of your mind as you see a new attempt to provide all-in-one computer music making tools. But there are reasons to pay attention to Ohm Studio, aside from the fact that the music making application comes from a fairly beloved plug-in developer. One is, the tool promises to approach real-time collaboration and community (or “cohmunity,” as they say) from the ground up. It’s a desktop app for the cloud. That may or may not be of interest to you, but it at least provides differentiation.

Two, this week we get to find out that the UI looks quite gorgeous.

Cid Andrade of Ohm Force writes CDM with three screenshots of the new interface for the upcoming beta builds. (Previously, we had seen only alpha UIs.) It looks clean and clear; there are strong similarities to GarageBand (which in turn borrowed functionally from Acid), but with some twists. There are quick-access edit tools, freely-routable plug-ins, and lots of integrated tools for collaboration.

Cid walks CDM through what’s in the beta interface and how it works; see the callouts in the image below. (Thanks, Skitch!)

Cid explains:

1 – Sequencing Panel’s “Macro Viewer”: gives an overview of the whole sequence. The movable focus-square has two functions: it allows the user to navigate within the macro viewer and easily locate and go to some region of the sequence, and also shows to all other session members which sequence region the user is working on. In this example, this focus-square is the one controlled by the user who’s actually seeing this screen. It’s over the current selected pattern. All other session members will also see this user’s focus-square, so they will know what he’s working on. There will be an efficient color code allowing a quick visualization of each session member’s focus-squares and current selections.

2 – In this example, the macro-viewer is displaying two focus-squares, what would mean that there are two members working simultaneously in this session. The user who’s actually seeing this screen also sees this second focus-square (the one belonging to the other member) and thanks to that can know where in the sequence he/she is working on. Still, in this example, one user may be editing some rhythmic parts in the sequence intro while the other one is starting to compose a bass line later in the timeline.

3 – This is the current selection of the user who’s seeing this screen. The other members can see a colored pattern in one of the focus-squares that the macro-viewer is displaying. By the color they’ll know which user is.

4 – These are the “power tools”. An user will be able to make all possible audio/MIDI edits using only these tools, as their function can be altered by pressing some keys (of course each edit action will have its respective keyboard shortcut so none will be obliged to use the mouse all the time).

5 – This is the Gear Panel, where the members of a session will place (and freely route) audio effects and virtual instruments (in addition of Ohm Studio’s own built-in effects, it will support VST and VSTI).

6 – The Gear Panel’s macro-viewer. Works similarly to the Sequencing Panel’s one, this time allowing an user to navigate within the Gear Panel (which is virtually infinite in area) to easily locate a specific region. It’s also useful to let each session member know on which Gear Panel’s region the other users are working on, and see/show each one’s current selections.

Thanks, Cid!

The beta is scheduled to start mid-December. There’s still time to sign up, says Cid, if you’re interested in testing.

http://www.ohmstudio.com/ask/for/beta

…and Ohm have plenty of other information about how they’re handling collaboration, community, and versioning, all essential when your project is shared by others:

http://www.ohmstudio.com/