60 – Generative Ideas (pt. 1)

Enough about Kong already. Let’s try something a little more interesting. Let’s start with a concept: Generative Music. And let’s see what we can do with it in a Reason environment. For starters, let’s see how we can extend the Thor step sequencer a little bit. Well, okay, let’s make it go absolutely NUTS!

Enough about Kong already. Let’s try something a little more interesting. Let’s start with a concept: Generative Music. And let’s see what we can do with it in a Reason environment. For starters, let’s see how we can extend the Thor step sequencer a little bit. Well, okay, let’s make it go absolutely NUTS!

You can download the project files here: thor-extended-step-sequencer-ideas. This contains a lot of different ideas from EditEd4TV, Sterioevo, and myself. All of us had a hand in working out my little idea. And I just want you guys to know that you’re the best! Without your ideas, I never would have been able to make this thing work. So anyway, there are 5 Reason (.rns) files and 5 Combinator (.cmb) files. Read below to see what kind of mayhem you’ll find inside. Note: to “Run” any of the patches in the file, just press Button 1 on the Combinator. This will start the sequence/system going. To stop the sequence/system, press Button 1 again. There’s a “Sound Source” setup in each Combinator to test the sound. There’s also 2 DDL-1 devices in each Combinator which is used to visually see the CV Note / Gate values.

Defining Generative Music

There’s many definitions for what Generative music is. Put simply, it can be defined as music that meets the following requirements:

  1. It must be created by a “system,” which is to say that it requires an algorithm to generate the “structure” (such as algorithms, mathematical equations, number sequences, etc). There must be logic behind it, whether this logic is set up by the composer or the listener.
  2. It is ever-different and changing over time; non-repeatable and “emergent,” as wind chimes are.

Brian Eno provided a really great Generative Music lecture at In Motion Magazine. I would highly recommend giving it some time if you also enjoy this sort of thing.

Starting off with a Problem

First I’ll give you the problem: How do we create a step sequencer pattern that is 128 steps long and randomly selects values between 0 – 127 in real-time? Can this be done in Reason using Thor’s Step Sequencer?

When I was building my “Key Flux FX Processor” behemoth, I wanted a way to randomly select the MIDI note values from 0-127 (C-2 to G8). Using the Matrix was a workaround, however, you have to jump through some serious hoops in order to get it to use note values outside the typical 5-octave range of the device. And even then, the randomizations aren’t really random. You’re selecting from a set of pre-defined patterns that never change. You can click the “Randomize” function in the Matrix, but once the notes are assigned to the Matrix, they’re permanent. Thor, on the other hand, provided a way to assign a “Random” run mode that is random during “Live play” — and this is the crux of the biscuit. This is what can open you up to one area of Reason which is truly “Generative.” It’s like the Holy Grail of building a “Generative System” in Reason. However, like the Holy Grail, it’s elusive. You’ll soon see why.

As for the “Key Flux FX Processor” patch, I settled on the Matrix because I couldn’t solve a simple problem at the time: How to Merge the Note values coming out of Thor, so that you could create patterns longer than 16 steps (the total length of a Thor Step Sequencer). The idea was to set up a series of Thor Sequencers and increase each step by 1, and then randomize the whole lot, so that you can get something truly random going from 1 – 127 MIDI value. Of course, I soon realized that you can’t get something truly random like that with the Thor Step Sequencer because the way it would work is it would go from Thor 1 (randomized between 1-16 MIDI value), then to Thor 2 (randomized between 17-32 MIDI value) and so on. Not “truly” random, but still better than nothing.

However, there are two main issues with Thor’s Step Sequencer:

  1. The Thor step sequencer leaves the gate open from one step to the next and never fully returns to zero between steps. This means that merging the note/gate values sums the previous note value with the next note value. And using the “End Trig” CV to trigger the “Start Trig” of the next Thor sequencer sums the two values together. This could be seen as a bug or a feature, depending on what it is you want to do with the CV values given off by Thor. Sometimes keeping the gate and CV open is a good thing. However, not in this case.
  2. The second issue is that the Note CV values from Thor’s Step Sequencer are bipolar (-64 to +63). Not a really big deal if you understand that. But something that will leave you scratching your head if you’re trying to visualize your CV with a DDL-1 device.

These two seemingly harmless facts about the Thor Step Sequencer ended up in hours upon hours of frustration when I was trying to do something as simple as connect multiple Thors together and have them generate the exact note/gate values to apply to a single sound device.

To recap, here are the three limitations/hurdles we need to overcome in order to tackle the issue:

  1. We need to use Thor, because it’s the only device that can generate a real-time “Randomized” sequence. Using the Matrix is a non-starter because the notes cannot be changed or randomized in real-time (not to mention it uses only a 5-octave range out of the box).
  2. We need to be able to create a Step Sequencer that is 128-steps long, so that each MIDI value has a chance to be selected. Since Thor is 16 Steps long, we need 8 Thors to generate a step sequence from one end of the MIDI spectrum to the other.
  3. We need to build a method to Randomly “play” the entire sequence so that only one MIDI value is selected and played at any one time, and this value can freely jump from any value between 0-127 to any other value between 0-127.

The solution(s)

Hurdle #1:

Tackling the first issue is simple. We use Thor and forget about the Matrix. Check!

Hurdle #2:

The second issue was beautifully tackled by both Sterioevo and EditEd4TV, with two different solutions:

First, Steve (Sterioevo) came up with the brilliant idea of using the Global Sustain on Thor to shut the gate off between notes. This was perfect. You simply connect all your Thors together, send the CV from the Note / Gate outputs through Rotaries in Thor and then use the Global Envelope Sustain to scale the note and gate CV in the Modulation Bus Routing Section (MBRS) in the Thors. This allows the Global Envelope Sustain to “shut off” the gate between the steps, and you can freely merge as many note CV and gate CVs as you like. In essence, you can string as many Thors together as you like and merge them properly. See the project files for his patch.

Next, EditEd4TV provided a more compact solution. His solution sends both the note / gate CV outputs into the CV1 and 2 CV inputs on the same Thor, and then outputs them to CV 1 & 2 outputs to the Spider Note / Gate CV mergers. This step is done to convert the note values from bipolar to unipolar (that so-called benign problem #2 was solved). Then in the MBRS, he programmed the following:

CV in1 : 100 > CV out1 : 100 > Last Gate

CV in2 : 100 > CV out2 : 100 > Last Gate

The Modulation Bus Routing Section (MBRS) of Thor showing the assignments and Steps
The back of the first Thor device showing the CV routings to set up the first set of 16 steps in the 128-step Forward-running sequencer where the Thors are strung together and play end to end.
The back of the first Thor device showing the CV routings to set up the first set of 16 steps in the 128-step Forward-running sequencer where the Thors are strung together and play end to end.

Brilliant. The “Last Key > Gate” (ie: Last Gate) is what shuts off the gate after each step, and allows you to merge the note / gate CV successfully. Now you are free to string up as many Thors as you like, without a hassle. See EditEd4TV’s patch which is also included in the project files. Hurdle #2 has been jumped and solved. Check!

Note: Due to EditEd4TV’s solution being easier to build, and more self-contained, I’m going to build on his patch to solve hurdle #3. Not that Sterioevo’s solution isn’t any less brilliant or usable by the way.

Hurdle #3:

Solving the third problem hit me in the head like a ton of bricks. What was needed was a set of recursive on/off triggers. One Thor needs to be set up to control the on/off state for every two Thor sequences beneath it. Once this is set up, you can then work backwards, building a pyramid of Thor controllers to turn things on and off. Visually, it looks something like this:

Master Controller > > Controller A > > Controller A1 > > Sequence 1 (Steps 1-16)
> Sequence 2 (Steps 17-32)
> Controller A2 > > Sequence 3 (Steps 33-48)
> Sequence 4 (Steps 49-64)
> Controller B > > Controller B1 > > Sequence 5 (Steps 65-80)
> Sequence 6 (Steps 81-96)
> Controller B2 > > Sequence 7 (Steps 97-112)
> Sequence 8 (Steps 113-127)

 

So I started to work from the bottom of the pyramid upward. It worked out well for Controller A1 controlling two sequences underneath. To see how this was set up, you can look at the “Thor 32-step random sequencer” rns or Combinator file in the Project files at the top of this article. Incidentally, it uses the “double-scaling” lines in the Modulation Bus Routing Section of the Pattern Sequence Thors (so that’s a little nod to Hydlide’s next tutorial all about the MBRS — See his latest on the Mod Matrix Filters and Amps — a great read).

The idea is to create another Thor (Controller A1 in the diagram above) which switches Sequence Thor 1 and Sequence Thor 2 on or off. I used the 2 Curves inside Controller A1, and set them so that they are both 16 steps which are set to “Random” mode, as follows:

Curve 1: Step 1 – 0; Step 2 – 100; Step 4 – 0; Step 5 – 100, and so on. . .

Curve 2: Step 1 – 100; Step 2 – 0; Step 4 – 100; Step 5 – 0, and so on. . .

Then I sent Curve 1 into CV 3 input on the first Thor Sequence, and Curve 2 into CV3 on the second Thor Sequence. In these Thor sequencers (1 and 2), set the following lines into the last 2 lines on the MBRS (the ones with 2 scalers):

The MBRS for the first Thor Step Sequencer
The MBRS for the first Thor Step Sequencer
The step sequencer on the "Controller A1" Thor, which uses both curves set in opposition to each other to control the 2 Thor step sequencers underneath it.
The step sequencer on the "Controller A1" Thor, which uses both curves set in opposition to each other to control the 2 Thor step sequencers underneath it.

So this creates the “Thor 32-step Random Sequencer” patch found in the project files at the top of this article. If you duplicate this same setup for the next two sequences (Sequence 3 & 4), controlled by “Controller A2,” you end up with one level tackled. Our next step is to figure out how to extend this to 64 steps. So let’s try doing that now.

You would think that using this same idea one level higher would yield the same results. What you find out instead is that this trick can only be used once. As soon as you use the double Curve trick one level higher (“Controller A”) to control the level below (“Controller A1” and “Controller A2”), you end up with completely messed up CV values coming out of the system. Trust me: I tried. So what we need to do is find a new trick to select between the two “A1” and “A2” Controllers.

Enter the Mod Bus switcheroo! This time, we need to separate the merged note/gate outputs from Thor Sequence 1 & 2 and Thor Sequence 3 & 4 so that they both are on separate Spider Merger/Splitters. Then send the merged outputs from all 4 of those Spiders into the “Controller A” CV inputs 1-4. Be sure to keep track of what is going where, as shown below:

Note Merge 1 & 2 > into CV 1 input

Note Merge 3 & 4 > into CV 2 input

Gate Merge 1 & 2 > into CV 3 input

Gate Merge 3 & 4 > into CV 4 input

The routings to split the 2 sets of Thor sequencers into their own Spiders, and send the merge outputs into the "Controller A" CV inputs. The CV 1 & 2 outputs are sent to the Combinator Rotaries.
The routings to split the 2 sets of Thor sequencers into their own Spiders, and send the merge outputs into the "Controller A" CV inputs. The CV 1 & 2 outputs are sent to the Combinator Rotaries.

Then you setup the Thor “Controller A” MBRS as follows:

CV In1 : 0 > CV Out1

CV In2 : 0 > CV Out1

CV In3 : 0 > CV Out2

CV In4 : 0 > CV Out2

While you’re there, set up the steps on the Thor “Controller A” the same way you did with “Controller A1” and “Controller A2”:

Curve 1: Step 1 – 0; Step 2 – 100; Step 4 – 0; Step 5 – 100, and so on. . .

Curve 2: Step 1 – 100; Step 2 – 0; Step 4 – 100; Step 5 – 0, and so on. . .

The MBRS and Step Sequencer of the Thor "Controller A"
The MBRS and Step Sequencer of the Thor "Controller A"

In the Combinator Modulation Routing section, select “Controller A” and enter the following:

Rotary 3 > Mod 1 Dest Amount : 0 / 100

Rotary 4 > Mod 2 Dest Amount : 0 / 100

Rotary 3 > Mod 3 Dest Amount : 0 / 100

Rotary 4 > Mod 4 Dest Amount : 0 / 100

The Combinator Modulation Routing for "Controller A"
The Combinator Modulation Routing for "Controller A"

On the back of the rack, send the CV Output 1 & 2 from the Thor “Controller A” into the Combinator’s Rotary 1 & 2, respectively. Note: in the setup shown above, these CV outputs are split with a Spider “Note/Gate” splitter so that I could send the signal to two additional rotaries to visualize the CV values in the two DDL-1 devices, but you don’t need to do this. This is so that I could test out the CV and make sure the values output are indeed random and working properly.

Turn up the CV trim knobs to 127, and on the front of the Combinator, turn the rotaries to zero (0). And there we have it. a 64-step random sequencer. Of course, you have to use 2 Rotary CV sources on the Combinator, but if you have version 5, you can set this up on the new CV inputs, without giving up any rotaries. Take a look at the “Thor 64-step Random Sequencer” patch included in the project files at the top of this tutorial to see it in action.

Finally, to gain access to the next level (Master Controller), I have to concede that I cheated a bit. I used a Thor and called it “Doubler” which essentially doubles the CV values of all the Thor Step sequencers. Then I used a curve value to send a series of random steps set to either a value of zero (0) or 100. This was sent into the final CV input on all the step sequencers, and the following was entered into the MBRS of each Thor Step Sequencer (Sequencers 1-4):

CV In4 : 99 > S. Transp (Step Sequencer > Transpose)

This has the effect of extending the range of the four Thor Sequences from 0-64 to 0-127. Of course there may be a limitation when it comes to changing other parameters of the step sequencers, like Gate Length and Gate Duration, because you essentially have 1 step which acts for 2 outputs. For example, the Gate Length for step value “1” will also double for value “66.” So this system is not exactly perfect. But it’s the best I could come up with at the moment. Perhaps someone smarter than I could come up with a better solution. If so, I’m all ears and would love to hear it. Check out the “Thor 128-step Random Sequencer” patch in the project files at the top of this tutorial and you can see the finished version.

So there you have it. This solves the third and final hurdle. Checkmate and your move!

Moving Forward

In the next part of this series, I’ll try to explore a little more about how you could potentially use this type of setup. For right now, just have a look and see if you can improve upon this or create a better way to create a fully functional 128-step random sequencer.

As for the “Generative Music” concept, I think this could have some interesting potential. For right now, I’ll just leave off with another interesting “Generative” site that I found online which takes mathematical number sequences and converts them into music. You can listen to thousands of sequences all based on these math sequences. I thought it was interesting. Check it out here if you have a minute: http://oeis.org/play.html. The site is a little cludgy, as you have to copy the database integer sequence number into the “Play” page, but once you do, you can hear that database record as a MIDI file and choose the instrument that plays the sequence.

And here’s another site which generates music (MIDI files) from paintings: http://www.synestesia.fi/ Now there’s something original.


In conclusion, you can indeed insert some “Generative” elements into your Reason projects. Hopefully you won’t have to spend hours upon hours figuring out how to do it like the three of us did, and instead spend hours and hours coming up with your own “Generative” systems a la Brian Eno. More to come on this later. . .

In the meantime, send me your best “Generative” music ideas and let’s see where this concept will take us in Reason and Record. Peace out!