Welcome to the new and improved Native Instruments online community. Join our active forum of 40,000+ members for discussions and much more.

# Random drum sequencer step trigger

Member Posts: 5 Sine

Hi everyone,

is it possible to randomly trigger the steps of a step sequencer with individual trigger probabilities?

So for example when random is hit, the first step will be triggered with a probability of 50%, the second step at 25%, the third step at 100%,...

How would I have to connect that?

Sry, just started using reaktor π

Thank you in advance.

• Member Posts: 826 Saw
edited March 15

Here you can use left of the row the βSβ to set randomly new steps. The zero on the right side delete all steps. It works with IC-Send to each step:

You can down load the ensemble here:

https://www.native-instruments.com/de/reaktor-community/reaktor-user-library/entry/show/10099/

In front is a button and a separator.

Myself use the range of 0, 0.25, 0.5, 0.75 and 1.0 for the velocity iof the sequencer.

• Member Posts: 6 Sine

Yes, it is possible using logic modules. This sequencer I built does just what you asked; feel free to explore the code.

https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/13711/

• Member Posts: 423 Saw

Are you asking about a specific sequencer, or just in general?

If its the latter, then pretty much anything that you can imagine sequencer wise is likely possible in Reaktor. If its the former, then please say which sequencer you are using. That matters - there are a LOT of sequencers in Reaktor (and synths and everything else too). And they all do it a bit different from each other.

• Member Posts: 5 Sine

Hi colB, thank you for your answer.

Here's where I wanna go in the end:

I wanna do a drum pattern generator that uses a kind of "intelligent random".

So, if a user wants to create a Deep-House Pattern, the plugin would treat each track with it's separate "intelligent random" genre based specifications.

Example:

Kick: would be triggered at every 1/4 note.

Hats: would be triggered at every 1/16th note, with random velocity

Clap: would be triggered at every second kick trigger

and so on...

So, the outcome would always be a good sounding beat pattern, and no 1/16th notes triggered kick messing things up for example.

For each track the user (or the genre preset itself) can define the intelligent random ranges for Velocity and Trigger probability (maybe also pitch and offset).

I'd also implement a groove/swing option.

With a tutorial I could build a simple step sequencer with toggle buttons in reaktor.

But now I am failing to do the rest π

Here's a sketch:

(the midi and sample load stuff would be nice, but I am more than happy when the intelligent random range definitions work)

So, if you or anyone else wanna help me, feel free to answer here or message me π

• Member Posts: 423 Saw

Generally, you would need a lane in your sequencer to have probability settings per step from 0 to 1, then for each step, you generate a random number per step, and if its value is less than or equal to the probability for that step, you send a trigger, otherwise you don't

so if probability is 1 then a random value between 0 and 1 is always going to be less than or equal to 1, and you always generate a trigger, whereas if probability is 0.25, then a random value between 0 and 1 is only going to be less than or equal to the probability about a quarter of the time... pretty simple really.

For fun, here's an ensemble using factory blocks that demonstrates the idea:

This works slightly differently due to the limitations of the available blocks. The velocity lane of the shift sequencer is used for probability setting per step. A sample and hold block generates random values per step, those are added together. The result is sent to a gates & trigs module. Now if the value is above the threshold we get a trigger, so with a low probability, we need a really high random value to get a trigger, whereas a high probability pretty much always gives a trigger. The gate driven VCA guarantees that the trigger/gate is always reset.

• Member Posts: 423 Saw
edited March 17

Here's a different version using multiplication (VCA) instead of addition. This means that 100% isn't possible!... so better to just use a comparator if RND <= PROB if you are rolling you own :)

(I remembered to do it as a rack this time, so 6k instead of 7Mb :))

try hitting the 'VEL' button on the shift sequencer, that will randomize the probabilities!

• Member Posts: 5 Sine

Hi colB,

thank you for your answer and examples. I am not sure if I got you right.

Should the Vel lane define the probability of each step? (Gate, Hold?).

When I set the Vel lane like in the first picture and hit the "gate" random button for example, it still seems to randomly trigger steps. Shouldn't it look more like in the second picture?

Sry, I guess I missed something.

• Member Posts: 423 Saw

For that patch to work, the gate needs to be on for all steps on the sequencer. The probability part is created by the combination of the velocity output of the sequencer and the other blocks in the patch. The gates & trigs block is where the actual probabilistic triggers are generated.

Like I said though if you are scratch building a sequencer, better to use the simple comparison approach.

Do you have a basic sequencer that you are working on? If you post that, then it might be easy to modify it for probability!

That might be the best way forward - build a simple sequencer, then modify

• Member Posts: 5 Sine

That's the ens so far π

π

• Member Posts: 423 Saw

I'll check it out tomorrow!

• Member Posts: 423 Saw
edited March 18

OK, basic idea would be to duplicate the row of velocity knobs (fix the first one so that its 0..1 instead of -1..1 ;))

Then send the gate (i called it trg) signal and the probability value through a new macro that looks like this:

This generates a random value between 0 and 1, then compares it with the probability, if its less than or equal it outputs 1 otherwise 0. You then multiply that with the actual gate, and the gate passes dependent on the probability.

I also noticed that your lamps are 1 off what they should be - not sure why you included that -1 in there?

There's a buch of other stuff to do, but this should get you some basic probability!

• Member Posts: 5 Sine

Got it to work! Thank you so much!

Is there a way to also randomize the velocity, but only values within the given range

(V Range - Min Max per step) are used?

• Member Posts: 423 Saw
edited March 19

Is there a way to also randomize the velocity, but only values within the given range

Manipulating stuff with Maths is much easier and better in core, but what you are asking is still pretty easy in Primary.

If you look to the pic in my last post, the Randomize module has two inputs, Rng and In.

What you get at the output is a random number between In-Rng and In+Rng (yes it's weird, but then it's Primary).

Tip: there are info hints for all the modules, and they are usually pretty good descriptions of what they do!

So anyway, with a min and max control...

'In' would need to get the halfway point between min and max, which would be: (max+min)*0.5

'Rng' would need to get half of the difference between them, which would be: (max-min)*0.5

IMO it might be easier just to have a single random amount setting for each velocity, then just send the velocity to 'In' and the random setting to Rng, then you get random fluctuations above and below the velocity setting by and amount specified by that single control.

Or if you do go with min and max, ditch the velocity knobs because they become redundant in that context!

...Or, have a velocity setting and a 'humanize' that uses the velocity setting as max, and humanise as a min for the min/max version... then you can still set the maximum precisely, but you still only need one extra control... I would also be playing with applying a curve to the probability so that more of the hits fall nearer to the 'correct' velocity and fewer are further away... this sort of thing is much better done in core where you don't get punished so much (in complexity and cpu) for doing a lot of basic arithmetic processing...