In search of inconsistent results...
  • I have been using a method of transitioning sounds on a timer lately and it has led me to the following discovery: when you reopen a patch all the LFOs and random nodes are in exactly the same spot, resulting in very nearly identical playback. It is pretty much note for note and bleep for bloop consistent. This is pretty nice when practicing playing along with the track, as I know that an asynchronous change will occur at X seconds into the timeline will occur and play around it.

    But now that I've noticed it, I kind of want to know how to actually make it different each time it plays, even if it is when you first open the file. I find that when I leave the patch open for long periods of time it will develop cracks and pops (is this the new bug I've been hearing about?) so I restart the patch when I want to record it.
    Section 31.audulus
  • It's a shame that the random node doesn't have some way to change the seed programmatically.

    Change the seed programmatically.

    That is exactly what I was trying to say!
  • So the best I can do would be to contrive some way to have most of the random come from one or two nodes and then manually increment the seed before reopening the patch? I will give that a shot.
  • It’s handy a times to have a repeatable “random” sequence, so I wouldn’t want to have the default changed, but it would handy to have perhaps a gate on the node that would change the seed.
  • Totally agree, the default is fine.
  • BTW love the performance.
  • This is some of your finest work Robert. I mean that. As far as the cracks/pops, mine does it to after about 3-4 minutes and the cpu usage starts to hit 90+%. I'm on a macbook pro 2013.
  • The way to get true randomness is to use a free audio input as a source of noise - you may have to amplify it a lot but that does work. If it’s an iOS only patch, just use the microphone input. As far as the crackling over time I know this has to be some kind of bug, its happened for a while, but don’t know how to repro it. If any of you can grab a video of this happening it might help trace down what’s going on.

    Computers that need true randomness in them use a special flying transistor noise generator module inside them. Using a flying wire from your ES-8 will work too. I’ve suggested as a superiror solution to have a date/time node that outputs a number that is the system’s date time combo then send that to a random node as its seed. It’s not pure theoretical randomness, but it will do for this use, if not for cryptography haha!
  • Interesting idea using an audio input. In the patch I have posted, how would you go about this? Modifying the turing machines? This might even merit buying a dedicated noise module.
  • Basically anywhere there’s a noise node you’d replace that with the audio input. You can also wavefold it x10000 with sin(mic*10000) to get a more consistent white noise distribution. To use multiples of the same input you’d just delay the triggering of the noise by a nominal amount of time. I’ll whip up a patch and post it here.
  • The trigger delay turned out to be the wrong method - changing the amplification factor of the wavefolding was a better solution:
  • As for buying a dedicated module - you can if you want pure white noise randomness, but methinks this would work fine in most situations?
  • The mic noise is an excellent idea. Clever to wavefold it.