-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Bline is an acid-style parametric bassline sculptor inspired by the "Topographic Drum Sequencer" concept developed by Mutable Instruments and initially used in their Anushri DIY synthesiser, later forming the basis of their Grids Eurorack-format module.
It takes the form of a Lua script for the Norns Sound Computer platform by Monome, and will run on an original Norns, the DIY Norns Shield or Fates hardware.
Bline creates bassline patterns which can be played by standalone hardware or virtual-instrument Roland TB-303 emulators via MIDI.
Patterns are created in realtime based on values looked up from a hard-coded dictionary of random values. A number of parameters are provided to shape and transform the resulting patterns.
In developing the script, I was working towards fulfilling the following requirements:
- Generated patterns should not be random! The same parameter values should always produce the same patterns
- Small changes to parameters should produce small changes in the resulting pattern, larger parameter changes should produce more extreme changes in output
- Parameters should be easy to understand, and easily "performable"
- The most important parameters of the script should be exposed in a simple user interface on the Norns display
The basic concept underpinning Bline (and borrowed from Anushri/Grid) is that of a matrix of "pattern nodes". Nodes are arranged in a notional 2-dimensional 5x5 grid. Think of it like a map - a pattern map.
Each of the 25 nodes consists of a 16-step note pattern.
Parameters are provided to set the coordinates of an imaginary point on the pattern map.
At each sequencer step, the script looks up the values for the current step in the 4 pattern nodes around the selected coordinates.
It then blends these values based on the distance to each of the nodes.
The result is a continuous, navigable "pattern space", where patterns morph smoothly in 2 dimensions.
In the original MI implementation, each pattern node consists of 4 "channels", each consisting of 32 steps.
- Bass drum
- Snare drum
- High-hat
- Accent
Data for each channel was extracted from an analysis of iconic drum patterns.
The clever bit is that, rather than the step values for a given channel representing simple binary on/off switches, the pattern is actually encoded as a series of probabilities that a drum will be triggered on that channel/step.
This allows for a threshold value to be set, which can be compared against the probability values encoded in the node. Probabilities above the threshold value will cause the drum to be triggered, thus changing the threshold allows changing the density of the played-back pattern, from completely silent at one end of the scale, to a trigger on every step at the other.
This probability-based setup is what allows pattern-morphing to happen. Because probability values are numbers rather than binary on/off switches, they can be interpolated between nodes.
While The purpose of MIs “Topographic Sequencer” is to create 3-channel (plus accent) trigger patterns to trigger drum sounds, the requirements for bline’s implementation of the concept were slightly different.
To determine how many channels would be required for each pattern, and what kind of data needed to be generated, the best approach seemed to be to look at the parameters that defined a step on the original Roland TB-303 sequencer.
It turns out the 303 sequencer is somewhat eccentric in operation, compared to more recent step-sequencer type devices. Specifically, the way step-length is defined separately from pitch and other properties (a feature shared with the 303s near-contemporary MC-202) seemed to many particularly counter-intuitive.
Emulating it would also complicate the sequencer logic considerably, so I elected to use a more conventional fixed step-length instead.
The remaining step properties are:
- Note
- Octave
- Accent
- Slide
- Rest
- Tie
I decided to add node channels for all these properties, with the exception of tie.
Since a tie is effectively the same as a slide to the same note, I decided not to add channels for both slides and ties.
I’ve had various ideas about implementing note-tie, but haven’t settled on a method that really makes sense, from a usability perspective. Something for the to-do list.
Looking at the channel list above, it’s evident that the type of data that needs to be produced by each channel is of two types.
- Binary on/off type (Accent/Slide/Rest)
- Integer (number) (Note/Octave)
Type 1 channels can be implemented using data representing trigger probabilities, compared against a threshold value set by a “Density” parameter, as described above.
For Type 2 channels, the simplest approach is simply to use the (quantised) weighted blend of 4 step values (equivalent to probability values in Type 1 channels) directly as note/octave values, allowing these properties to be smoothly interpolated when navigating “pattern space”.
Simple is often best (and I’m not a great coder), so that’s what I decided to do!
For this channel type, a “Density” parameter doesn’t make sense, but more data is processed in other ways (primarily by the Quantiser module, see below) before eventually appearing at the output.
Incidentally, it might be argued that Note and Octave could be combined to produce an absolute note index, thus eliminating the need for one of the 5 channels.
However, I felt that keeping them separate would allow for much more variety in the generated pitch sequences when combined with the additional channel parameters detailed in the “Extending Grids” section below.
As mentioned above, the pattern data Emilie used in Anushri (later re-used in Grids), was derived from a corpus of MIDI drum patterns.
Machine-learning-derived analysis techniques were then used to sort the resulting 25 pattern nodes into a 2D grid where similar patterns appear closer to each other than less-similar ones.
Lacking Emilie’s theoretical background in computer science, I’m unclear on what basis “similarity” is defined in this context, and this aspect of the MI product’s development doesn’t appear to be documented, unfortunately.
My first thought was to attempt the same for Bline - ie transcribe 25 of the many published “famous acid patterns”, and attempt to apply the same mathematical voodoo to create an equivalent bassline pattern-map.
Unfortunately, I didn’t have the first idea where to start, in terms of analysing and sorting this initial data.
There’s another issue, though, that rather lets me off the hook here.
I began to feel (conveniently) that I didn’t want Bline to turn into a kind of “morphing best-of” compilation of classic 303 basslines.
While I had some concerns around copyright issues, it was mainly that I wanted using the script to be an exploratory process, and I felt that the sudden emergence of part of “Da Funk” by Daft Punk (for example) would be an unnecessary distraction.
With that in mind, filling the patterns with random values seemed like the simplest and best solution.
To increase the variety of patterns available, and the chances of “happy accidents” (and because I’m lazy, and poor at maths), no attempt was made to sort the nodes in any way.
I may attempt some kind of 2D sort in the future, but for the moment, the random values seem to produce quite nice results.
To compensate for the inherently unmusical nature of the random number-based pattern-generation method used, I thought of implementing a number of additional channel parameters.
- Pattern-Length
- Start-Position Offset
- Coordinate Freeze