Randomise

[RobinC]

Button that allow you to randomise the values on the current preset then send them to the device

[martin]

This belongs to the Snapshots feature. My idea is that the user could set the “amount of change” for each control in the Electra One console, Something like from 0% to 100%, and transfer this information to the controller. Once the info is in the controller there would be a button to randomize the control values accordingly.

[RobinC]

That would be cool. I’ve currently been playing around with the snaps feature as a way of storing a custom init patch and then diving off sound design from there. A randomise feature would also be a cool way to start some patches

[mokomo]

+1 for Randomise; particularly if objects could be set to be part of 0 or more Randomise Groups for discrete triggering and % impact)

[riggar]

• 1 for randomise too the suggested implementation allows full range from randomise everything to a very specific requirement - super!

[Futureaudio]

+1 for Randomise function

[OldManZero]

+1 to randomization. I’d love to see a randomization range attribute for each parameter as well as tags/groupings so we could group together various parameters for multi-parameter randomization. (Randomize all, randomize oscillator settings, randomize sequencer notes, etc.)

[oldgearguy]

generating the random numbers is straightforward. LUA provides the code to do that. (see at the end here). The challenge is in the implementation for a typical synth patch. You have a lot of parameters. Some have nice ranges like 0 to 127, other are 0 to 100%, others -50 to +50, some are simply on/off, etc. So you would have to tailor the call to generate the random numbers differently for each parameter.

That’s all doable of course. The question is whether it would be generally useful to invest the time and codespace to programming all that in. On the plus side, when you define a control, it has a range, so the Electra One does have the base information needed. The next step would be figuring out when you wanted a value from the knob/screen or from the random number generator.

Then there’s the idea of generating good/valid/useful random values or generating a new value that’s some percentage from the current value, etc.

If you want to play around and don’t mind working with LUA scripts, some basic stuff (untested since I’m not in front of any hardware):

function seedRandom()
   math.randomseed(os.time())
   math.random(); math.random(); math.random()
end

function newRandom ()
    local r = math.random(0,127)
    print(string.format("new random number: %d", r))
end

For a quick test, I’d create two virtual momentary buttons, one labeled Seed and the other labeled Generate. Attach the seedRandom() function to one and newRandom() to the other. Press Seed once, then repeatedly press Random to see the output.

The math.randomseed() should be called once to seed the random number generator and the 3 calls to math.random() are used to pop off the initial random values. There’s a long discussion about the quality of the underlying random number generator in LUA and the consensus is to throw away the first few after calling randomseed since they tend not to be so random. If you don’t call randomseed() once, you’ll generate the same sequence of random numbers every time.

The function newRandom() has a hardcoded range of 0 to 127 for this example. You’d likely want to call it with different ranges for each control and instead of just printing, maybe jam the new value into the parameterMap or send it back to the synth.

[Flyweight]

print(math.random(-50, 50))

This works for negative numbers as well. tested with lua 5.4 on windos.

[oldgearguy]

@oldgearguy

function seedRandom()
   math.randomseed(os.time())
   math.random(); math.random(); math.random()
end

function newRandom ()
    local r = math.random(0,127)
    print(string.format("new random number: %d", r))
end

Here’s a quick randomization template (uses all virtual controls so no synth needed)

Randomize

The 4 top buttons display various values based on the ranges set in the LUA code

EDIT - Did some slight updates (using the headers above the buttons to document the ranges) and added 3 more controls to play around with a sliding percentage of the current value.

[Flyweight]

great stuff to try out. thanks!

i would like to randomise some tuning tables
however its difficult as the data is split in 2 nibbles.
Have not found how to do that in lua.

so 255 = FF = 0F 0F
or 1 = 1 = 00 01

any hint will be very welcome

interesting would be to take the value min/max and current value to apply a persentage of random.

[oldgearguy]

newVal = newRandom()

highNib = (newVal & 0xFF00) >> 8
lowNib = newVal & 0x00FF

for full range (16 bit, or in the case of NRPNs 14 bit) values

or

highNib = (newVal & 0xF0) >> 4
lowNib = newVal & 0x0F

if you know your number is between 0 and 255 (8 bit values)

---

(I assume you want to randomly move some percentage away from the current value?)
This is not the most optimized or even the cleanest, but it gets the idea across

what I might try for a 10% (0.1 (or 0.05 + 0.05) is 10 percent) variation from current value (assuming all integers!) is

controlMin = 0
controlMax = 127
curVal = current_value_from_control_or_parameterMap

variation = math.floor((0.05 * curVal) + 0.5)
min = math.max(controlMin, curVal - variation)
max = math.min(curVal + variation, controlMax)

newVal = newRandom(min, max)

The idea is using whatever the current value is (say 40) and taking 10 percent variation around it (+/- 2 which is 5% each side) and then using the LUA math.min() and math.max() functions to ensure the new value doesn’t go too high or low and then pass that as the new range for a random value. This will tend to produce small variations if your current value is low and larger variations if the number is high.

Note the math computing variation is effectively creating a rounding function since LUA doesn’t have one and your multiplication may result in a fraction. So even if you change your percent variation to a different number like 30% (+/- 0.15 each side) you still need the floor() with the + 0.5 at the end to round to an integer.

If you want a fixed amount of variation (percentage of the total range), use
variation = math.floor(((max - min) * 0.25) + 0.5) [where the " * 0.25 " part represents 1/2 of the percentage of variation, in this example 50%]

[Flyweight]

Wow Thomas that’s’ great! thanks for that.

Will play around and hope I might manage tuning tables with some pitch random for the Ensoniq mirage.

[oldgearguy]

just a coffee-fueled brain dump. lol

The idea of a percentage based on the current value is interesting for a musical context. Most random algorithms simple generate a value between min and max, so you can get big jumps over time. For synth parameters, that’s usually good to generate a wide variety of possible patches.

Percent based on current value ends up creating very small variations on the low range (since even 50% of 4 ends up generating random numbers between 3 and 5) which might end up sounding better than sudden jumps at low values. Definitely something to play with.

Other note - when I get some time on the Electra One again, I’m going to investigate whether the random function “works better” (i.e. - more random) if you pass in no range, let it generate a number between 0.0 and 1.0 and then scale it after you get it back (versus sending in a range). Some comments on the net seem to imply that it’s less random when passing in a range.

[Flyweight]

yeah randomizing has good use in musical context.

It would be great to make section and then being able to load ‘templates’ or apply a percentage of random to the currentValue. So you can select predefined envelope curves or just randomize them.

On some synth that have a performance mode you can cycle through voices and assign different patches to each voices.
There slight randomization shines.
You just load a copy of your patch and apply a small random to each patch.

In terms of tuning tables randomization of micro pitch is as well powerful. You can make boring sounding synth sound alive.
Basically this is what many older analog synth provide out of the box but in an uncontrolled way
I think midi pitchbend might also be usefull for this.

Looking forward to try your tips.

[martin]

I am silently listening here. Great work guys!

What is kind of emerging in my mind is an idea of providing number of built-in functions that users could call from the “function” field of a control. It would be especially handy in combination with the virtuals. I want to use this for the page and controlSet switching, but calling randomisation would follow the same pattern.

I would say that anything that users invent in Lua and that would become frequently used, can be later implemented as an built-in function in C++.

I hope you catch my drift.

[Flyweight]

Thank you Martin for this awesome platform.

It would make most sense to me if there would be an additional grouping possibility and then you apply some kind of magic only to that group. like for example the randomization.

controlSetId is limited to the currently active page and only one set can be active at once.

But maybe most sense would to just use group add groupId so 1 group can be more then 6 controls and allow a function to be added to a group.

Lua is really a great idea.

But for me its hard to debug my own code,
I use a lua binary if I need something to work but what would really help me is being able to connect to the current lua session on the e.one.

Now for example I am trying to make copies of the parameterMap in a for loop. And I try, load the lua code, disconnect the app, start the console. Fail and do the whole thing over and over.

Of course its my own stupidity // inexperience but an interactive prompt would help me as a noob a lot

I see there are already some off the shelf solutions like luapropmp or eLua. No idea how well they work or if e.one has an UART interface.

[Flyweight]

Your randomizer work great.

Can’t wait to try it in a working template.

What I am aiming for is a dial where you can set the randomization strength from 0 to 100%.
Where the percentage is the min and max the value can be different from the current value.
As you described.

And then as well the tuning tables trying out the shift right logic.

So that’s a lot of homework. lol

Thanks!

[oldgearguy]

so it appears that os.clock() is an illegal call due to the fact that LUA on the ElectraOne does not know about the “os” library. I was wondering why the randomseed() wasn’t working well.

[martin]

I should be able to get this working. The low-level firmware supports random/seed.