May 24, 2018 at 4:34 pm #84098
for some of my modulators, the value range increments
in units of 10 ie: -360<>+240
but if i randomize the modulator value, it comes back
with values other than x10.
is there a string.format expression to deal with this?
ie: for hex, it would be
this is the random method:
function randVoice() -- This variable stops index issues during panel bootup if panel:getRestoreState() == true or panel:getProgramState() == true then return end -- ----------------------------------------------------- math.randomseed(Time.getMillisecondCounterHiRes()) --[ seeder for 32bit ]-- -- ----------------------------------------------------- local param=nil local min=nil local max=nil local rnd=nil for i=1,21 do param=tbl_voiceParam --[Voice Edit params]-- --[any value range]-- min = param:getProperty("modulatorMin") max = param:getProperty("modulatorMax") rnd=math.random(min,max) param:setModulatorValue(rnd,false,false,false) end endMay 25, 2018 at 2:27 pm #84108
if you want randomize -360 to +240 I would randomize -36 to +24 and the mulitply then result by 10
May 25, 2018 at 3:26 pm #84112
- This reply was modified 1 month ago by Possemo.
yes that seems to be the simplest.
s’pose if it was for min/max, can do the same,
dividing it first.June 10, 2018 at 9:45 am #84229
ok, i didn’t apply your method yet. but i’m observing
something strange with the randomising of this parameter,
which goes from -360 to +240: it just seems to be going
in incrementing direction – ?? – and then looping round
to the start again. very odd, can’t explain this.
i’m going to reload the previous version to see if it
was doing this ( i just copied this modulator several
times – but they all have unique names so it shouldn’t
the random script is same as before.
the other parameters ones are ok.June 12, 2018 at 12:38 pm #84248
ok so now i’ve applied your advice with this:
function randMultistep() -- This variable stops index issues during panel bootup if panel:getRestoreState() == true or panel:getProgramState() == true then return end -- ----------------------------------------------------- math.randomseed(Time.getMillisecondCounterHiRes()) --[ seeder for 32bit ]-- -- ----------------------------------------------------- local param=nil -- local min=nil -- local max=nil local rnd=nil for i=1,1 do param=tbl_multistepParam --[ multistep params ]-- --[any value range]-- min = -36 --param:getProperty("modulatorMin") max = 24 --param:getProperty("modulatorMax") rnd=math.random(min,max) param:setModulatorValue(rnd*10,false,false,false) end for i=2,4 do param=tbl_multistepParam --[ multistep params ]-- --[any value range]-- min = param:getProperty("modulatorMin") max = param:getProperty("modulatorMax") rnd=math.random(min,max) param:setModulatorValue(rnd,false,false,false) end end
and it’s working and i’m getting divisions in 10s.
however: all that parameter is doing is incrementing, in
a loop: stepping up to maximum, and then starting again
at the minimum. does this have anything to do with it
using a mix of negative and positive values? should i just
have a translation table for it to fetch end values from?
could be the simplest solution. (but why does it do this???)June 12, 2018 at 1:08 pm #84250
well i tried that, and it didn’t work either.
end up with a table of 61 items, as a panel pre-load table,
and then do:
and it’s very odd but it still goes always incrementing,
even if the jumps are random.
must be something else i’m doing wrong.
edit: i realise that, above isn’t correct, btw, because it’s only
taking the values of the keys. i tried doing:
for j=1,61 do pval = tbl_multipitchval[j] end
in order to define pval as the thing to randomise, followed by:
didn’t work either. *still* went incrementing…something odd here.
(er, no: just wrong, because i’m still getting the value of the key,
not the key, with that…start again)June 12, 2018 at 8:25 pm #84257
could this be a pseudo-random problem?
where it has a pattern with the first random?
i’ve noticed the same ‘increment only’ thing going
on with the other pitch modulator (-360<>+240) in the
other mode. this is a show stopper at the moment.
it is NOT the negative values. it’s working fine with
the other modulators with negative range.June 12, 2018 at 9:48 pm #84259
stll totally stumped by this:
two out of three of these modulators randomise in this
strange incrementing way, and the other one does what
it’s supposed to. it’s the same script essentially.
have no idea where to look for the problem.
all the others randomise properly as well.
i’ve changed the modulator name, made a new, fresh modulator…
nothing seems to make any difference.
????June 12, 2018 at 11:33 pm #84261
I had that problem too. It could be that in some cases the rnd won’t get the value from the randmoseed. Try the other randmoseed (time * clock) or run them both.June 12, 2018 at 11:59 pm #84263
but wasn’t this one 32bit friendly? the other one doesn’t run
how would one run both?
good to know it’s known, anyway.
would be nice to get to the root of it !
June 13, 2018 at 7:37 am #84265
- This reply was modified 1 week, 4 days ago by human fly.
okay, here’s my ugly fix – for the time being:
(and i can work onwards)
i’ve added a dummy modulator on my hidden ‘utility’ tab page,
and added a
[ 0 ]key to the table of modulators being randomised,
and so now i random 0,21 instead of 1,21
and that seems to fix the issue, and the 1st parameter randoms normally.
the new ‘vdummy’ modulator is now the one that increments.
i don’t need to change any other scripts relating to these modulators,
the ones that collect values to write a Voice data, so i’m hoping it
will be a tidy clean intervention.
i don’t much like doing this, it’s a bit messy, but hey, it was quick,
doesn’t alter much else, and it’s easy to trace and remove if need be.
it still doesn’t explain why it doesn’t happen with one of the groups?!!!June 13, 2018 at 8:01 am #84266
oh i see: the other group IS doing the same thing, i just hadn’t
noticed: that group includes a combo dropdown list, and that is
incrementing as well. so i will have to do the same thing there.
so this is my suggestion for the reason: the seeding operation
does not have time to complete before the next instruction?
what if a a delay was inserted there, either with another instruction,
anything, dunno… evidently does not need to be a timer…
well, essentially, that is what i’m doing by inserting a dummy
modulator to process, i suppose.
i will have to check if it happens with the other seeder.
i am using your *10 suggestion btw, seems very adequate 🙂
and i’m able to split the randomising into more than 1 iteration
for this, with the dummy only in the 1st one, with everyone
so that’s a ‘fix’. job done.June 13, 2018 at 9:26 am #84271
yea it should be 32bit friendly in the way that it shouldn’t show the “no-rnd increment bug” on Ctrlr 32bit. But if the bug does show anyway I would experiment with randomseed some more.June 13, 2018 at 9:35 am #84272
so that’s the bug you had that made you stop using
the other method? i’m using 64bit Ctrlr for programming anyway.
of course, i’d rather not have to rewrite sections of code
for 32bit and 64bit …
or maybe combine the two seeders, make it even more random..
but that might just be a longer process. there are probably
many ways to generate a seed anyway. i experimented with this
in synthedit, and was producing pseudorandom patterns, was
quite interesting until i found a proper solution.June 13, 2018 at 1:09 pm #84274
I don’t see that much ways of making good rnd with randomseed. In theory a hires clock (milliseconds) should be best. Everytime you run randomseed it should have a different value – only way I know to do this is taking the actual time of day.
You must be logged in to reply to this topic.