Problems with delays in poly streams...
Posted: Tue Oct 03, 2017 3:48 pm
Hi guys!
I’m experimenting with physical modelling and it’s going quite well, but I’ve hit a problem with delays in the poly stream.
I’m using Martin’s quad (SSE) ASM poly-safe interpolating filters and I’ve reduced the memory block size to a minimum (4096) since the short delays are used to generate audio by excitation. This is fine for basic Karplus-Strong and 4 delay-element Digital Waveguide implementation.
However when I try to make a Waveguide Mesh, of any sort of useful size like with 16 scattering junctions and 80 delays (40 bidirectional delays), I’m hitting a problem with the poly system. When I sound any new note I get a short interruption in the stream, a brief silence. This is present on the VSTi export too.
I assume this is because each note opens a new channel and so has to assign 80 memory blocks in one go, for the delays, for every note. Also there is a small latency when pressing the first note, presumably for the same reason.
It seems I need to allocate memory on a semi-permanent basis, so it’s kinda reserved for when a note sounds, but I think this is impossible.
To make matters worse I proved that if I have several different delay configurations in modules and connect the module outputs to a selector, the memory usage effect of multiple delays adds up, even though I thought the selectors should isolate and not use CPU for the unselected modules. I even tried two selectors in series but the only way I can stop this cumulative effect is to disconnect the module completely in the schematic. It seems that the FS software still evaluates the delays “just in case”, even though they should be out of circuit. Removing their inputs with a selector as well makes no difference; if they are patched to any selector they are evaluated. I see a short large CPU spike when I sound a note even with no selected stream path.
Presumably commercial plugins like Chromaphone can avoid the memory issues by low level programming to reserve RAM for their meshes. Also hardware implementations like the Yamaha VL1 don’t have to create memory space because it’s physically implemented, so just has to be read out as required.
I suspect that I won’t be able to create and play with a decent sized mesh in Flowstone, unless any of you wizards has a suggestion…
Cheers
Spogg
I’m experimenting with physical modelling and it’s going quite well, but I’ve hit a problem with delays in the poly stream.
I’m using Martin’s quad (SSE) ASM poly-safe interpolating filters and I’ve reduced the memory block size to a minimum (4096) since the short delays are used to generate audio by excitation. This is fine for basic Karplus-Strong and 4 delay-element Digital Waveguide implementation.
However when I try to make a Waveguide Mesh, of any sort of useful size like with 16 scattering junctions and 80 delays (40 bidirectional delays), I’m hitting a problem with the poly system. When I sound any new note I get a short interruption in the stream, a brief silence. This is present on the VSTi export too.
I assume this is because each note opens a new channel and so has to assign 80 memory blocks in one go, for the delays, for every note. Also there is a small latency when pressing the first note, presumably for the same reason.
It seems I need to allocate memory on a semi-permanent basis, so it’s kinda reserved for when a note sounds, but I think this is impossible.
To make matters worse I proved that if I have several different delay configurations in modules and connect the module outputs to a selector, the memory usage effect of multiple delays adds up, even though I thought the selectors should isolate and not use CPU for the unselected modules. I even tried two selectors in series but the only way I can stop this cumulative effect is to disconnect the module completely in the schematic. It seems that the FS software still evaluates the delays “just in case”, even though they should be out of circuit. Removing their inputs with a selector as well makes no difference; if they are patched to any selector they are evaluated. I see a short large CPU spike when I sound a note even with no selected stream path.
Presumably commercial plugins like Chromaphone can avoid the memory issues by low level programming to reserve RAM for their meshes. Also hardware implementations like the Yamaha VL1 don’t have to create memory space because it’s physically implemented, so just has to be read out as required.
I suspect that I won’t be able to create and play with a decent sized mesh in Flowstone, unless any of you wizards has a suggestion…
Cheers
Spogg