-
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. An internal bass synthesiser SuperCollider engine is also provided for standalone use.
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 properties, which combine to create the MIDI note data that forms the output of each step 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 both Note and Octave data is processed in other ways (primarily by the Quantiser module).
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 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 implemented a number of additional channel parameters. They were all pretty easy to add, and I like low-hanging fruit, when it comes to coding.
Allowing independent lengths for the channel patterns makes possible poly-metric effects where channels are able to slip out of phase with each other as the virtual "playhead" wraps back to step 1 before reaching the last step of the channel's pattern. I also added a master reset option Loop Length to reset all channels to step 1 after a selectable period of 0.5 to 16 bars.
Since there is no "intuitively correct" start-point for Bline's bassline patterns (unlike Anushri/Grids' drum patterns), I added a step-offset parameter for each channel to bring additional variation. There is also an option to offset the start-point of the whole pattern using the Master Offset parameter.
Since this also essentially "came for free", I added an option to freeze the XY Position of each channel to "lock in" a particular Note/Octave/Accent etc. sequence while allowing other channels to continue to respond to the master X and Y coordinate controls.
The Grids Eurorack module features a "Chaos" parameter that adds per-step randomisation. I've included a similar feature in Bline (though from memory, I think it's implemented slightly differently), but have included additional per-channel parameters to scale the master chaos/jitter amount, to allow more control over pattern randomisation.
See subsequent pages of this wiki for more details of all the parameters exposed by the script.
Bline was envisaged as an improvisational instrument and works best when parameters can be controlled in real-time via a MIDI or OSC control surface.
Because many of the basic controls are identical for each of the Bline pattern channels (Note/Octave/Accent/Slide/Rest), and there aren’t too many of then, a controller that allows the controls for each channel to be grouped together works particularly well.
While developing the script, I used a Novation Launch Control XL. This proved to be perfect, as the 4 most important parameters for each channel fitted the 3 rotary pots and 1 slider of a notional vertical channel on the hardware.
Since the LC XL has 8 of these “channel strips”, there were enough controls left for mapping to the principle Global and Quantiser parameters.
I was also able to map 4 parameters of the internal bass synth engine to the final controller channel strip.
See Bline Parameter Mapping page for more details.
In no particular order:
- Additional output modes
- Updated Quantiser module
- Additional assignable functions for K3
- Momentary pattern-transform FX
- Grid support for specific parameters (pattern-lengths, offsets, pattern-transform FX)
- Arc support for key params
- Preset system (instant save/recall)
- MIDI file export
- TouchOSC template
- MIDI controller feedback for eg FaderFox EC4
- LFOs
- Do something with the unused 6th channel
This is a personal spare-time project, and I'm a hobbyist programmer, so no guarantees all (or indeed any) of these additional features will be implemented.