Page 1 of 1

Problems with delays in poly streams...

PostPosted: Tue Oct 03, 2017 3:48 pm
by Spogg
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

Re: Problems with delays in poly streams...

PostPosted: Tue Oct 03, 2017 5:21 pm
by martinvicanek
Hm, I'm thinking perhaps you could do it in blue instead of white (poly). Something similar to the tonewheel in a recent post. Hm...

Re: Problems with delays in poly streams...

PostPosted: Tue Oct 03, 2017 5:51 pm
by Spogg
I was thinking about Blue too, but I need to think more about the polyphony aspect.
Exciting a resonating system in Blue should be easy but to get it properly polyphonic is another thing entirely. The organ thing involves selecting from pre-made signals without pitch bending and the like. Hmmm...

Plus, I'm still in shock that selectors don't fully turn off the delay memory creation. I tested in the latest 3091 alpha and the result is pretty much the same with the selectors. It does seem to use less CPU though and I can get away with 4 bidirectional delays with one scattering junction but that's not exactly a membrane emulation!

Cheers

Spogg

Re: Problems with delays in poly streams...

PostPosted: Wed Oct 04, 2017 12:52 am
by martinvicanek
Well, if your mesh is tuned to the note played then yes, you would need as many meshes as you want voices. The advantage of Blue would be that all meshes are already there, no need for dynamic allocation as you play. The price for that is you need to manage voices yourself (in Blue), which might be a bit tricky. :mrgreen:
BTW do you have a reference or a schematic for what you are after?

Re: Problems with delays in poly streams...

PostPosted: Wed Oct 04, 2017 10:27 am
by Spogg
I just sent you what I have, and many thanks for taking an interest :D

Cheers

Spogg