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.
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.
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.
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.
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!
- Powerful comping feature operating inside audio clips.
- Expression spread adds randomness and variation to notes and audio events.
- Operators for notes and audio act as algorithmic compositional tools.
- No comping of MIDI input.
- Import of Ableton Live sets is partial at best.
Bitwig Studio 4 strengthens the DAW’s position as part composition system, part modular music engine. Comping combines multiple takes with creative audio slicing at the clip level, while operators facilitate patterns and add randomness to notes and audio events. The result is a bigger box of creative tools for experimentation and production.
- Apple MacBook Pro (Mid 2014)
- macOS Catalina 10.15.7
- Bitwig Studio 4.0.1