This looks like an interesting module!
See the upload ‘custom’ firmware:
This looks like an interesting module!
See the upload ‘custom’ firmware:
I thought everybody news this already. NE also have written about it in the manual
Apparently there are at least 3 commercial eurorack modules based on Daisy (other than Patch itself).
Qu-bit Surface was already discussed here. And this one has a familiar yellow parasite on its back:
I was wondering if anyone knows if there is any open source code for this or something similar to the Desmodus Versio? The description of the reverb and the controls are very similar to the type of effect that I have in mind for a requested upgrade to my recent amplifier project.
Actually, there were promises of open-sourcing something from DV this year. But I suspect they would make it possible to run custom code on it rather then release reverb algorithm sources.
How did you know about the mention in the manual? muffwiggler forum?
It would be good to report it here, many people don’t know what eurorack modules use Daisy
It was on Noise Engineering site somewhere, either in DV manual or some module-specific page.
Or did you try VCV Rack, Plateau
or the reverb in https://forum.electro-smith.com/c/projects-and-examples/18 ?
I made a small doc with links about reverb papers, videos and sources here:
@erwincoumans Wow! Your response is overwhelming! I haven’t started any research in ernest beyond trying the StereoDelay example for the Daisy Seed (which I was pretty impressed by).
Before the Daisy came onto the scene all of my audio design was strictly in the analog realm. I’ve been a code monkey for over 4 decades but I’m a Noob to DSP. My definition of research extends beyond copying examples (although they are useful) to learning the concepts and theories behind what I’m attempting to achieve so I can confidently grow my own or intelligently modify an example to fit my requirements.
I never imagined that I would some day be able to understand DSP beyond a description of how the hardware works let alone actually being able to programmatically create my own audio effects and filters.
Thanks for sharing your knowledge and for the extensive list of resources!
Hi there! Kris from Noise Eng here. We’ve definitely shouted our use of the Seed loud and proud. We’ll be pushing out libdaisy support before the end of the year. We’re pretty small and wanted to be sure we had all the kinks worked out. Look for that to be coming in the next month or two!
Great, thanks Kris, just ordered a Desmodus Versio from Control Voltage
Can you tell a tiny bit of what kind of algorithms are used? Is it similar to the Jon Dattorro paper, but heavily optimized/improved?
DV is in no way descended from the Dattorro line of thought. I personally really like the sound of the recirculant all-pass filter reverbs and have implemented them before. But…
Most early synthetic reverb algorithms were beautiful hacks to create many echos without using very much memory. This is where algorithms like the one you linked really shine. The Seed doesn’t have that problem so we went with a much more memory hungry method based on some topologies i’ve been playing with for a few years. The seed presented just enough compute resources to implement one of these ideas on an embedded platform.
If you want to firmly classify DV in reverb class its a FDN. I would call it a sparse FDN as the delay lines are only connected in small subsets (the FDN matrix is mostly zeros). This is a lot like what waveguide reverbs look like if you convert them to FDN form though DV doesn’t use waveguides and in fact intentionally breaks the waveguide constraints if you look at it from that perspective so it doesn’t fall under the SDN class. DV uses no explicit all-pass or comb filters just basic adjustable length delays.
Maybe a better way to think about it is that its Just a Bunch (32) Of Delays connected by nonlinear mixing nodes.
The real trick in DV is having nonlinearities and gains of > 1 in the feedback paths while keeping it both stable and pleasant sounding.
Thanks a lot for all the details Stephen, looking forward trying out the DV!
32 delay lines is a lot, that must produce some nice smooth diffused reverb tail.
(I had to reduce the number of delay lines in my simple CloudSeed port from 12 to 2, due to memory and compute limitations, may look into that again later.)
SDRAM performance on the seed is a constant battle. Well, DRAM performance everywhere is a battle even on your desktop. The 32 delay lines are scattered through the different rams on the H7 to improve performance. Only about 2/3 of the delay lines end up on the SDRAM. The SDRAM performance is actually what set the max delay time for the DV since we would have had to have put more delays on the SDRAM if they were any bigger.
To get decent SDRAM performance you have to work with the ARM data cache and the FMC (read the manuals on these!). Locality and in-sequence accesses are really important. We actually perform and cache 64 reads from the 32 delays delays before doing any of the dsp to improve the ram performance.
For another product we are working on (which has 48 memory reads per produced sample all in sdram and at 2x the sample rate of DV) i prototyped a mechanism with MDMA that would pull all the SDRAM data needed for the next frame into SRAM while it was doing the dsp for the current frame. Performance was a wash on that one because the particular application has some tricky nonlocality with the delays which ended up costing a lot to deal with. doing MDMA in the background however was very, very effective and its a tool I will def use in the future. If you are reading sequentially from a delay line at a more or less constant rate it would work really well.
In the seed’s favor… The SDRAM setup is about as good as the H7’s FMC can handle. Its pretty close to the max frequency and it is using the full bus width for transfers… So for this class of platform there isn’t much better performance to be had with external dram.
Caching into SRAM sounds good, is there DMA controller access doing that? It sounds a bit like the good old PS3 Cell processors SPUs, creating a software cache.
For my granular synthesizer on Seed, I load up to 64MB worth of WAV samples in SDRAM, and stream up to 20 parallel grains (playing any of the wav files), which seems sufficient. I had to optimize a bit, avoiding memory copies etc. Running out of CV’s / controls is an issue, will use the screen to enable ‘banks’ of controls (or use MIDI instead).
The easiest DMA controller to use for mem2mem stuff on H7 is MDMA. The other dma controllers can’t talk to DTCM and ITCM. MDMA also has a truly epic feature that you can make a linked list of transfers in memory and it will go through them all with only one intervention by the program.
I’ve actually implemented a DMA caching scheme on a PS3 SPU (for a reverb no less) very similar in concept though somewhat more sophisticated to what I mentioned.
Granular should be a dream setup for doing DMA caching since you dont usually change playback speed or direction for the entirety of a grain so prediction should be simple and accurate.