That is interesting in that having a ton of tracks in a project even if they are blank or empty causes performance problems.  I had the same issue years ago (and many told me that they hadn't seen it) when I was using template tracks with KONTAKT... each version of KONTAKT I loaded would load its 32 audio tracks as part of the KONTAKT profile.  Performance was terrible... but when I deleted the unused tracks, my performance would improve tremendously.
 
I have sense knocked down my KONTAKT default load to only 8 tracks per instance of KONTAKT and have NEVER experienced the performance LAGs as I did yesteryear.
 
I do think there is something to projects and resource consumption of unused tracks that SONAR doesn't like, even though the bakers told me otherwise.
 
Jim

Maestro6
SOLVED! (Workaround): I wanted to update all of you that after I shared my templates with Cakewalk and they had the same issues at their end as well with my templates. (works fine on Hopkinton but not on Ipswich). They suggested me two things and solved both the problems. Here they are:
 
1. Opening a project/template takes long time. - Solution: (This was simple and something I didn't try before) Just save it as a new version again on Ipswich and next time it opens up in normal speed.
 
2. Performance problem. - Solution: In preferences-->Project-->Record-->"Allow Arm Changes During Playback/Record" has to be disabled. That fixed the problem. Looks like this has some sort of CPU hit on the computer with the new real-time direct instrument track recording feature that was introduced with Ipswich I believe. I do like the "Arming tracks" during playback/record function normally, so would love to be able to enable this without having performance issues.

Thank You!
1. Yes, it works.
2. Disabling it gives huge improvement to CPU performance, but it seems that it is still slightly worse than in previous version, but maybe I'm wrong. Definitely this arming feature should be fixed if possible.

"Allow arm changes during record" aka dynamic arming, will always incur a performance hit. The reason is when you do this essentially every track with always has to be in a permanent "record ready" state - IOW it is processing input even through it may not be actually recording it. In the past this only applied to tracks with hardware inputs. Now with real time synth recording the same applies to all tracks with synth inputs. So if you have a lot of tracks with synth inputs its expected that there would be an extra performance hit.
I will be investigating why it makes a difference if you resave the project but I just wanted to point out that some performance hit is inevitable. If your system can't keep up with it I suggest only enabling dynamic arm when you actually need to use the feature - ie tracking.

Resaving is not a problem because you will do it anyway at some point, but maybe it worth mentioning somewhere that the project structure have changed and it need to be resaved to improve loading time. But if it could be solved, it would be good.
If dynamic arming cause so big CPU difference maybe it makes sense to split this option for hardware and software sources.
Also 99% using this option I don't really need to record immediately after arming. For example I listen to my track from beginning, and at some point I understand that I want to record guitar. I don't want to stop playing right at this moment, but I want immediately arm track, or add new track and arm it. And if arm button is completely disabled it is really frustrating. I need to arm it, but I won't press record button right at this moment, I will listen some more, and then stop and begin to record from begging. And this is 99% of my using of dynamic arming really. So if there would be option that just allow to switch on arm for future recording after stop, I will be happy with it.

Noel Borthwick [Cakewalk]
"Allow arm changes during record" aka dynamic arming, will always incur a performance hit. The reason is when you do this essentially every track with always has to be in a permanent "record ready" state - IOW it is processing input even through it may not be actually recording it. In the past this only applied to tracks with hardware inputs. Now with real time synth recording the same applies to all tracks with synth inputs. So if you have a lot of tracks with synth inputs its expected that there would be an extra performance hit.
I will be investigating why it makes a difference if you resave the project but I just wanted to point out that some performance hit is inevitable. If your system can't keep up with it I suggest only enabling dynamic arm when you actually need to use the feature - ie tracking.

Hi Noel, improvements will be welcome here. Also is there a way to have a button on the control bar for "Allow arm changes during record" so that can be turned on/off - on the fly?

Cheers..

Doktor Avalanche
Also is there a way to have a button on the control bar for "Allow arm changes during record" so that can be turned on/off - on the fly?

How would it help if you will have dropout after turn it on? And if you have enough CPU room you don't need to turn it off.

Doktor Avalanche
Also is there a way to have a button on the control bar for "Allow arm changes during record" so that can be turned on/off - on the fly?

 

Adq
How would it help if you will have dropout after turn it on? And if you have enough CPU room you don't need to turn it off.

CPU levels fluctuate all the time, projects are different, it isn't a black or white scenario.


It probably won't help people who experience dropouts all the time (they should just leave it disabled), but it will save CPU time for those who do use the facility without issue. I don't use arm record much on the fly during playback, but I may very occasionally. Having monitoring continuously on is a waste of CPU time at least in my scenario, the ability to quickly flip on/off this monitoring whilst the transport is playing would be extremely handy. 

Is it possible to add the command to the custom CCC module?