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
Problems with delays in poly streams...
5 posts
• Page 1 of 1
Problems with delays in poly streams...
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
-
Spogg - Posts: 3358
- Joined: Thu Nov 20, 2014 4:24 pm
- Location: Birmingham, England
Re: Problems with delays in poly streams...
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...
-
martinvicanek - Posts: 1328
- Joined: Sat Jun 22, 2013 8:28 pm
Re: Problems with delays in poly streams...
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
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
-
Spogg - Posts: 3358
- Joined: Thu Nov 20, 2014 4:24 pm
- Location: Birmingham, England
Re: Problems with delays in poly streams...
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.
BTW do you have a reference or a schematic for what you are after?
BTW do you have a reference or a schematic for what you are after?
-
martinvicanek - Posts: 1328
- Joined: Sat Jun 22, 2013 8:28 pm
Re: Problems with delays in poly streams...
I just sent you what I have, and many thanks for taking an interest
Cheers
Spogg
Cheers
Spogg
-
Spogg - Posts: 3358
- Joined: Thu Nov 20, 2014 4:24 pm
- Location: Birmingham, England
5 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 17 guests