Bitwig continues to blur the boundaries between instrument and DAW, while offering some welcome practical enhancements.

Bitwig Studio seems to be living its life at something of an accelerated rate at the moment. We are seeing a major release once every couple of years, which is quite an aggressive schedule, and the expansion of features from each version to the next also tends to be quite considerable. Version 3 brought us The Grid, a fully integrated modular synthesis environment, nudging Bitwig into becoming an instrument or algorithmic composition tool. Version 4 is another step in that direction, but mostly at the level of sequencer events: notes, audio fragments and loops. So let’s see what’s in the box...

Comping

Bitwig Studio now supports audio comping. Users of Ableton Live 11 will be familiar with comping as a way of laying down additional takes within the linear arrangement. Bitwig supports this too, but its notion of ‘take’ is slightly different.

To fully make sense of how Bitwig supports comping, it might help to recall how it structures clips. A Bitwig audio clip is not a single piece of audio: it’s actually a sequence of consecutive audio ‘events’, analogous to notes in a MIDI clip. Think of comping as a way of also stacking audio events vertically, in separate takes. What makes Bitwig’s comping unusual — and powerful — is that the takes are encapsulated within clips, not just in the project’s linear arranger. You want multiple takes in the clip launcher? You got them. If you copy and paste clips, the takes come too.

The obvious way to work with comping is to set a loop in the arranger. Each trip round the loop adds a take to any audio clips which are currently recording. If the recording process starts before the beginning of the loop, then the first take will be longer than the subsequent ones.

Any attempt to record over an existing clip will incorporate a new take into it, rather than replace it. If you do a recording pass over a sequence of clips, each will accumulate a new take, while any gaps in the existing track will be populated with new clips. This does mean that a ‘single’ recording can get rather confusingly fragmented across multiple clips, although the track will play back fine. (A subtle bug which can cause audible clicks in this situation should be fixed by the time you read this.) If this sounds confusing or inconvenient, I recommend clearing out any audio track that you are planning to record into.

I’ll mention one ‘gotcha’ in the linear take recording process: if the arranger clip has its own internal loop then any attempt to record over it will, well, record over it. Adding takes in this situation was perhaps considered too complicated to implement, or perhaps too complicated to be useful.

Since the clip launcher doesn’t have a timeline or a global loop, setting up comping here requires the take length to be set explicitly. Turn on Record as Comping Takes from the Play menu and set the take length in bars and beats at the same time. Any clip containing multiple takes is marked with a little icon at the right hand end of its title tab.

Stop recording half way through a clip, and you end up with a combination of the last two takes, split at the ‘punch out’ point. Split points separate editing regions across all the takes: click into any take, and its audio for the clicked region will be made active at the top of the clip. You can walk around the various takes and regions with the arrow keys, auditioning different combinations. To subdivide into smaller regions, click and drag horizontally inside a take. You can drag the boundaries between regions to change their size, or you can even ‘peel back’ a region in the composite view to create a gap into which you can link another take.

If you click the Audio Events button on the left of the clip view, you’re back in the world of multiple sequential audio events within a single clip, with no sign of the comping machinery. Well, almost: the audio regions are still coloured, indicating that these are still links into the original takes, even though Bitwig’s menus now refer to these audio areas as ‘events’ and not ‘regions’. Perform any serious editing here, and the link to any take is broken, as a ‘region’ gets demoted into a plain old ‘event’. Switch back to the comping view, and the editing area is now grey, showing its disconnection. (You can still click on another take region to replace it.)

There are a few editing operations which can be applied to take regions without ‘breaking’ them. Regions can be resized by moving a left or right boundary, or sliced into smaller portions. Their audio gain can be adjusted, and the underlying audio can be nudged forwards or backwards in time.

Bitwig’s implementation of comping is versatile and logical. Implementing comping within clips, rather than within tracks, initially seems a little strange, and results in some rather odd outcomes: a single linear recording can create takes within several clips, and there is no overall ‘comp view’ across the arrangement. But for modern, bar‑oriented music, the comping machinery can be repurposed as a creative tool at the clip level, which is a more‑than‑fair trade‑off. Being able to edit comps from rhythmic fragments of material whilst working in the clip launcher feels like a really empowering workflow development.

Operators

Bitwig Studio has slowly been growing into a kind of hybrid environment somewhere between DAW and modular synthesizer. Version 2 saw the arrival of ‘modulators’, which allowed arbitrary plug‑ins to be extended with additional control components like LFOs, envelopes and step sequencers. The concept was pushed further with The Grid, the modular synthesis environment introduced in v3.

Any kind of modulation system, especially one which can randomise its behaviour, potentially pushes the composition process away from literal notes and towards musical ‘systems’ where the composer builds structures which generate note‑like events, possibly in unpredictable ways. Bitwig 4’s operators (unrelated to FM synthesizer operators) are an attempt to bring in a kind of modulation feature at the level of sequence data, whether that’s MIDI notes or audio events in a clip. From a synthesist’s perspective, you can think of operators as a kind of modulation that’s applied whenever a note is played or an audio event triggered.

Before we look at operators proper, it’s probably worth revisiting a feature of Bitwig that’s been present since version 1, namely histogram editing. Select a set of events such as notes or automation points, and it’s possible to edit them as a group: a histogram display shows all the values as a continuum, and they can be shifted, scaled or randomised in a single operation. A histogram is purely a temporary editing shortcut, an alternative to manually editing each of the individual events. Once altered, values remain fixed until another edit.

The first step into the world of operators is through a feature called ‘expression spread’. This is similar to scaling using a histogram, but is dynamic: there’s no editing of the values, but before every playback pass, the values are randomised within a spread range.

Looking at MIDI data rather than audio for a moment, it’s possible to apply a ‘spread’ to note velocities — rather than having a single velocity, a note can be assigned a velocity range (a percentage variance from a central value). Every time a clip is triggered, or each time its loop restarts, actual velocities are assigned randomly within the range and the notes are played. Not all notes have to have the same spread, or any at all — it’s on a note‑by‑note basis. And to add a layer of editing sophistication, since velocity spreads are editable properties of notes, you can select a whole set of notes and then alter the spreads in a histogram.

How much effect velocity randomisation has depends, of course, on the instrument that the notes are playing. For most off‑the‑shelf instruments. you’ll probably get some variance of loudness or brightness, but this kind of controlled randomness might hint at some sound‑design ideas: start with a quantised MIDI loop for drums or a rhythmic synth motif, and dive into editing the response to velocity in more radical, unconventional ways. Even a simple trick like layering two instruments on the same track, using note filters to pick instrument according to velocity, can really animate a simple musical sequence.

For instruments that support MPE, we can play similar games with per‑note performance data (timbre, pressure and pitch‑bend). Unlike velocities, this data is notionally continuous, like automation, so the spread is applied to control points of the data, not just at note‑on. I’m struggling a bit to think why I’d want to randomise pitch (except perhaps for slight detuning), but random timbre or pressure could animate the tone of individual notes within a chord each time it’s played. Audio clips support expression spread as well, for gain, pan, pitch and formant.

Random Interlude

At this stage we should probably talk a little about how randomisation works. It’s all well and good to apply random processes to musical composition, but sometimes a particular roll of the dice will yield a good result which you want to keep (or which your client wants to keep), making a degree of reproducability important. Based on what we’ve discussed so far, each clip launch or trip around a clip loop starts with a randomisation process which replaces what happened the last time through.

The arranger is generally where we want to start setting material into its final, mixed, form. Bounce‑record a clip from the launcher into the arranger, and sure enough the randomisation when the clip is played is completely repeatable. If the clip has a loop, the loops will be distinct, but the clip as a whole will always sound the same. You can even start playback part way through the clip, several loops in, and have it behave as if all the randomness has been rendered in place, regardless of how many times it’s been looped.

This stability is achieved by random seeding. There’s no such thing as a truly random number generator as far as computers are concerned, so what they do instead is build repeatable chains of randomness from a single initial numeric seed value. If that seed can itself be randomised in some manner every time a clip is launched, then everything else seems to be random. Fix a clip’s seed, and all of its random behaviour becomes repeatable. Every clip has a seed setting: if it’s set to ‘random’, then the chain of random values is recalculated on every clip launch. Click to ‘capture’ a random seed, denoted by a pattern of rectangles, and everything becomes repeatable.

Operators Redux

Let’s look at operators proper. There’s a group of condition functions that can be applied to any event — a MIDI note or an audio event in a clip. These act as filters, deciding whether that event will play or not. In fact, only the first of these functions, prosaically called ‘chance’, makes use of the random seeding described above. The others are more computational, generally depending on the current state of a clip whilst it’s playing.

Chance is simply a probability that a note or audio event plays — or doesn’t. Select one or more events and set the chance to any value between zero and 100 percent. In the clip view, the event is annotated with a small dice icon, showing a number of dots between one and five as a rough visual indicator of the chance, and there’s also a graphical editor view — and the histogram view — for editing them.

Like spreads, the event chances in a clip are calculated when the clip is launched and again every time it loops: the events are visually highlighted each time according to whether they will play or not.

The repeats operator effectively cuts a note or audio event into slices, although the operation is non‑destructive: think of it as a stuttering effect, or adding grace notes in a musical score. The subdivision can be calculated according to the length of the original event (cut into halves, thirds, etc.) or according to the time grid, placing the repeats on a subdivision of beats. In the former case, the division points will scale or ‘stretch’ with the event if it is resized; in the latter, division points will be added or removed to keep the specified grid spacing. The grid‑based divisions are not restricted to powers of two, either: if you want 37 repeated notes in a bar, perhaps to add a bit of a Conlon Nancarrow groove to a piano part, feel free. Certainly, divisions into thirds and sixths give you plenty of options for polyrhythms.

For MIDI notes, a response curve allows the velocity to be scaled up or down along the repeats, allowing for some dynamic change along the event; sadly, there’s no way to apply such a curve to the amplitude of repeated audio events, so that would need to be done with automation. Also, it would be nice to be able to add a curve for other properties, such as pitch or timbre, through the repeats.

A feature which is shared between notes and audio events is the ability to shift the timing of the repeats into an accelerando or ritardando phrasing, to add some speeding‑up or slowing‑down interest to drum fills or other effects, for a bit of a Rival Consoles vibe. A note‑with‑repeats or audio‑event‑with‑repeats is still a single event from an editing perspective, so other processing like spreads and chance applies to the entire event with repeats, not the individual repeats themselves.

The recurrence function is another filter, causing events to either play or not. For an event you can specify a recurrence length (from two up to eight) which is used to count the clip loops as they repeat. For each ‘lap’ of the loop in this recurrence length, there’s a toggle box to indicate whether the event plays. Once past the recurrence length, the process starts again. The best way to think about this (or, at least, the way which works for me) is to imagine the clip loop unrolled linearly over time. A recurrence length of two makes the loop twice as long, duplicating all the events but letting some of them play only in the first half, or the second. A recurrence of three makes the loop three times as long, and so on. If you stack up some dense drum parts in a short loop and then thin them out by adding recurrence with differing lengths, you get longer, more engaging rhythms really quickly. At the very least, if you often find yourself doubling the length of a MIDI loop, duplicating all the notes, and then selectively editing or removing notes in one half or the other, This will save you a lot of time and be more manageable. Little icons at the end of notes or audio event tabs in the clip view let you keep an eye on what’s going on.

Occurrences

I’ve left ‘occurrence’ until last because it’s probably the most complex, and most subtle, of the filters. As with recurrence, an event plays, or not, according to some calculations made about the state of the clip. An event can be made to play once only when a clip is triggered. (This means the first occurrence of the event: jump into the middle of an unrolled loop in the arrangement and the event won’t play.) Or an event can play every time except the first. An event can be made to play only when the previous event did, or only when it did not. For MIDI clips, the playback can be dependent on being the same (or different) note pitch, or same or different MIDI channel. (For some reason, these conditional events don’t get highlighted dynamically during playback according to whether they trigger.)

Occurrence can also be established by the state of a global ‘fill’ toggle, presumably intended to be mapped to a MIDI footswitch to add fill parts to a drum pattern. There’s only one fill control in the entire session; I’d quite like to have had one per clip (or at least per track), but you can at least automate it in the project’s master track.

The subtlety of occurrence involves simultaneous notes in a chord: if the notes are all set to not play after a previous event, will they interfere with one another, and which notes will actually trigger? Bitwig very neatly sidesteps this problem by treating all notes at the same time location as comprising the same event, so every quantised chord is ‘atomic’: it either registers as a played event for following notes or it doesn’t.

There’s a lot to digest in the operator machinery, given how individual events can influence those downstream in a sequence according to potentially complex combinations of rules. The Bitwig press release states that the operators work “in parallel”, though to my mind it’s more ‘in series’: any one of them can remove an event from playback, and that can then cause alternate events to trigger instead.

The ability to combine occurrence and recurrence to ‘unroll’ simple melodic loops into more sophisticated forms is something I found really engaging as a creative process.

I’ve long been a fan of randomness in composition, and it’s one of the first things I jump to in any device or environment I use, but with Bitwig’s operators it’s best used sparingly. The ability to combine occurrence and recurrence to ‘unroll’ simple melodic loops into more sophisticated forms is something I found really engaging as a creative process. It’s a bit of a shame that note repeats can’t be made conditional in some way; you can hack the effect by placing two identical notes in the same place, if they’re on different MIDI channels, and alternating between them, but it’s a bit of an effort. On the whole, though, operators form a sophisticated toolbox, letting you transform the base metal of a simple step sequence or drum pattern into the gold of a longer, more varied and engaging musical idea.

Other Enhancements In Studio 4

There are other low‑profile — though non‑trivial — enhancements that have arrived with Bitwig Studio 4. On the Mac, there is now native support for the M1, Apple’s new ARM processor architecture. There’s lots to be said about the M1 in relation to music software, although as the owner of a seven‑year‑old Intel Mac, waiting for the next generation of ARM machines to arrive, my thoughts would be somewhat speculative.

One thing that Bitwig have achieved, however, is to port version 4 to the M1 processor whilst maintaining support for legacy Intel plug‑ins (which, at this stage, is still most of them). This is to some extent an accident of fortune, because Bitwig has always had the option to host plug‑ins in a separate process from the program proper. This allowed the roll‑out of an M1‑based DAW using Intel‑based plug‑ins, which is at the moment the best of both worlds, and should allow for a smooth transition from Intel to M1 over the coming months and years. Any Intel code still needs to be passed through Apple’s Rosetta 2 translator, and it’s not clear what the performance gains are for Bitwig on M1 given that most of a DAW’s CPU load is from the plug‑ins themselves, unless you stick to the built‑in devices. But this does mean that Bitwig can steam ahead with M1‑based development and not leave users with their legacy instruments and effects behind — at least as long as Apple support Rosetta.

Bitwig 4 also claims to be able to import projects from other DAWs, quoting FL Studio and Ableton Live as supported formats. I was rather sceptical about this, and found my scepticism pretty much confirmed. Bitwig loaded projects from Ableton Suite 11 without much complaint, but they were, to say the least, incomplete. Some track names and instrument names were missing. A drum rack imported with a complaint about missing samples, which is odd because they were in the standard place in the Live project; importing them manually didn’t fix things. An attempt to import Live’s native Wavetable synthesizer, obviously doomed to failure, resulted in a rather arbitrary instance of Bitwig’s Polymer synth with a completely different sound, although to be fair it did have the correct preset name. An Ableton Live flanger did miraculously make it into Bitwig sounding pretty much unfazed (as it were) by the ordeal.

VST presets seemed unharmed, and MIDI clips seemed to transfer OK (even those with MPE gestures!), although the story with audio was a bit more mixed, as a syncopated warped drum loop in Live transformed, not entirely disastrously, into a pattern containing fragments in triplet time. Track groups and routings were intact, as were the positions and MIDI data of arrangement clips, but any kind of automation was basically dropped on the floor.

The question to ask yourself, faced with a copy of Bitwig Studio 4 and an Ableton Live set, is what you want to achieve and how much work you are willing to do to get there. Porting track setups, clips (launcher or arranger) and third‑party plug‑ins seems pretty robust. Anything more complex or more Ableton‑specific and you’re in uncharted, and probably unchartable, territory.

I’ve been growing more fond of Bitwig Studio through the years as it has matured from DAW into a well‑rounded compositional system, with sophisticated modulation features, an internal modular synth and considerable versatility in some of its built‑in instruments.

Conclusion

I’ve been growing more fond of Bitwig Studio through the years as it has matured from DAW into a well‑rounded compositional system, with sophisticated modulation features, an internal modular synth and considerable versatility in some of its built‑in instruments. The comping feature in version 4 is surprisingly powerful by virtue of being implemented at the clip level, allowing for some creative applications, while the operators open the door to new algorithmic compositional techniques, complementing the modulators at the device level.

I can’t think of any real down sides to the new release, but at the risk of pointing out the obvious: this impressive music environment is, at the end of the day, all screen‑based. Do explore and exploit all that it can do, but don’t forget to get out into the real world with a physical controller and actually make some music!