Drum Sequencer - Randomizing Repeats & Probability?

[Melody303]

Can it be done? If so, how?
If not, consider this a feature request.

[challism]

This is the best I can think of, right off hand. Throw it in a Combi and route the Pattern Select to one of the Rotor Knobs. Then hook up Pulsar's random LFO to the Rotor Knob. Make different variations of each hit type that you want (different probability values and different repeats) in each pattern.

For even more variation and randomness, you can stack a couple of these Drum Sequencers on top of each other to give you 16 different patterns to chose from (route the Drum Sequencer's On button to a Rotor Knob and hook up Pulsar's 2nd LFO to another Rotor Knob. Do the same thing on both Drum Sequencers, but program it so when one is On, the other is turned Off).

You could program much randomness like this by using different destination/targets for the Rotor Knobs. I think Key Number or Step Reset would be a pretty good target to randomize, as well. I'll bet there is a way to stack more of these devices than the two in a Combinator and have them turn On/Off randomly, but I haven't put that much thought into this. There is probably a way to do it using Lectric Panda's Tap Player and Robotic Bean's free RE Select CV Switch in conjunction with Pulsar's Random LFO.

Also worth noting is the Speed section of the Drum Sequencer (the thing at the end of each lane on the right side). For the Direction setting, you could pick Random, this will add a lot of randomness to your beats.

Anyway.... a couple of Combi files attached. They are a little messy, put together quickly, but they should give you an idea of what I'm talking about.

Randrum.zip

(17.57 KiB) Downloaded 31 times

[EpiGenetik]

Can it be done? If so, how?
If not, consider this a feature request.

EDIT: Just realised I read this post wrong, sorry

[EpiGenetik]

Having a think about this, both can be achieved with additional Player devices and a random LFO, although one of the required Players is not released yet, and will not be for another couple of weeks, maybe sooner but unlikely.

[rgdaniel]

Interesting thing about Drum Sequencer and randomness: If you open a new file, drag in an instrument, then drag Drum Sequencer onto it as normal, then add a second Drum Sequencer onto it (or even a second instrument in another channel), then set the dropdowns for both to "Random", then click the dice for the whole patch, for each Drum Sequencer, you will get the SAME pattern in BOTH Drum Sequencers. Click them both again, a new "random" pattern, the SAME in both. So, not so much actually random as a collection of curated random-seeming but probably thoughtfully designed patterns, presented in a fixed order.

[EpiGenetik]

Interesting thing about Drum Sequencer and randomness: If you open a new file, drag in an instrument, then drag Drum Sequencer onto it as normal, then add a second Drum Sequencer onto it (or even a second instrument in another channel), then set the dropdowns for both to "Random", then click the dice for the whole patch, for each Drum Sequencer, you will get the SAME pattern in BOTH Drum Sequencers. Click them both again, a new "random" pattern, the SAME in both. So, not so much actually random as a collection of curated random-seeming but probably thoughtfully designed patterns, presented in a fixed order.

Seems plausible that some sort of Euclidean function would be in play in order to obtain highly random but musically/rhythmically relevant results.

[buddard]

Interesting thing about Drum Sequencer and randomness: If you open a new file, drag in an instrument, then drag Drum Sequencer onto it as normal, then add a second Drum Sequencer onto it (or even a second instrument in another channel), then set the dropdowns for both to "Random", then click the dice for the whole patch, for each Drum Sequencer, you will get the SAME pattern in BOTH Drum Sequencers. Click them both again, a new "random" pattern, the SAME in both. So, not so much actually random as a collection of curated random-seeming but probably thoughtfully designed patterns, presented in a fixed order.

Seems plausible that some sort of Euclidean function would be in play in order to obtain highly random but musically/rhythmically relevant results.

Nope, those rhythms are not Euclidean. The most likely explanation is that the random number generator(s?) in Drum Sequencer is/are seeded with a constant value, instead of using a pointer address or something to guarantee a unique seed in each instance. I can't tell if it was done on purpose, though.

[rgdaniel]

It seems counter-intuitive that clicking "random" should result in the same exact pattern every time. To get a "random" pattern you haven't seen before, you have to click it more times than you ever have in the past.

[EpiGenetik]

Seems plausible that some sort of Euclidean function would be in play in order to obtain highly random but musically/rhythmically relevant results.

Nope, those rhythms are not Euclidean. The most likely explanation is that the random number generator(s?) in Drum Sequencer is/are seeded with a constant value, instead of using a pointer address or something to guarantee a unique seed in each instance. I can't tell if it was done on purpose, though.

I'll take your word for it
Thanks

[EpiGenetik]

It seems counter-intuitive that clicking "random" should result in the same exact pattern every time. To get a "random" pattern you haven't seen before, you have to click it more times than you ever have in the past.

It actually changes a bit more intuitive if you click the main random, then a channel random then the main random again, that gives different results to the main random being called twice, so it's possibly something to do with the previous call and performing a function on that.

I would have to guess that this has been done intentionally for performance reasons. It wouldn't make sense to have a more exotic way to do it than a true random function only for it to be slower in the final product, and more difficult to code.

[ScuzzyEye]

I would have to guess that this has been done intentionally for performance reasons. It wouldn't make sense to have a more exotic way to do it than a true random function only for it to be slower in the final product, and more difficult to code.

Software can not produce truly random numbers, ever. The best you can do is retrieve a seed value from an unpredictable hardware source, and then "stir" it with some math to try to make it very different from the starting number. But using the same starting seed will always produce the same sequence of pseudo random values.

Because REs can't directly access hardware, the number of unpredictable sources is very limited.

[selig]

Speaking only for myself and for generative patterns, I don’t necessarily want a pure random signal that’s different every time I hit play, at least not for my song productions (maybe for live performance?).

This leads me to suggest allowing the choice of a preset range of seeds (as many other devices already do), and adding an external CV to further stir the pot if you want to make things even more random.

I’m not sure what each device does to generate it’s random string - do they seed the generator when you load the song or device, or when you start playback from bar 1, or each time you start playback from any bar? There are lots of options even with one preset seed value.

For example, with a CV input for seed, and a free run LFO such as Pulsar feeding that input, you could indeed get a fairly pure random result if needed - or alternatively get a more predictable result if needed. Better to have the choice IMO!


Sent from some crappy device using Tapatalk

[buddard]

I would have to guess that this has been done intentionally for performance reasons. It wouldn't make sense to have a more exotic way to do it than a true random function only for it to be slower in the final product, and more difficult to code.

Software can not produce truly random numbers, ever. The best you can do is retrieve a seed value from an unpredictable hardware source, and then "stir" it with some math to try to make it very different from the starting number. But using the same starting seed will always produce the same sequence of pseudo random values.

Because REs can't directly access hardware, the number of unpredictable sources is very limited.

That's why I suggested using a pointer address, since it's fairly unpredictable and at least will be unique for each instance!

[EpiGenetik]

Software can not produce truly random numbers, ever. The best you can do is retrieve a seed value from an unpredictable hardware source, and then "stir" it with some math to try to make it very different from the starting number. But using the same starting seed will always produce the same sequence of pseudo random values.

Because REs can't directly access hardware, the number of unpredictable sources is very limited.

That's why I suggested using a pointer address, since it's fairly unpredictable and at least will be unique for each instance!

Cool

If you guys don't mind - how does the C++ "rand()% x" function really work then?

I like the idea of using the pointer address, I hadn't grasped that this was the intention the first time you mentioned it. Although not truly random (I get that it's always going to be an algorithm), what about just bit shifting the system time until it gets into range?

[EpiGenetik]

For example, with a CV input for seed, and a free run LFO such as Pulsar feeding that input, you could indeed get a fairly pure random result if needed - or alternatively get a more predictable result if needed. Better to have the choice IMO!


Sent from some crappy device using Tapatalk

Another way to do it would be to have two free running LFO's with different shapes and freq's that sit inside the device but don't get exposed to the user. The seed range is then between the two amplitude points at any given time.

[selig]

For example, with a CV input for seed, and a free run LFO such as Pulsar feeding that input, you could indeed get a fairly pure random result if needed - or alternatively get a more predictable result if needed. Better to have the choice IMO!


Sent from some crappy device using Tapatalk

Another way to do it would be to have two free running LFO's with different shapes and freq's that sit inside the device but don't get exposed to the user. The seed range is then between the two amplitude points at any given time.

You don't need two LFOs - one is just as complex in this example because the two LFOs will always start at the same point when you load the device - thus they will always produce exactly the same value at any point in time, just as a single LFO will.

[ScuzzyEye]

If you guys don't mind - how does the C++ "rand()% x" function really work then?

I like the idea of using the pointer address, I hadn't grasped that this was the intention the first time you mentioned it. Although not truly random (I get that it's always going to be an algorithm), what about just bit shifting the system time until it gets into range?

First you call srand() with an unsigned int as a seed. There now multiple PRNG algorithms available in the <random> header. But they all are basically a sequence generator that in order to be secure needs a good seed value that no one else knows. But for REs finding the address of memory allocated to you is good enough. Just don't put your banking details into the next hot synth.

time() is a system call, that hits hardware.

[EpiGenetik]

Another way to do it would be to have two free running LFO's with different shapes and freq's that sit inside the device but don't get exposed to the user. The seed range is then between the two amplitude points at any given time.

You don't need two LFOs - one is just as complex in this example because the two LFOs will always start at the same point when you load the device - thus they will always produce exactly the same value at any point in time, just as a single LFO will.

Gotcha I hadn't considered it from that perspective. Rest assured it would have occurred to me within a month or so of starting any project that was using it

[selig]

Another "clue" there is no true random values in software comes in the new Complex-1 noise module, which has a sync function. Noise is basically a random signal, so what is "sync"?
The only way the noise module would be able to use a sync function was if there is some sort of pattern. And indeed there is, as there is with all digital noise.

[EpiGenetik]

If you guys don't mind - how does the C++ "rand()% x" function really work then?

I like the idea of using the pointer address, I hadn't grasped that this was the intention the first time you mentioned it. Although not truly random (I get that it's always going to be an algorithm), what about just bit shifting the system time until it gets into range?

First you call srand() with an unsigned int as a seed. There now multiple PRNG algorithms available in the <random> header. But they all are basically a sequence generator that in order to be secure needs a good seed value that no one else knows. But for REs finding the address of memory allocated to you is good enough. Just don't put your banking details into the next hot synth.

time() is a system call, that hits hardware.

Awesome, thanks For the record I only give bank details to foreign princes who're needing to get their money out of the country quickly; I always feel sorry for them - maybe I'm too compassionate

Cheers
B

[EpiGenetik]

Another "clue" there is no true random values in software comes in the new Complex-1 noise module, which has a sync function. Noise is basically a random signal, so what is "sync"?
The only way the noise module would be able to use a sync function was if there is some sort of pattern. And indeed there is, as there is with all digital noise.

That's pretty cool info, although it's waaaay into the future for me before I consider anything of this nature. Today has been highly informative, though

Many thanks (yet again sir )

[Melody303]

The tangents you folks went on are definitely interesting, and I'm glad to have learned new things with your help, but I kinda feel we all missed out on the core of my question here.
The random button on Drum Sequencer ignores the probability & repeat lanes entirely, and I wish it wouldn't. I also wonder why they skipped that functionality. Workarounds that may be created on the user side with combinators and the like may be useful, but are kind of an antithesis to the usual idea I have when clicking a random button.

[selig]

The tangents you folks went on are definitely interesting, and I'm glad to have learned new things with your help, but I kinda feel we all missed out on the core of my question here.
The random button on Drum Sequencer ignores the probability & repeat lanes entirely, and I wish it wouldn't. I also wonder why they skipped that functionality. Workarounds that may be created on the user side with combinators and the like may be useful, but are kind of an antithesis to the usual idea I have when clicking a random button.

I assumed your comment was now considered a feature suggestion, as you requested, and so off we went on a new tangent (maybe needed a new thread?).

However, the idea of random probabilities (random randomness) IS intriguing…


Sent from some crappy device using Tapatalk

[Melody303]

The tangents you folks went on are definitely interesting, and I'm glad to have learned new things with your help, but I kinda feel we all missed out on the core of my question here.
The random button on Drum Sequencer ignores the probability & repeat lanes entirely, and I wish it wouldn't. I also wonder why they skipped that functionality. Workarounds that may be created on the user side with combinators and the like may be useful, but are kind of an antithesis to the usual idea I have when clicking a random button.

I assumed your comment was now considered a feature suggestion, as you requested, and so off we went on a new tangent (maybe needed a new thread?).

However, the idea of random probabilities (random randomness) IS intriguing…


Sent from some crappy device using Tapatalk

I just didn't want to leave the impression that the original question/request is resolved. Tangents are fine in addition.
Here's another tangent: I'd really love a pattern sequencer where I can set the probability that a particular step will be tied/accented/ratcheted/octave-shifted (and determine the range of octaves too). I recall requesting that feature once from one of the Developers behind some of the current sequencer rack extensions, but I guess it was either too difficult to implement or they didn't like the idea enough to justify the effort or something. :p

[buddard]

I'd really love a pattern sequencer where I can set the probability that a particular step will be tied/accented/ratcheted/octave-shifted (and determine the range of octaves too). I recall requesting that feature once from one of the Developers behind some of the current sequencer rack extensions, but I guess it was either too difficult to implement or they didn't like the idea enough to justify the effort or something. :p

You can do random Ties, Mutes, Octave shifts and "Accents" (i e velocity boost) with two or more instances of Step 2.0!

You let the main Step instance be modulated by the other instances, which use trigger conditions (probability or recurrence) to decide whether to modulate that particular step. Connect the gates/CV/velocity outs of the "modulators" to suitable CV inputs on the main instance and you're good to go!

I can go into more details if you want, but I don't know if you want to start a new thread for that?