From the original SynthMaker forum (2004–2014), with its members’ names and dates.
exonerate ·
There's a bug with the random primitive, it always outputs the same sequence of numbers when reloading a schematic.
Here's an example osm to test...
Basically just click the button a few times and note down a few of the numbers in sequence, then close SM completely without saving the schematic. Now reload the osm and click the button again. You get the exact same sequence.
If you save before closing the schematic then it will produce a new sequence.
HERE is a related thread to this issue.
This problem basically make generating random presets in a VST plugin impossible.
Cheers 😉
Exo
exonerate ·
Also as a side note the text primitive is truncating the float value by two digits.
Is this for efficiency reason? I think it would be better not to do this because if I save a waveform to text then reload it I've lost some information. Affecting bit depth and quality of the waveform.
Cheers 😉
Exo
Disco_Steve ·
I noticed this two, with my dither perimitive, I spent quite a while making it use a random set of random noise, but each time its the same! could you get round it by seeding the random int perimitive with todyas date and time
exonerate ·
Disco_Steve wrote: I noticed this two, with my dither perimitive, I spent quite a while making it use a random set of random noise, but each time its the same! could you get round it by seeding the random int perimitive with todyas date and time
In the example I posted I am actually seeding the random primitive with the system time, the result is the same.
Disco_Steve ·
opps, thats what you get for not having SM close to hand!
that is a big poo 🙁
could you use todays date, to create an interger, that made a loop go tick X number of times, that moved the random generator on so the start position is a little random, untill this gets fixed by the one man band?
concept?
stw ·
Maybe i got different primitives or i don't understand the bug. I loaded your osm triggered a few times and saved as a new osm for later reference. Closed SM and repeated this three times. I always got different results as you can see below. The first two numbers come from your initial osm which already contained it.
If you save before closing the schematic then it will produce a new sequence.
don't save and try again
actually I'm not seeing this behaviour with you test app? the first two number are always the same, but the rest are different
exonerate ·
Ok I think I'm going insane, or I'm doing something different but in my currents test there is no problem what so ever, I get a different sequence of numbers every time.
Mo ·
Your time seed seems to work fine. Just need to trig it some times on load to get rid of the first non-random numbers. Without the seed it's still the same numbers.
oddson ·
Even if there should be a reoccurring pattern as the millisecond counter cycles through it's range the output should not look like it does here:
stw ·
oddson wrote: Even if there should be a reoccurring pattern as the millisecond counter cycles through it's range the output should not look like it does here:
I've to admit that i don't fully understand the seed input at the rand primitive. It seems as if the seed input limits the output range of the prim. But even if it looks like you got a equal repeating pattern with same numbers on the display in fact they're different. Connect a text prim at the array output and look at the real numbers.
However if i disconnect the seed input the even the display shows a real random output. So i still don't see the bug here...?
oddson ·
EDIT - below is a pile of crap to justify my posting above... the truth is you shouldn't reseed with every output so it's very likely the results are the outcome of unexpected use of the random primitive. It does show, however, that low value integer seeds tend to produce lower value outputs and that might still be a problem.
If you use a seed it's supposed to give you the same sequence each time - which is needed in some processes. By using the MS output as a seed it should give you a pseudo-random value provided there's no pattern to when you seek the value compared with the MS output. (Which of course there is when you keep changing the seed with an adjacent integer with each iteration.)
But from what I understand a proper seed system should not show systematic output pattern (monotonically increasing with a near constant rate of increase for example). A seed system is supposed to utilize sensitivity to initial conditions to generate dramatically differing outputs from adjacent values. (I could just be wrong here and then my whole argument is trash... it just seems to be to be a desirable property of the pseudo-random generator that it not show systemic patterns of output.)
Seeding with the MS output isn't really something you should do (or need to do) but I think it might demonstrate a problem - especially as the output is heavily biased to the low end of the distribution.
Coupled with the fact that unseeded primitive is giving static patterns it tends to suggest there is a problem with this primitive.
Wrote something here? To have a post removed or your name hidden, write to [email protected].