If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
efficient streamy random 'array'
11 posts
• Page 1 of 2 • 1, 2
efficient streamy random 'array'
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.
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.
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: efficient streamy random 'array'
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
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)?
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)?
- KG_is_back
- Posts: 1196
- Joined: Tue Oct 22, 2013 5:43 pm
- Location: Slovakia
Re: efficient streamy random 'array'
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.
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.
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: efficient streamy random 'array'
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.
Only thing even faster would be to write everything (including sine generators) into one assembler block.
- Attachments
-
- mem randomizer.fsm
- (4.16 KiB) Downloaded 780 times
- KG_is_back
- Posts: 1196
- Joined: Tue Oct 22, 2013 5:43 pm
- Location: Slovakia
Re: efficient streamy random 'array'
Idiots are sometimes the best beta testers.
We see how it goes. Thanks.
We see how it goes. Thanks.
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: efficient streamy random 'array'
KG_is_back wrote: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?
- Attachments
-
- mem randomizer2.fsm
- (5.86 KiB) Downloaded 748 times
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: efficient streamy random 'array'
It seems to work.
- Attachments
-
- mem randomizer3.fsm
- (5.83 KiB) Downloaded 746 times
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: efficient streamy random 'array'
tester wrote: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).
- KG_is_back
- Posts: 1196
- Joined: Tue Oct 22, 2013 5:43 pm
- Location: Slovakia
Re: efficient streamy random 'array'
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?
*
Maybe this one could be reworked somehow, without need of mem usage?
- Attachments
-
- random-buffer.fsm
- (2.84 KiB) Downloaded 730 times
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: efficient streamy random 'array'
tester wrote: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.
- KG_is_back
- Posts: 1196
- Joined: Tue Oct 22, 2013 5:43 pm
- Location: Slovakia
11 posts
• Page 1 of 2 • 1, 2
Who is online
Users browsing this forum: Majestic-12 [Bot] and 87 guests