I’ve developed lots of modules, just haven’t released anything yet in the library apart from the Plaits/Macro Oscillator fork. (Under the Atelier plugin name.)
regarding reverbs and complexity:
my second module was a port of mVerb
I did it just for experimental reasons: I was not at all convinced by the model “one sample processing” in Rack
but when I ported it and discovered that was working and the weight on cpu was minimal, I was in awe
that’s one of the reasons I loved Rack (as fun platform for programming)
you need a double buffering only if you do ffts imho
1 Like
Well that seems like a pretty simple 1024 point real FFT without much processing. I’d like to do a 1024 point real and imaginary fft and overlap them by 50-75%… aka compute a 1024 point real and imaginary FFT every 256 samples. So it’s a little bit more work but we’ll see how it goes!
I’ll try both approaches (worker threads and doing all the processing in the audio thread). Thank you for sticking with the conversation. Appreciate you advocating for the audio thread approach! Don’t know if I would have even seriously considered it without your recommendation.
Your experience mirrors my own! It really surprised me too when I made my reverb module. My reverb module seems to run much smoother/balanced when I process things one sample at a time and only uses ~2.5% CPU on my $99 dual core HP laptop.
When I do the block based approach within the audio thread it tends to be a little more “spikey” with the CPU usage. It will go as low as 2.3% but then jump as high as 3.2%.
Oh, that Atelier is cool! Nice. Why not release more?
1 Like
No proper panel designs yet.
1 Like
Well, @pyer seems to be the person to talk to about that, but you know that as he has designed atelier beautifully. 
I would offer myself as assistance, but I have nothing to show off except a module concept and am still more used to working with pixel based assets.
1 Like