They say one step in planning saves two in execution — and that certainly applies to doing a performance with Ableton Live.
Sometimes it seems as if there are as many ways to use Live as there are people who own it. For some, it's a digital audio workstation with amazing loop capabilities. For others, it's a DJ program. Some wouldn't think of using Live without Rewiring it into a host program, and others see it as a songwriting tool.
To me, it's a musical instrument that just happens to look and feel like a software sequencing program. And like any other musical instrument, it requires practice. Putting together one of my live sets involves a lot of preparation; this article covers the steps leading up to actually performing a remix-type set with Live. The three main steps for me, other than practising with Live itself, are:
- Optimise existing loops and create any additional loops that might be needed.
- Transfer the loops into Live and create and organise Scenes.
- Add real-time control.
In this article we'll check out the first two elements; real-time control will be the subject of a future article.
Goals For Optimised Live Loops
Live already has some excellent stretching algorithms, so why not just throw the files in there, and let Live do its thing?
The main reason is fidelity. What Live does in terms of preserving fidelity when doing complex real-time stretching is amazing, but using files that require no stretching, or that you stretch off-line using the highest possible fidelity and then import into Live, can improve the overall sound quality. However, note that in some cases importing a loop into Live will produce the best results because it offers algorithms other programs don't, so always try Live's stretching as well.
Another reason is compatibility. Live 5 doesn't support REX files, so if you want to use those, you'll need to convert them into WAV or AIFF files. Similarly, although Live can read ' Acid ised' WAV files, it does not read the Acid isation markers that optimise an Acid ised file for time-stretching. While this usually isn't a problem because of the quality of Live's time-stretching, there are situations where Live's algorithms will not stretch as well as carefully edited Acid isation.
For example, suppose you have a drum part with a repetitive 16th-note closed hi-hat pattern, but with some open hi-hats that last an eighth note. Using Live's Beats stretching option, you'd choose 16th notes in order to 'slice' the closed hi-hats properly. But because Live slices at every 16th note in beats mode, there will be a slice in the middle of the sustained hi-hat eighth notes that will probably add a discontinuity to the sound. If you set Beats to eighth notes, though, then the closed hi-hat parts won't slice properly (although they may end up with cool swing effects, depending on the tempo).
In this case, you may be better off bringing the Acid ised file into a host that reads Acid isation markers (such as Sony's Acid or Cakewalk's Sonar), time-stretch as needed, then export the file at the same tempo as the Live project so it slides right in without having to do any stretching. The reason I say 'may' is because some samples are poorly Acid ised in the sense that no-one took the time to edit the Acid isation markers for optimum results, so the files may very well sound better when brought into Live and stretched using Live's algorithms.
Yet another reason to create loops that, if used together in a Scene, are the same length, is that it makes it easier to 'track' what's going on in a Scene. For example, suppose a Scene's longest loop is four bars, and other loops are one or two measures — with off-line editing, you can copy and paste the one- and two-bar loops, then save as a four-bar loop.
Choose Your Algorithm
There are variables with each approach, but here are some general guidelines: REX files generally work best for percussive material with strong attacks. Using Propellerheads' Recycle program, it's often possible to create a stretched file with fidelity indistinguishable from the original. This is because Recycle uses virtually no DSP to alter the signal; it instead just slices the file into parts that get triggered closer together (to increase tempo) or further apart (to slow down the tempo). However, the REX format is pretty much useless for sustained sounds, unless you want to add a rhythmic element to them.
Acid ised files work very well for a combination of percussive and sustained sounds, as in the drum part example mentioned earlier. The same holds true for rhythm guitar, some bass sounds, keyboards and the like.
Live's stretch algorithms are ideal for 'general purpose' stretching, although the Complex algorithm is uniquely wonderful and can often provide the best possible stretched sound for complex material. Beats is good if a pattern is percussive and repetitive. Tones and Texture work well for pads, but require some experimentation to achieve the best results. It's worth trying a file with these algorithms as well as Acid isation to decide which sounds better; there are no general 'rules', as the results depend on the nature of the material, and the amount of stretching you need to do.
While You're Creating Loops...
In this application, I basically use Sonar as a 'loop development system' for Live. But even while using it, I also keep the ultimate goal in mind: a performance based solely on using Ableton Live. As a result, I'll bring over lots of loops, and use Sonar's solo and mute to get a 'feel' for which loops are most compatible. Loops that 'seemed like a good idea at the time' get discarded, while loops that are prime candidates get optimised and exported as WAV files for bringing into Live. I also place loops that work well together as scenes or sub-Scenes in Sonar Track Folders, and give them distinctive names — we'll see why that's important next. Once the loops get into Live, they go through another winnowing process so that only the best loops remain.
When creating a Live performance, I like to see all of the channels that are in use (most of my Sets use 16 channels). Short names allow me to use narrow channel strips, but this means that the first few characters of the name are crucial so you can tell at a glance what's in the channel. Note that using narrower channel strips does shorten the volume fader throw, but as I use a remote fader box, this doesn't matter.
If I'm on stage, the browser is of no further interest as I've collected my files in place beforehand, so I hide it. This gives more room for the Master Channel, which allows longer scene names that can instruct you about what needs to be done — for example, naming a scene 'Fader12-13<' means pull faders 12 and 13 down before switching to the next scene. I also hide the Clip View unless I need to do some real-time manipulation in that section.
Preparing REX & Acid ised Files For Live
Granted, this section isn't strictly about Live tips, in the sense that they require the use of other programs. Still, the reason for doing this is to produce the best possible Live performance, so bear with me — the results are worth it. Note that these techniques assume you know what the ultimate project tempo will be in Live.
We covered how to process a REX file for use in Live in the April issue, so refer to that article for details. For those who missed it, the basic idea is to import the file into Propellerhead's Recycle program, set the tempo to the Live Project's tempo, optimise the loop's stretching at that tempo using Recycle's available tools, then export the file as a single sample suitable for importing into your Live project.
To optimise Acid ised files for use in Live, there are two main tools: Sony Acid and Cakewalk Sonar. Before describing the process, though, we need to discuss Acid isation briefly.
As with REX files, Acid isation depends on finding discrete blocks of sound, and marking their start points with markers (the end of one block is, de facto, the start of another). As with REX files these are stretched, but there is also a significant amount of DSP brought into play, especially with sustained files. Suppose there's a marker every quarter note with a sustained pad; Acid will apply crossfading and DSP-based stretching to try to make as smooth a sustained sound as possible. This is simply not possible with the REX protocol.
Because of the stretching and crossfading, it's essential that the Acid isation markers be placed properly with percussive material. If a marker goes before a percussive transient, you'll hear flamming when the file is slowed down because the single transient gets stretched into two transients as the algorithm strives to 'fill up' the space between where the marker falls, and the actual transient. This is a particular problem with drums played by a human, as hits may be slightly off the beat.
Marker placement with sustained sounds is not as critical; proper placement often involves experimenting and listening to what sounds right. For example, with some pads it's possible to put a marker every quarter note, or every whole note.
Acid isation is an art as much as a science, which is perhaps why many libraries suffer from sloppy Acid isation. If you stretch poorly Acid ised files, they'll probably sound worse than if you just used Live's algorithms. However, if you're savvy enough to edit the markers, you can often stretch a file over a wide tempo range (typically -20 to +100 percent) with excellent sonic results.
When Acid ising non-Acid ised files, I find that Acid Pro 5 does a better job of analysing files and placing edit points; but for editing existing files, Sonar 5 offers additional features (the ability to change pan, gain, and pitch for each slice) that you might want to exploit.
Here's the basic procedure to prepare Acid ised files for use with Live: begin by loading the Acid ised file into Acid or Sonar and adjust the host tempo for Live's project tempo. Edit the Acid isation markers for the best possible sound quality at the target tempo and save the file as a WAV or AIFF file. With Acid, this is the usual save procedure. Sonar does the same thing, but there's also a shortcut — drag the Acid ised file to the desktop, and it's saved.
Another tip is that if the file is a straight WAV and hasn't been Acid ised, I check to make sure the file will loop without clicks. If not, I'll add a fade at the attack, decay, or both, depending on what's needed prior to adding the Acid isation markers.
This isn't absolutely necessary, as Live has a clever Fade option that does this automatically. However, as you can probably tell, I like to get everything as close as possible to ideal before the file goes into Live.
Optimising Loops In Live
Well, we're just about done with our preparation work: the files have been optimised, imported into Live, and collected into an initial collection of Scenes. But there are still a few more tweaks we can do within Live itself.
First off, Live 5 allows you to set parameters for multiple loops simultaneously — you no longer have to do things like changing all Clips to RAM Clips one at a time. Either click and drag around the Clips you want to edit, or select a Clip then Shift or Ctrl-click (Shift or Apple-click) to select additional Clips.
Because the loops we've described are already prepared at the project tempo, you don't have to do any complex stretching and can simply Re-pitch the selected loops should there be any slight timing differences of a few samples here and there. Of course, you don't want to do this with loops that you're stretching using Live's stretch algorithms.
Another use for editing multiple Clips simultaneously is converting them all into RAM Clips, which is especially important with laptops. Laptop hard drives tend to run more slowly than desktops (5400 vs 7200 or more rpm) for both noise and power-consumption considerations. With a 5400rpm drive, even trying to run 20 or so Clips will probably cause audio problems because the hard drive can't keep up. Converting as many Clips as possible to RAM Clips (consistent with your computer's ability to hold them) solves this problem.
Our last two tweaks are simple: Turn off Hi-Q to reduce CPU drain if needed (but leave it on if your computer has enough power), and turn off Fade if you added a short attack and decay as part of the loop preparation process. If you didn't, then enable Fade on a per-loop basis if needed to eliminate audible clicks when the loop repeats.
The only remaining preparation work is to hook up a control surface, as it's a whole lot more fun to slam faders than it is to do everything through a mouse and keyboard. But interfacing with Live is another story, for another time. See you then!