efficient streamy random 'array'

[tester]

I'm looking for a way to generate an "array" (multiple outputs, 32 up to 128) of random values, at rate 4-5 such arrays per seconds. (Basically - destination units will "sample and hold" some of these arrays at random rates in sample-accurate mode.)

Right now I'm using Martin's white noise generator, and "one sample delay" prims, to generate a chain, that is redistributed to outputs and then to mono4 combinators. But right now (32 outs) - the whole thing eats c.a. 2% of CPU.

Question. Can this be somewhat simplified? I don't know, some hoped multidelay single code? Or some weird version of noise generator?

p.s.: I'm prototyping a concept, so there might be some things that I'm not sure how they should work.

[KG_is_back]

There are several ways to do that. To pick the most efficient one I need to know in which form the output should be.

You can use

Code: Select all

streamout out;
float i=0;
float array[128]=rand(0-1); //or whatever range you need
out=array[i];
i=i+1;


and hook that to analyzer primitive. This way you can generate random array every time you trigger it. To import it to stream you simply use float array to mem primitive and wave read prims.

There are more efficient ways that involve assembler to write data directly to external mem and to extract the data more efficiently than wave read prim. They easily can even be sample-precise in therms of when the array randomization happen.
In what form is the "random array" expected to be? a series of output connectors of a module? a mem (wave-table)?

[tester]

It's a simulator of a non-harmonic instrument, thus - made of several sine generators adjusted individually (unless you have a way to do this via 128kpts or higher FFT?). It's a prototyping stage, so the schematic will be heavy and unpredictable at the moment...

Single unit is made of up to 16 individual stereo tones, which gives 32 sine generators (8 prims when using mono4 split, but the amount of nodes does not change; I use stock sines, because they are audibly stable). Each sine generator will be connected to phase modifier and gain modifier. It's possible that some of these connectors will be duplicated in different locations (ways of use) as well, so it would be nice to know how to change the randomization pool to include them too somehow.

So this 32-unit design will be connected to envelope generator(s), and at each envelope re-activation - new phase and gain settings will be re-evoked (via blue version of sample and hold to be sample acccurate). And since this is S&H variation, input can be connected to some sort of hoped slow white noise, in (0-1) range I guess.

Now - the schematic will be made probably of 12 such units described above, but since they will be re-evoked not at the same time (random periods) - scenario with slow ongoing random noise (or else method of having paralel new unrelated values before envelope change) seems to be appropriate. Thus - signal analyzer (having green outs) - may not work well with DAW rendering?

Basically, everything will be on blue streams. Live playback, live modifications, DAW rendering.

There is also one more issue to solve, but I need to check what I have by now; when envelope restarts, and phase is changed on input (the ding sound so to speak) - it produces glitches. But this could be eliminated by adding slight (up to few ms?) fade out/in (sample accurate) on phase change, to have relatively smooth ding and phase variation at once.

[KG_is_back]

Here, a quick build. The mem module creates 16bit aligned mem. The "fill with noise" module fills the memory with random values when boolean is true (So I recommend sending only pulses). Mem read modules read data at given index in the mem. The index is fixed (initialed at stage0) and may be set via properties. The schematic is not fully stable and certainly not idiot-proof, so use it with care. It should be the most CPU optimal way of doing it.

Only thing even faster would be to write everything (including sine generators) into one assembler block.

[tester]

Idiots are sometimes the best beta testers.

We see how it goes. Thanks.

[tester]

Here, a quick build. The mem module creates 16bit aligned mem. The "fill with noise" module fills the memory with random values when boolean is true (So I recommend sending only pulses). Mem read modules read data at given index in the mem. The index is fixed (initialed at stage0) and may be set via properties. The schematic is not fully stable and certainly not idiot-proof, so use it with care. It should be the most CPU optimal way of doing it.

Only thing even faster would be to write everything (including sine generators) into one assembler block.

Something like this?
BTW, is it mono4 compatible output?
This "64" value (in noise gen and in mem creator) is the index size, yes?

[tester]

It seems to work.

[KG_is_back]

Something like this?BTW, is it mono4 compatible output?This "64" value (in noise gen and in mem creator) is the index size, yes?

exactly!

It is mono 4 compatible (and even poly compatible, however all channels will use the same mem), but note that all 4 channels are randomized and loaded at the same time. The 64 value means the mem is 64 SSE variables big ( =4*64 float values, because SSE variable has 4 channels). Attempting to load value from outside the array will result in crash (when the Mem Read module has index equal or above mem-size in SSE values).
Be careful though. Sometimes trying to retrigger the mem create prim causes crashes when audio is running. I've found no way to fix that unfortunately (the same problem that makes my alternative wave read prims unstable).

[tester]

Hmm... as it is - it works, but when placed in the schematic - it isn't working correctly or gives unpredicatble results. :-/

*

Maybe this one could be reworked somehow, without need of mem usage?

[KG_is_back]

Hmm... as it is - it works, but when placed in the schematic - it isn't working correctly or gives unpredicatble results. :-/

*

Maybe this one could be reworked somehow, without need of mem usage?

that was my first guess also... but then I realized the rand function fills the input with random data only on initialization. You would have to completely retigger the schematic with clear audio prim to make it work. Or you may put it in a poly stream and trigger it by new notes, however passing arrays between modules (and especially when one is poly and second is mono) can prove to be very tricky.