I’m playing around with Polyverse’s Manipulator plugin in my open source looper which of course uses JUCE. It actually all works quite well, the JUCE API for creating plugin instances is nice and simple.
But when running a release x64 build under Visual Studio 2019, I see that each instance of the Manipulator plugin I create consumes 250MB or so of heap. One of the goals of my looper is to make it easy to instantiate as many plugins as you like, but at a quarter gig per instance my RAM alone isn’t going to hold out, never mind the CPU.
Is this kind of RAM usage fairly common these days with modern VST and other audio plugins? I am thinking I will have to optimize for few instantiated plugins, recording the plugin output audio and looping that… which is too bad as I had been hoping I could just let the live plugins do it. But recording the post-plugin audio will save a lot of CPU as well, so perhaps I should just suck it up…
Curious what the best practices are around managing the memory usage of many loaded plugins. Thanks!
If a plugin consumes a lot of memory (or CPU) there isn’t really much you can do as the host application, apart from allowing to offline render the plugin’s processing into a new file and then unloading the plugin. (This is often called “freezing” in hosts.) The caveat is that sometimes plugins don’t release their memory allocations fully even if you destroy the plugin instance.
You can also do what you mentioned : allow recording live to a new file or memory buffer with the plugin’s processing applied.
250 megabytes per instance sounds quite high. Have you been in contact with the plugin developer and asked if they consider that “normal”?
Yes, I have contacted the plugin developer and hopefully will hear back. For now I will use this plugin only on the inputs, and not allow creating extra instances of it on already-existent loops.
If people have suggestions for good low-latency low-memory-footprint VST2 or VST3 plugins suitable for vocal-centric performance, I would love any and all suggestions. (Takes the thread slightly off topic, but only slightly.)