Just looking at VSIG, I note the dlysmp2n has a maximum sample size of 720 seconds at 48kHz. The length gets divided by the number of channels and halved if you go to 96kHz, so that is perhaps a guide for how much we can use. By my calculation thats 34,560,000 samples available, each of 32 bits. The data structure used by ~gen in Tom’s circular buffer example (massive thankyou BTW) uses 64 bit floats. According to some documentation I found the H9000 uses 32 bit floats as its maximum bit depth, though not sure if internal data structures are bigger than that or not. I’m not sure if there is a conversion going on in creating the buffer on the H9000, or if a 64 bit array element is built from 2 x 32 bit bytes in the H9000, but conservatively we should have 17,280,000 samples available to ~gen via RNBO. I have no idea what happens if we exceed the RAM cap. Probably nothing good.
Thanks for that information about dlysmp2n. I’ve managed to induce crashes with dlysmp2n VSig patches, but I do have one running stable that is 12 seconds x 4 channels– so max of 96 seconds at 48k. To help with stability, I keep this algorithm isolated on its own fx chain. I was running into issues when I had other delay algorithms running in series with the dlysmp2n based algorithms.
I’m encountering something similar with a RNBO patch that has data object set to 3,840,000 samples that constantly records incoming signals. On its own, it’s pretty stable. When I have other algorithms (Eventide native/Vsig or RNBO), in the FX Chain, the chain will occasionally crash.
