Or a “Re-imagination of the Step Sequencer Paradigm”
As I continue down my research for algorithmic music processes, I’m working hard at constructing modular, building blocks in MaxMSP. Through this recent work I’ve created modular components dealing with probability, simple synths, envelopes, etc. So my mindset has been “Modularity!” and not just because it’s a good idea but because I’m still ineffective at planning and structuring more elaborate projects. This is how I decided to approach a traditional step sequencer. The first component I needed to develop was the “step” component. This is where I realized the limiting assumptions of “sequencing” data.
As I worked my way through analyzing my needs for a step sequencer, I separated the concept into a few smaller parts: a step, a time control, a timeline.
My earliest introductions to music sequencing were with Cakewalk Pro Audio and the hardware sequencer on a Korg N364 (still one of the best). I was eventually introduced to step sequencing through the Korg EA-1 and Fruity Loops. The assumed structure of both approaches goes like this: Place data within grid. Sometimes you can control the grid. Done. There are of course alternatives such as euclidian sequencers and likely other options out there. Considering how any form of data can be translated into any other form of data (practically), music sequencing is theoretically limitless. You can turn a series of tweets into musical information. You could claim to control those tweets and thus “sequence” your music based on its set of rules. On a pragmatic level however we deal with common sequencing paradigms.
As I worked my way through analyzing my needs for a step sequencer, I separated the concept into a few smaller parts: a step, a time control, a timeline. Traditional sequencing ideas can neatly fall into these categories. Let’s hold it up against the euclidian approach for a moment:
- A euclidian sequencer uses circles, a radius, and its circumference in order to understand timing and additional data.
- A line representing the radius would move within the circle at an arbitrary rate. The rate is the time control and the circle could be called the timeline.
- Nodes might be placed within the circle with varying distances from the center; the nodes represent sound/music/data. These could be called steps.
- When a radius crosses a node, it is triggered. This type of functionality basically abandons a common grid system.
A euclidian sequencer is a pretty exciting approach but I stumbled across another funny way to structure sequenced information. A method that could mimic a step sequencer and a euclidian one but with more options.
Separating the “step” from the timeline and time control source
Since my original intention was simply to build a traditional step sequencer in parts, I first started on the component I’m calling the “step”. I decided to combine a few features such as the playlist max object which plays samples, a custom envelope I call “ADXR”, signal input, and one additional, curious feature: bang output. This is where I realize the step sequencing concept can be tweaked.
The bang output–for non Max users, a bang represents a trigger data–leaves the step object after a duration of time. In other words when a step has a duration of one whole note and is triggered, after a whole note transpires the bang output occurs. That output can then trigger another step. Repeat. Let me describe it more carefully:
- Step object receives a trigger
- Step object plays a sample (a kick drum for example)
- Step object counts down the defined duration that is input into the object (for example a quarter note’s length)
- When the duration ends, a trigger output occurs.
- The output can trigger anything else including another step (for example a snare)
My audio examples are still in their “autechre” phase
I’ve designed the steps to receive notation based times and milliseconds. So it can work without a grid system (by grid I’m referring to structured times). A kick drum plays. We wait 200ms. The snare plays. We wait 1 quarter note. Another snare plays. We wait 100ms. A hihat plays…
Here’s where it gets interesting. This modular setup allows for a feedback loop. A sequence of loops can trigger itself in a cycle. A structured rhythm can be set up to follow a strict time OR a step can occur based on millisecond durations which aligns with some of the qualities of a euclidian sequencer (some qualities).
If you wanted to fully mimic a euclidian approach, you would want to create multiple feedback loops with at least two steps (Max does not allow one object to loop back into itself without a few caveats). With multiple feedback loops like this you could trigger them all and copy the euclidian approach. However this is just the start. Before I list other possible scenarios I should admit that this isn’t necessarily innovative. It’s not ground breaking. Many people using MaxMSP–and similar technologies–are engaged in abstract, complicated feedback loops and flows. That’s not new. I think what is interesting about this concept is that it bridges traditional electronic music user experience concepts with more intricate flows. I’ve taken a “step” paradigm and designed it to fit into a variety of scenarios.
I think what is interesting about this concept is that it bridges traditional electronic music user experience concepts with more intricate flows.
I can’t say the wheel has been reinvented here but I think a new type of wheel is being introduced for those who need it. This modular step approach can get rather complicated.
The Modular Step Object Flowchart
This is a work in progress and outlines some of the key factors of my step object/patch. There are some details to the patch that I am ignoring (they are not critical to the over all purpose) but this flowchart outlines a few of those features. This flowchart however does not offer an example of an elaborate sequence. I have another flowchart to explain that.
Two nearly identical loops with (likely) very different results
Loop A slightly represents a simple loop. A kick is followed by a snare then hihats. Then it almost repeats. If you look at the second to last hihat in Loop A, that hihat triggers two things. It triggers two hihats. Those two hihats then go on to follow their own sequence. One of the hihats loops back to a kick. The other eventually stops after a few steps. Additionally you can see durations between triggers designated. The only surprising duration in Loop A is a 16th note in the middle. You can almost imagine how this might sound. Think for a moment how that rhythm may go.
Now let’s look at Loop B. At first glance it’s pretty similar but look at the durations. We have 8ths, 16ths, and 200ms. That alone really complicates the rhythm and moves it outside typical time structures. Look at the second to last hihat as well. What’s different? It loops back into the main loop! How do you think this rhythm sounds? I have no idea. In fact during development of all this I constantly found myself in reboot-worthy feedback loops. That is one problem I still need to address. If you can avoid though, you will find yourself creating very different types of rhythmic structures.
Early stages of development
I skipped additional details regarding this development. For example I’m building in a signal gate into each step object. So you can sequence samples and sequence gates upon a live signal. Although the audio I provide may not shed too much light on the potential, I will continue going down this rabbit hole to see what musical qualities can be achieved this way. I think it looks promising.