Patch randomizer?

[k brown]

Anyone ever come up with a patch randomizer for Flowstone?

I have no idea how it works but the one in 'Oatmeal' coughs up usable results a surprising percentage of the time.

https://testblog.music-society.de/oatme ... i/musicus/

[R&R]

This is an interesting topic...
Hoping more ppl have looked into this

I know in theory how I would construct a patch randomizer. It would be based of "range template" values.

1.
Every preset module in the synth will have to have a reciever module to set the parameter value and it's corresponding knob, naturally.
Probably just a "last switch" or a more advanced module with an "arming" mechanism (which I use in my newbie synth for resetting all modulation knobs in the entire synth). Basically a trigger switch with some surrounding logic, to allow resetting values.

2.
I would categorize some value ranges for all "critical" parameters that can and will make the synth go silent if those values are to extreme. All these value ranges will be put into arrays in a top of hierachy module then selectively distributed to all preset modules.

3.
Ruby in the top module.
The first step of the randomizer Ruby code would be to randomly select from these "critical" categories, of which value ranges will be chosen from.
Example categories on amp env's:
Stabs: will have short attacks, medium release values (0 -- 0.1 and 0.1 -- 0.2) etc.
Strings: will have slow attacks, slow release (0.1 -- 0.4 and 0.25 -- 0.4) etc.
Plucks: ...
Leads: ...
Drums: ...
And so on...

After critical values are selected from and set, all non critical parameter values (those of any interest) can maybe be entirely random.
Alot of values would not need to be randomized at all.


I intended for a patch randomizer in my newbie synth, but ended up struggling with other stuff. I just know too little about synthesis and math anyways regarding the actual sound generation etc.
For no particular reason other than "I could"... i'm also at 3000+ parameters (and counting! not finished) in my synth... so... the the patch randomizer idea is on hold It will only be possible in a finished final FS4 version for my particular synth I think, due to memory handling.

[Spogg]

The closest I’ve come to that (which isn’t close at all really) is to make use of the Random trigger on the knob framework I use. That would be for very specific functions, such as partial levels in an additive oscillator.

You would need to have such a trigger input on all controls that you’d want to randomise (selectors etc). The randomisation would need to work on the 0-1 side, before the preset module, so a new randomised value could be saved before being converted to the desired range. My guess is the range of random values possible, inside the 0-1 limit, would have to be carefully biased to exclude extremes for some parameters. For example, if you randomised the Attack knob on an ADSR you could end up with mostly long times, most of which would be useless in practice. There would need to be some sort of rational mapper, like a log function, to compress the random values into mostly low ones for this case. The opposite kind of mapper would be needed for the Release time.

The upshot is that each control with a Randomise trigger would need to have its “range bias” adjusted according to its function in the synth. This range bias might even need to changed depending on what other controls get set to, which adds to the complexity of design but would make it “smarter”. For example, if a Sustain level was set randomly to a low level you might need a faster Decay and so on.

When I make a new synth I transplant a previously used Preset Manager and I flick through the old presets just in case I get something interesting. I know it’s not the same thing, but on only one occasion did I get one useful sound, and even that needed tweaking.

I gather that FL Studio can randomise the parameters for any synth (in the DAW) but from what I read the results are very rarely any good. In my view, preset creation is an artistic endeavour and needs a human in the loop to judge the aesthetics.

[R&R]

Spogg's idea with "range bias" is most definately the professional approach, rather than static ranges i'm considering...

When I make a new synth I transplant a previously used Preset Manager and I flick through the old presets just in case I get something interesting. I know it’s not the same thing, but on only one occasion did I get one useful sound, and even that needed tweaking.

This can be illustrated in simple micro scale with my newbie synth. By simply flicking through the Osc modules for any preset. Since each Osc Module is a simple individual synth, with different mappings on it's 3 knobs.
Some Osc Modules work for some presets, some does not... some go completely silent (due to current knob mapping).

[tulamide]

I won't go into details of how to trigger a value for an aspect of a synth - that's up to you.

But I want to make some comments about randomizing. There are two types of randomization

1) Pure randomness
This is just like throwing dice. No context awareness, it just spits out a number within a range and that's it. You can't get very far with it in terms of presets, because, for example, without music theory in mind, selecting two frequencies for two oscillators alone will rarely result in something that sounds attractive.

2) Procedural generation
We're not talking generative music, this is something completely different. Procedural generation, at its core, is a randomizer. But this time it is context aware. There's a game I'm playing right now, No Man's Sky. It simulates a universe. There are around 18 billion planets to explore. You can reach ech one. If you land on them, they all look different, they all have different atmospheres, different minerals, different surfaces, diffent flora and different fauna. Everything, except for the player in this game is created using procedural generation.

But why does it work? Well, it all starts with a seeded random generator. The seed is important, because everytime you set the same seed, you get the same series of random numbers. This fact is how programmers make sure, that everyone will see the same planet at the same spot.

Now from this seeded random, you use a series of numbers as seeds for other seeded random number generators. In our case, it would be one for oscillator 1, one for oscillator 2, one for the filter, etc.

Now you create conditions for the random numbers. You tell them, how the have to be interpreted. Note: you don't program the interpretation, you just set a book of rules. For example, you could limit the detuning of 2 oscillators to a maximum of 10 hundreds. Then you throw the dice and the number applied will always be within these limits.

You do that for every aspect of the synth that you think is important. And then comes the fun part!

By just entering a new seed for the very first random number generator, the whole tree works his way and you end up with a completely new, usable and good sounding preset. Even the simplest seeded random generators already use a seed value in the range of 4 billion. Lots of presets to go through.

Again:
1 seeded random generator is the root of all
x seeded random generators get their seed from the root generator
the parts of your synth get numbers from their respective random generators
these numbers are set into context

Result: a grin on your face, everytime you hit the randomize button, which feeds the root with a new seed!

[R&R]

Now you create conditions for the random numbers. You tell them, how the have to be interpreted. Note: you don't program the interpretation, you just set a book of rules. For example, you could limit the detuning of 2 oscillators to a maximum of 10 hundreds. Then you throw the dice and the number applied will always be within these limits.

You're giving me nightmares... and I haven't even starting looking at this
So by context you are refering to similar thing as Spogg with "range bias"?

Using seeds.. the order in my scenario would be someting like?

Root seed --> distributed to separate parts of synth generating 2nd, 3rd, 4th seeds and so on --> combine with context limits (for example categories: Stabs, Lead, Pad etc if wanted, maybe based on root seed for selection) --> then scales output dependening on incoming seed "and" incoming context (in other words a "range bias")

The context would never be known to the end user but I myself could see under the hood in what context the patch was generated.

[Spogg]

Yes, I discussed this with tulamide some time ago and implemented it in some synth or other.

The advantage of using “cascaded seeds” is that the base seed will always lead to the same first and subsequent “random” number set being generated, for a given initial base seed. In the green random number prim if you don’t set an input seed it uses the time (not sure if it’s the run time or PC time) and that means the random numbers generated will be different every time it’s triggered.

Having said that, to generate random presets I wouldn’t want the exact same sequence of “random” parameters created every time I clicked on the Create button, after first loading. Otherwise I’d have to run through loads I’d already tried and rejected. For this application I would want to have the base seed set randomly from time, and the cascaded seeds set from that. So after loading I would click on the Create button and always get a new sequence of random values.

I hope I’m right and that makes sense!

[tulamide]

Yes, I discussed this with tulamide some time ago and implemented it in some synth or other.

The advantage of using “cascaded seeds” is that the base seed will always lead to the same first and subsequent “random” number set being generated, for a given initial base seed. In the green random number prim if you don’t set an input seed it uses the time (not sure if it’s the run time or PC time) and that means the random numbers generated will be different every time it’s triggered.

Having said that, to generate random presets I wouldn’t want the exact same sequence of “random” parameters created every time I clicked on the Create button, after first loading. Otherwise I’d have to run through loads I’d already tried and rejected. For this application I would want to have the base seed set randomly from time, and the cascaded seeds set from that. So after loading I would click on the Create button and always get a new sequence of random values.

I hope I’m right and that makes sense!

If you want to fully automate the process, then it does make some sense, of course. However, the advantage of "repeatability" by manually entering a seed for the root generator is, that you only need to know (and share) this initial seed. By only saving this seed, you can always recreate the preset, and by sharing the seed, any other user can enter the seed on his instance of the plugin and get the very same preset!

I only know of one plugin that uses procedural generation (no need to invent a new word for it, like cascaded seeds) in its full potential. There are quite some that you can randomize, but only one that works exactly as I described. It's called "Autogun", and even the display is procedurally generated. I link to a video, look at the display, the names and descriptions are all made up. The only real thing is the seed. If you hover over a certain button, it will show you the seed (which they call very suitable "preset number"). Whenever you enter this number again, you will hear the exact same sound. There's even a seeded randomizer for the forward/backward buttons (it will generate a new "preset number").

Autogun is at least 10 years old, but is still part of FL Studio (and therfore gets updated to run on current systems). It is also available as a free download, even as 64-bit. Install it to see it working. You will see that all sounds are really harmonic and pleasing. If all of them are usable in your music, I don't know. But every single sound beats the standard random shit from other synths by miles.

This is not just due to the seeded random! They also went the extra mile for the context awareness. That's what makes it so useful.

Autogun is based on Ogun, another (commercial) FL Studio synth, they just stripped the GUI, to control it just by entering seeds. In fact, if you find a seed that sounds awesome to you, you can enter that seed in Ogun, where you have full access to all the elements that make up this sound. Needless to say that they both sound identical, of course.

video: https://youtu.be/DGuaD4xSWzo
download: https://www.audiopluginsforfree.com/autogun/

[Spogg]

Interesting demo tulamide, many thanks. I downloaded it and was surprised at the sonic variation obtained by generating “new” presets. I also looked into Ogun to see what kind of engine is under the hood. A very impressive additive system I must say.
The seed number consists of 2 component parts, each having a range of 0 to 32767. These 2 parts each control different aspects of the synth to give over a billion combinations. The really clever bit is the design must allow for every single value to be meaningful.

However, I’m not convinced that sharing a seed number is significantly easier than sharing a preset file, but it has at least a novelty and interest factor. Maybe the point is that Autogun is free and offered as a loss-leader for those who are impressed with the random presets and want to explore deeper. That’s a clever marketing idea and differs considerably from the common “player” plugins out there.

I must say I like R&R’s idea about having selectable contexts for the synth. You could say “I need a short stab” and get lots of randomised stabs to choose from. That kind of system I think would be more useful than purely random presets. But if you have Ogun and you found something suitable in Autogun you could transfer the seed and tweak it there.

All very interesting stuff!

[RJHollins]

Great insights Tulamide ... thanks for sharing/explaining