rogeriodec
In my orchestra template, where I use many instances of Kontakt, in addition to multiple instances of Virtual Sound Stage, in addition to buses with Altiverb, Ozone, etc, this also takes several seconds to completely unload.
It seems that the download time is proportional to the amount of RAM used.
But this delay is inexplicable, because if I kill the Sonar.exe process directly in the Windows Task Manager, it releases the RAM immediately, without any problem for Windows, nor for the project ...

That's exactly what I see. I think it's just doing some kind of "RAM housekeeping" or something, because everything is fine - even after killing the process.
Also - if you close SONAR, and switch off the computer (or reboot) before it "finishes" - it's also still fine.
 
I never considered this to be a problem - just a PIA sometimes when you want to close a file and open another one quickly ;-)

So, if we all agree that there is no problem in closing a project in a radical way as in the case of simply killing the whole process in task manager, I think this could become a formal request to bakers, what do you think?

Walt,
With the amount of plug ins on each track you have, are you using "Plug in load balancing" ?
Try doing a test by disabling it/or enable it and try your tests again.
 
With 5 plug ins per track, this sounds like a great candidate for load balancing.
 
In my projects I use a good amount of tracks (between 35-50) and quite a bit of plug ins and I don't see a big difference in time duration when closing large projects and smaller ones. a few seconds at best.
Im, not seeing any RAM being unloaded.  I have however, seen devices that hold my system hostage until they feel like letting go. This can be an audio device or a midi controller.
 
You can try removing all your devices and doing the same tests.
Also a bit of advise, if you are using 5 plug ins per track on multiple tracks, you may want to consider busing/routing options.
 

rogeriodec
In my orchestra template, where I use many instances of Kontakt, in addition to multiple instances of Virtual Sound Stage, in addition to buses with Altiverb, Ozone, etc, this also takes several seconds to completely unload.
It seems that the unload time is proportional to the amount of RAM used.
But this delay is inexplicable, because if I kill the Sonar.exe process directly in the Windows Task Manager, it releases the RAM immediately, without any problem for Windows, nor for the project ...

That can be inducted by modern programming... Most plug-ins are written in C++. In the approach driven by its ground ideology, freeing RAM resources was the problem from the beginning. When computers was really slow, the effect was so obvious that everyone was carefully checking why program exit takes so long and eliminating that effect (there are several methods for that). But these days developers prefer advise users just get faster computer.
 
Probably some plug-ins are worse then other in that respect. Identifying such plug-ins  and begging for the "fix" has some chance to be noticed, but not a big chance.
 
When the program just use the whole memory (and long time ago) or asked to be freed at once (as during process killing today), individual "objects" do not have to be freed separately. But when a project is closed, all plug-ins are working as a part of Sonar. So Sonar can not "kill" all plug-ins at once without killing itself, it asks all plug-ins to exit gracefully. Plug-ins can use huge data structures, composed from individual (logically) elements. C++ compiler tries its best to aggregate standard data structures such a way that freeing single elements is not required when the whole structure should be freed. But as I have mentioned before, C++ ideology is strictly opposite, each individual element in any structure is an "object" with individual methods to do everything, including destroying. As the result, the "optimization" methods used in C++ (particularly in STL and other template based libraries) are based on rather tricky, hard to understand, not nice looking, error prone and not "object oriented" methods. For programmer, it is rather simple to write something which is technically correct, does what it should, produce no errors or warnings but silently prevent these optimizations. There is no good debugging/tracing/profiling tools to show such cases to the developer (at least I do not know such tools, and I periodically checking for them...).

azslow3
Probably some plug-ins are worse then other in that respect. Identifying such plug-ins  and begging for the "fix" has some chance to be noticed, but not a big chance.

+1

chuckebaby
Walt,
With the amount of plug ins on each track you have, are you using "Plug in load balancing" ?
Try doing a test by disabling it/or enable it and try your tests again.
 
With 5 plug ins per track, this sounds like a great candidate for load balancing.
 

Thanks Chuck. I'll take a look at "Plug in load balancing".

chuckebaby 
Also a bit of advise, if you are using 5 plug ins per track on multiple tracks, you may want to consider busing/routing options.

I do that on tracks that use doubling and/or multiple instruments of the same type (i.e. several trumpets), but most of my tracks are individual unique instruments that need their own parameters in the plug-ins.
 
Walt

WallyG

chuckebaby 
Also a bit of advise, if you are using 5 plug ins per track on multiple tracks, you may want to consider busing/routing options.

I do that on tracks that use doubling and/or multiple instruments of the same type (i.e. several trumpets), but most of my tracks are individual unique instruments that need their own parameters in the plug-ins.

im no one to question others but A limiter on every track ?
Just seem like a bit of over kill. Ozone plug ins suck up resources big time (im sure you know that).
I Would look at load balancing though ASAP.

chuckebaby
...im no one to question others but A limiter on every track ?...

 
It's in one of my track templates that I use quite a bit. If I don't use it I delete it. About 60% of my tracks are acoustic instruments/vocals. I mostly use the limiters on the acoustic stuff.

chuckebaby
 
I Would look at load balancing though ASAP.

I just tried it on one project and it didn't make any difference on the closing times. I had looked a Load Balancing when it first came out but since I was not really experiencing a audio drop outs, I decided not to use it since by itself, it uses up resources.
 
Walt