radiotonga

1) If I'm feeding multiple objects with noise~, and since noise can't be seeded, is it best practice to just use one noise object and route its output to the different objects in the patch? Of course, to get different numbers I would need to use multiple delay~ as well.

2) I'm cleaning up a big messy patch that uses 2 filtergraph~ instances inside poly~. I'm trying to delete all that is unnecessary, and while I'm sure this is not the most important, I wonder if replacing filtergraph with svf~ or filtercoeff~ (along with biquad) would decrease CPU usage. Since I'm not actively using filtergraph, and it is a GUI object perhaps it is an unnecessary lag?

1) If I'm feeding multiple objects with  noise~, and since noise can't be seeded, is it best practice to just use one noise object and route its output to the different objects in the patch? Of course, to get different numbers I would need to use multiple delay~ as well.

2-unrelated-questions-multiple-noise-objects-and-filtergraph-gui-hunger

1)But then you'd need to modulate the delay times as well to get the relationships between the original noise and the delayed part to vary as well... Seems like just using multiple noise~ objects would be simpler.

Are there situations where you could use normal non-signal [random] instead?

Thanks Wetterberg. I don't get what you mean by modulating delay times, I just instantiate once [delay~ 100 100], [delay~ 150 150] and so on. You made realise though that no two noise~ objects output the same number... Strange, I just had this idea that it wasn't so from another guy whose patches used the delay object under the false premise that "noise~ cannot be seeded, you have to delay its output so it is different from other noise~ objects in the same patch". Blah, anyways, I guess that this thing boils down to what is most economic at signal-rate (I need this to be so), either different noise~ objects or different delay~ objects on a signal, and I'm afraid I'm not qualified to such discussion.

 interesting but is currently way over my league. Do you think that a GUI object is such a lag on the system, if it's nested inside a poly~ and hence can be instantiated multiple times?

2) Hmmm, filter design looks very interesting but is currently way over my league. Do you think that a GUI object is such a lag on the system, if it's nested inside a poly~ and hence can be instantiated multiple times?


generally you'll avoid gui things inside subpatches, but I do remember seeing filtergraph inside some very excellent Stretta patches, so it can't be that bad.

There used to be a problem with [noise~] because, although each object used its own RNG, when multiple objects were instantiated at the same clock tick (which is what happens when you open a patch) they all produced the identical sequence (i.e., the signals were 100% correlated). But I think Cycling '74 eventually recognized that this was a problem and made an attempt to fix it. For some reason it looked to me as if multiple [noise~] objects now all draw from a single RNG sequence. This would give uncorrelated signals, at least to the extent that the underlying RNG doesn't have any correlations. The linear congruence algorithm C74 uses does will show up correlations, but I don't think there is anything that would be obviously audible in the course of signal processing. So I don't think this is a problem any more.

FWIW, I avoided this problem in Litter Power by using a "master seed generator" that is guaranteed to generate a different seed for each instantiated RNG object. So even when multiple objects are instantiated at the same clock click (or even in the same microsecond) they produce independent sequences. This seemed easier and more reliable than, for instance, allowing users to manually set up seed values. And the algorithm used is a more robust RNG.

i thought that older versions of the noise object were always outputting the same stuff, and then they changed that for max5, no?

Apparently that was the issue all along. The patches I've seen where a delay~ is applied to noise~ are most likely from the 4.x era.

2 unrelated questions: multiple [noise~] objects and [filtergraph~] GUI hunger