Randomize: right click context menu


(Latif) #1

On right click we have the option to randomize the settings of a module.
Ever since i tried it, i noticed that it randomizes nearly all settings that have parameters resulting in unwanted/undesired changes.
So i never used it again.
Wouldn’t it be a more creative and useful if that randomize would have some sort of standard, where as for sequencers it would only randomize cv & gate, fx modules all but dry/wet settings.
etc?
I know, of course this depends on preferences differently from user to user and developer to developer.
Just the way it is now, i find it rarely useful.
What is your thoughts about this?


(Nik Jewell) #2

I would certainly agree that controlled randomisation is vastly more useful than global randomisation. It could be achieved by adding tiny parameter locks next to controls but I don’t think that could be standardised or enforced. The facility could be there if devs wanted to use it though I guess.

I would have to think some more about more global standards based on module type but I’ve got a feeling that might prove too problematic. I guess you could have two randomisation options (global and per module type) maybe?


(Paul Piko) #3

The bordL sequencer lets you randomise the pitch, gates and slides/skips separately.


(Adi Quinn) #4

Agreed, i don’t use it because it defeats the purpose when after you hit randomization you then have to reset certain knobs by hand that you don’t want to be random. Could be neat to have check boxes of parameters within the context menu so you could select them on/off to control what’s being affected everytime you hit random.


(Andrew Belt) #5

The idea behind parameter randomization is this: Eurorack modules are black boxes with a parameter design space equal to an n-cube. Choosing a point in that space gives you the positions of all n parameters, which will produce a certain sound or behavior. A well-designed module (such as all of Mutable Instruments) is designed such that a there are no “dead zones” in this space, i.e. all neighborhoods are equally interesting. A difficulty with playing modular synths is that as you get used to using certain modules, you’ll often narrow yourself into smaller and smaller corners of this design space until you start thinking a module is becoming boring. To fix this, the randomization feature teleports you to a uniform unbiased point in this space, giving you a new starting point for rediscovering the module as if it’s brand new.

In practice, not all module designers give their parameter design space the treatment that Mutable Instruments does. For this reason, I should give Param a new bool randomizable field, which can be set to false if the Param is not to be changed with the randomize function. Thoughts on this proposal?

Another possible proposal (which depends on the above) is to allow this randomization to be toggled by the user in the new parameter context menu. However, I believe this is too much work for what it’s worth, and the work would not be “saved” across multiple launches of Rack, or even multiple instances of modules.

If a plugin developers wants to randomize internal state, they can override Module::onRandomize.


(Antonio Tuzzi) #6

SQUONK uses custom randomizations using contextual menu


(Leonardo Laguna Ruiz) #7

In many of the Vult modules the randomization affects a selected set of parameters. One example is in Noxious, the switch between Oscillator and LFO is not affected. I don’t recall all the places where I avoid randomization but I usually pick them while developing the module.


(Latif) #8

Yes, I use it Knock now you mention it!


(Jonathan Moore1) #9

One of my favorite iOS developers (Bram Bos) uses randomisation very effectively in many of his apps. I use it most often in Phasemaker, his 6 operator FM synth. I also use KQ Dixie on iOS as it loads any DX based sysex file. However, I get far more out of Phasemaker creatively because of the randomisation feature.

I’ve been experimenting with much the same technique in my early explorations with Vult Vessex (fast becoming my favourite VCO in VCV).

However I do think that randomisation needs to be well designed on a module be module basis. Not all modules lend themselves to randomisation in the same manner as the Mutable Instruments ones. This doesn’t make them bad modules, it’s simply a case that they were created to a different design strategy.


(fra) #10

It may be a bit off topic, but anyone think that would be Great to make a small module,with trigger input, that can randomise the first module to the right?? This in order to make randomise function controllable with cv trigger


(Skrylar) #11

That sounds like just a big sample and hold patched in to CV inputs :thinking:

Screenshot%20from%202019-01-27%2016-26-47


(Phil Golden) #12

There is an override that dev’s can use to disable randomising of any parameter but it is down to dev discretion to use it, void randomize() override {} user feedback might help with swaying their opinion on which parameters to not randomise.

It would be very nice though: to be able to hotkey ‘r’ and click a parameter to exclude that from a randomising que. Just a matter of ctrl+r then, perhaps r+left click could remove it from the list. Hopeful thought!


(fra) #13

Yes it is similar but the advantage is that it would be faster and it will work also for the few thing that don’t have CV imput


(Hardyfinn) #14

I’ve just tried your suggestion, but it falls short in two counts. The noise output produces the same values out of the s&h for each output, so really requires one utilities per s&h to cover the modulation space. Secondly, that s&h module requires amplifying to cover the full volts range of the CV ins.
Result - it works, but with lots more modules