I often near the limits of the amount of RAM in my PC when composing so I often have “not enough memory” errors while loading a track or loading a VST instrument - which is quite frustrating in the long term.
Now I have the option to save memory by rendering plugins to instruments but that’s a destructive move - I lose the opportunity to use the original parameters again later.
What I’d like to see is the ability to temporarily mark memory-intensive instruments as “inactive” which would unload the instrument from memory but would not remove the plugin parameters already set so I can quickly reload them when having more memory again (e.g. because I unloaded some other instruments).
That could also help memory issues in general. E.g. if Renoise doesn’t have enough memory, it could start unloading the instruments one by one in a lazy manner (it would be a bonus if it could choose the instrument eating the most memory). So all cases could be eliminated when a track can’t be opened because of memory issues - some instruments might be inactive but the track could be loaded and I could switch inactive instruments if needed.
I’d love to see something like this and it doesn’t seem to be a particularly difficult task, at first glance. Am I wrong? (I’m a software engineer, by the way.)
I have 4GB of RAM but the problem really is that I use a 32 bit OS (Windows XP) so I can choose between having everything in one process and have a limit of around 1.5 GB or having all plugins in different processes and have a limit of around 3.1 GB. However, the latter method have considerable overhead per plugin so it’s often still not enough, especially because my problem usually is not that I use particular plugins that use a lot of memory (there are some though, e.g. Drumasonic for Kontakt) but that I tend to use a lot of different plugins, partly because I often need to use different panning for multiple simultaneous sounds from the same plugin which requires duplications as I wouldn’t like to render the plugin to an instrument, losing its flexibility.
Certainly I could switch over to a 64 bit Windows 7 but this involves quite a lot of work, reinstalling everything (and requires some money for the OS).
I thought I was not the only one struggling with such issues and hoped this could be nicely handled without too much effort but I may be wrong.
Dude, just get a 64 bit operating system or stop using huge sample libraries. It’s kind of silly to request Renoise devs to spend hundreds of hours coding and bug testing this feature request, when it would only take you a few hours and a hundred bucks to upgrade. If you can afford all those sample libraries you can certainly afford a new copy of windows?
If you don’t want to switch platforms, you could consider upgrade your memory anyway and then use VSuite ramdisk: It creates a virtual disk from the RAM section that isn’t available to Windows XP and that allows you to stuff your page-file (virtual memory) on that disk. In that way your memory will still be fully utilized without your harddrive having to work.
But eventually, it is better to upgrade to Windows 7 64 bit and i would advise you to do that now as i’m afraid that Windows 8 will perhaps be the only environment being sold which is frankly not really the environment you want to run Renoise in. (It works but Windows 8 performance is lower compared to Windows 7)
Or perhaps Windows XP 64 bit is still available on E-bay, it might save you the hassle of reinstalling most things, but when you change your CPU (which you also might need to do if you don’t have a 64-bit cpu), usually that also means reregistering a lot of plugins that rely on challenge/response codes.
Thanks for the tips!
Ramdisk is a neat trick.
You also have a good point about the availability of Windows 7 so I became quite convinced I’ll have to switch anyway…
Fortunately my CPU is quite old but already 64 bit.
It definitely wasn’t silly to ask. This is the ideas and suggestions forum, after all.
From our point of view it’s like this: Programming anything related to dynamic memory management is always a pain in the ass to deal with, and is a very easy way to potentially introduce a lot of ugly problems. Adding plugins into the mix – which are already quirky as hell and often unreliable – only serves to complicate things even further. This is quickly sounding like a recipe for disaster.
If you’re regularly hitting the limits of your system, the solution is not a clever programming trick to avoid the limits. This will only delay the problem itself, and you’ll eventually hit another limit somewhere down the line. So in my honest opinion, creating such a plugin/memory management system in Renoise is simply not the answer.
The memory limit in Windows 32-bit sucks. The move to Windows 64-bit and re-installing all of your stuff also sucks, but it’s a necessary evil, and a fact of life we all have to deal with at some point. Simply switching to 64-bit alone will improve your entire experience by unlocking the rest of your available RAM. Upgrading to 8GB RAM or more will also be a huge step up, if you can afford it.
Overall, it’s an investment you must make to continue doing something you love.
I wonder if you’re aware of using plugin aliases in Renoise?
Aliases can be a very effective method of reducing memory usage, especially when dealing with large sample libraries in something like Kontakt. Instead of using 4 separate copies of Kontakt that are all playing the same sound with slightly different settings, you can use 1 instance of Kontakt instead, with 3 aliases linked to it. Duplicate your sound within Kontakt itself, setting each copy to output on a different channel, and then set each of your aliases in Renoise to use that channel. This way you only need the memory for one instance of Kontakt, not four.
As a software engineer, I know about the potential issues but I also have a vision of how those could be safely solved. Though, I don’t have experience with programming VST plugins so I could well miss some issues there. I also perfectly understand your fear for introducing unreliability, I’m absolutely satisfied with the current stability of Renoise. It even handles memory issues quite well, I just hoped that perfect flexibility/robustness is not very far from here.
Fair enough, I’ll invest in that.
The only point I disagree with that it’s only a programming trick. I see “plugin unloading without removal” a natural feature as part of an “intelligent freeze”, combining the configurability of VST plugins and the light-weightedness of Renoise instruments. So when one needs quick loading times, less memory usage, better CPU performance or tweaks for individual notes, they could be used as instruments (while the plugin is unloaded) but when configurabilty is needed, they could be still loaded back and used as plugins temporarily. I understand, though, that less memory usage and quicker loading are the only real benefits as the others could already be done without unloading the plugin - it just seems a waste of resources not to be able to temporarily unload them while they are not used.
But if this were possible, one could more easily avoid out of memory issues even without Renoise automatically picking plugins and unloading them.
I’ve been aware of this but I probably use it in fewer situations than I could so thanks for noting it!
Plugins have two things in memory:Their internal environment and the parameters that are required to send to them. Specially the memory hogg plugins (samplers) send massive amount of datachunks in their parameters as well.
When unloading the plugin, you still end up with a lot of parameter data in memory that has to be stored somewhere on disk in that case. Problem two will be to get this stuff stored into songfiles when you want to save your song. If stuff is fully unloaded and swapped to disk, it must be loaded back into memory again to get your song saved at least (and reloading back the plugin). Which costs a lot more time than it would cost if everything was already in memory. And if memory lacks because you added other components meanwhile that would not supposed to be around at first, you might not even be able to save your song.
Your idea makes it complicated for the Devs to realise and for users to keep track of what they are doing, because for such a feature you must be fully aware what you are doing and what the feature is doing.
Renoise is already complicated in the form it is now and such ideas only add to the complication but do not really add to value.
I think only those parameters are worth being kept in memory that are also saved with the songfile. From my experience, these usually don’t take much space as I haven’t seen any xrns files being that large unless they contained flac sample data. Even for a plugin consuming 200MB of RAM, I expect the parameters usually take <5MB. I didn’t think of anything more complex like swapping the parameter data to disk.
I have a feeling that you think of something more complicated than I do.
I can boil it down to the following changes:
An Unload/Reload button for plugins. The implementation of Unload would do the same as Clear but would keep the plugin parameters in memory. So the saving process should be the same. The implementation of Reload would be the same as when the song is loaded. I guess it’s done by loading the parameter data into memory first and then initializing the plugin with it as input. Reload would simply skip the first part as the data is already in memory.
Unloaded plugins should be marked somehow beside their name and they would mostly behave the same as when they can’t be loaded (e.g. when the plugin dll is not found) so not much to implement here, as well. The Reload button would change the user interface the same way as when a new instrument is loaded instead of the current one (if loading it was successful - but if not, a popup window could tell the user so and the plugin would remain the same as before). (By the way, the Reload button could also work for plugins that couldn’t be loaded earlier so the handling can be common also there and would give an extra feature.)
Render to Instrument feature would also have an option to unload the source plugin, not just an option of removing it. When selected, this would do the same as if it was done manually with the Unload button.
+1. When handling memory issues, Renoise could check the list of plugins and automatically unload them (using the same function as manual unload) until there’s enough memory so it doesn’t fail when loading a songfile.
Unless I miss some issues, I don’t think it’s that complicated, almost everything has already been done. That’s why I durst mentioning it.
I agree that there might be a communication issue here. But as a user, I would have expected such a workflow for a “freeze”/“render to instrument” feature in the first place. I may be in minority, though, and most users could go “what the hell is the difference between Delete, Clear and Unload”. Perhaps it could be handled with more concise, descriptive names.
I agree that there’s a delicate balance here and the above could be on the boundary or even worse. Certainly it’s not worth if I’m the only one who thinks this would be cool.
Observe, there are many Renoise users who are currently waiting for 3.0 and hoping that their high-end machines will have to work hard because of new cool features that push technology forwards. Imagine an alternative universe in which taktik or dblue actually replied to your feature suggestion:
“That’s a good idea! We will spend a few hundred hours on this, sorry folks - the beta has to wait a bit longer until we’ve solved this”
Just upgrade your machine, install some 24 GB of RAM, some SSD’s for the sample-based VST libraries, and go x64. It’s totally worth it. />
I got a question that’s somewhat related to the OP.
I’ve noticed that the first time I load a VST (e.g. EastWest’s Stormdrum), it takes some time for the instrument to load.
If I then quit Renoise for a time, without shutting down my PC, and then open Renoise again, and load the previous VST, it’s getting loaded super-fast.
I presume that the VST is saved somewhere in my cache, and as far as I can see it stays there, no matter what I do in the meantime (e.g. play games/watch movies). As long as I don’t reboot my PC the VST is loaded very quickly when I open it again.
So my question is this… Is the VST saved in my cache? And if so, I assume it will affect my PC’s performance. Is there any way to remove the VST from the cache when I quit Renoise?
Yes, this is a native behavior of Windows - any file would stay in memory as long as windows wants. This is normal and in most cases even good behavior. But if you work with many files which need only ones per session (for example Reason session) and after all you not want it than this cache behavior start to bring problems with memory management.
Also there is free utility for manual cache freeing — CacheSet - Sysinternals | Microsoft Learn
After good fat session with much samples and etc it would be good to press RESET — and no need to reboot system!!! =)
/>