Lfo eg type non randomizable

[ContemporaryInsanity]

Also Start & End when Type is Step Sequencer.

[baconpaul]

I can actually do better than that

I made the type so the wave-forms inter-randomize but if you are on step sequencer you dont

So pick sine and random and you flip sine saw noise etc...

but pick step and random and you stay on step

This also made me add custom randomizers to surge params in rack which is something i've been wanting to do anyway

next release.

[ContemporaryInsanity]

'add custom randomizers to surge'

Can you elaborate on this, as I'm developing a module for randomising other modules with slew & % I may need to take this into account?

[baconpaul]

Paramquantity has a virtual method called randomize which a param quantity can override

the api for randomize with alt r is for each pq do if pq->randomizable pq->randomize() (or that it may be in the base class randomizer)

this allows param quantities to have randomization responses other than value = urng * width + min

[ContemporaryInsanity]

I have a module in development that randomises parameters of a module by a percentage over time, in order to do this I have to directly change parameter values as opposed to just calling randomise, so attempting to randomise LFOxEG with my module can switch types as Type isn't set as non randomisable. Subtly randomising envelopes / LFOs etc is great for 'humanising' things but this breaks it for LFOxEG. I can ultimately get around this (for me personally) by having my own Surge XT custom build where LFOxEG Type randomizeEnabled = false, but you may wish to reconsider?

[baconpaul]

So you’ll have this problem with anyone who has careful custom randomization but I’m not sure how many plugins have thst.

A few things come to mind.

First you can build an exception list of module ids and parameter indices in your plugin and know what to skip when you find then. A bit gross but would work

second you could have an abstract interface you support for all open source devs which you ask them to implemenr if they want to support an alternate custom Parameterization but then you have to support thst and get devs to change their code. Then you could dynamic cast. But that’s quite a lot of work.

But I don’t think there’s a great third option. You are changing params and those params the get changed. If there’s some params you don’t want to change you need to the the params somehow. The rack has a single flag for randomize which you are re using but thst flag couples with the randomization implementation.

[baconpaul]

Oh and if I were you I would do option 1. I bet that list will be short and it’s just a tactical way to do it. And library param and module ids need to be stable otherwise streaming breaks anyway

[ContemporaryInsanity]

On my to do list is functionality to exclude parameters from randomisation (like Stoermelder STRIP), that should get around it.

One other thought, LFOxEG context menu option to Lock Type against randomisation?

[baconpaul]

Oh sure that’s a good idea in any case

[ContemporaryInsanity]

Just tried the latest build.

Randomising LFOxEG in Step Sequencer mode using either my RAND module or Stoermelder STRIP no longer randomises steps, only triggers, yet randomising using the context menu does randomise steps?

[baconpaul]

I didn’t change anything in steps though?

can you share a vcv file and plugin list that shows the problem? But I’m not sure there’s anything I either changed or can fix unless the diff above has some side effect I don’t see (and I just read it again)

[ContemporaryInsanity]

It's odd.

Take STRIP & LFOxEG:

Hit ctrl-r on LFOxEG and get:

Which is expected behaviour.

Now randomise with STRIP and get:

Steps stay the same, triggers, uni, start & end are randomised, which is unexpected.

[ContemporaryInsanity]

Sorry, triggers randomising is expected.

[baconpaul]

huh ok well i'll have to debug that!

the fact that randomize in rack works makes me thing strip is using some other api. I wonder what it could be though?

[ContemporaryInsanity]

https://github.com/stoermelder/vcvrack-packone/blob/v2/src/Strip.cpp

Line 208+

[baconpaul]

From reading that code the only difference between strip and built in is strip has a custom exclude list

Ar you running strip in EXCLUDE_NONE mode or whatever?

I've never used strip but it looks like it is just trying to call ->randomize() on some of my params. that "some" is probably the difference!

[ContemporaryInsanity]

The exclude list is populated via clicking on inc/exc then clicking on the control you want to exclude, so by default nothing is excluded until those actions have happened.

[baconpaul]

Oh i see the problem

Strip doesn't iterate over parameters. it iterates over parameter widgets and then gets parameter from them

Since I added a compound editor (to do things like drag-across-bars and the like) we don't have a param widget for the bars

So that's why it doesn't work

I don't know what I can do to fix it. The LFO editor is a single widget that operates on 16 params so it isn't a param widget itself. But Strip is doing what it says -for all single param widgets randomizing them. Just that's not what you want. What you want is for all randomizable params randomize them.

So I think this is a strip change.

[ContemporaryInsanity]

Ok, that makes sense, I think (I'm long since retired from coding and am very much C--).

One more bit of oddness, I note that STRIP randomises MOD MATRIX regardless of randomizeEnabled, whereas my RAND module will only do so if in FORCE mode to ignore randomizeEnabled, which I find odd as STRIP calls randomize() whereas I read & reset parameters explicitly.

Sorry about this, controlled randomisation is very much fundamental to how I use rack, hence developing my own RAND module.

Anyway, thanks for everything so far & keep up the BRILLIANT work :)

[baconpaul]

ParamQuanitty::randomize() randomizes and does not consult the ->randomize flag

Module::onRandomize looks like this

void Module::onRandomize(const RandomizeEvent& e) {
        // Randomize all parameters
        for (ParamQuantity* pq : paramQuantities) {
                if (!pq->randomizeEnabled)
                        continue;
                if (!pq->isBounded())
                        continue;
                pq->randomize();
        }
        // Call deprecated event
        onRandomize();
}

So the reason strip randomizes the modulation matrix is because it ignores the randomizeEnabled flag.

I feel like we should be talking about this on strip GitHub no? :)

[ContemporaryInsanity]

Agreed.

Can we still have

One other thought, LFOxEG context menu option to Lock Type against randomisation?

[baconpaul]

yup. that's why i didn't close the issue. :)

[baconpaul]

OK nightly later tonight will have that as option. this issue will close when i merge that change.