Be ye warned! This is a computationally intense module, so I recommend running it at 32kHz. (It’s possible to run it at 48kHz if you have no incoming CV and the controls stay within particular ranges).
Thanks to @CosineKitty for heavily optimizing this module so it can run on the MetaModule.
In the next release of the VCV plugin of Sapphire modules (v2.5.7), the Elastika will have a context menu option to run it at a different sample rate. (In the v2.0-dev firmware branch, you can access this option). This is useful if you want to run your whole patch at 48kHz but just run the Elastika at a lower rate to save CPU.
would be great to be able to have this option for all, but at least, the more cpu hungry modules like clouds spectral mode, befaco spring reverb, airwindows seems to have a few heavy hitters. im guessing they would only be able to have the resample option setting direct on the mm, unless the devs for those added it into the vcv plugins.
Well, the resampling happens inside the Elastika module, and it only resamples the audio stream (not the controls). To make this a general solution, we’d have to modify the source of any module that needs it. So that has the downside of the module acting differently on the MM vs on the computer, plus it adds a maintenance overhead. Not ideal. But also not impossible.
Another idea is to have the MM engine run selected modules at a lower sample rate, which might work and might make some modules act funny, though we’d really have to see. The upside of that is you wouldn’t need new versions of the plugins to do it, it would just work on any module you choose (however good it sounds and behaves).
There are some downsides to resampling though:
Resampled audio doesn’t sound the same as the original. Not just loss of the higher end (assuming you’re downsampling) but there’s also a little bit of loss of quality (THD) and depending on the module, it might even behave differently.
Resampling itself consumes some CPU. With the Elastika for instance, running natively at 48kHz takes about the same CPU usage as resampling from 48k to 44kHz internally. So you only start to see the benefit if you run natively at 48k and resample to 32k.
Hi everyone, I am the author of Sapphire Elastika. Just to add to what @danngreen wrote, I added the resampler capability to Elastika because it in particular uses more CPU than most modules out there, and I really wanted Elastika to run on the MetaModule.
Most modules will not benefit from a resampler because they don’t use that much CPU overhead in the first place. I think we should prioritize those that cannot run on MM without stuttering, or just barely run while leaving little CPU for other modules.
Dan is right that we could add this capability to other software modules but it would require changing their source code. That said, I designed the resampler to be modular enough that I could use it for other modules also, with minimal work.
The entire Sapphire plugin, including the resampler, is licensed as GPL3+, so feel free to use it in your plugin too if that license is compatible with your project. Or you can look at what I did as a reference and do something similar. I will even be happy to help you integrate my code!
In my opinion, it’s best if this is done with each plugin developer’s participation, or at least consent, to merge into their own code as a pull request. Otherwise we will end up maintaining separate branches of code, which will become less and less fun over time for all of us.
For anyone who is curious, the bulk of the resampler code is in the following header file: sapphire_vcv_resampler.hpp
Developers, if you are interested, feel free to reach out to me in this thread or PM me on this forum.
Just popping in to say what a cool module this is! A CPU hog, but worth it. I’ve only tried it with a couple of sources so far (a sequenced riff from DPO and some drums) but got all kinds of cool sounds.
The detailed descriptions of the controls is really appreciated too. Thanks so much for making it available to us MM users.