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?
1 Like
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?
The bordL sequencer lets you randomise the pitch, gates and slides/skips separately.
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.
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.
4 Likes
SQUONK uses custom randomizations using contextual menu
3 Likes
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.
5 Likes
Yes, I use it Knock now you mention it!
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.
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
1 Like
That sounds like just a big sample and hold patched in to CV inputs 
1 Like
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!
1 Like
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
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
I’m bumping a topic out of the ark, but there are loads of great modules kicking around that do have a randomize function which will randomize useful things like SEQ-3 does but there doesn’t seem to be any way to kick off that randomize outside of clicking on a right click menu option or using a key combination when that module has focus.
Is there anything now, four years after this topic was created, that would allow such a thing to be triggered from a trigger pulse? I tried in vain to find a way to use stoermelder modules to get this working, but could only find something that fires a trigger when you do a CTRL+ key combination, not that would send that to a different module.
Hope I missed something obvious.
Yes. ATM t is difficult to prevent randomization of some params. It’s been years, but I think ATM you need to derive a new widget or at least a new param? I did it one in response to some bug report…
Easy enough to override onRandomize, then you have complete control and can cover randomizable things that aren’t params, such as right click options. Plus you can maintain any constraints you have.
good point. fwiw most of my right click options have, in fact, been params.
Maybe I am misunderstanding, but you can use Stoermelder Strip for this? It has a randomize on trigger. In the context menu of Strip you can select “randomize parameters only” and you can include/exclude certain parameters as well.
1 Like
Oh wow, I use STRIP all the time, never noticed that before! Cheers
I had been looking at modules like Macro and Map. D’oh!
1 Like