AntManB
Does the fact that the load balancing is optional imply that there may be some circumstances/hardware where it is best left disabled?  If so, when?
 
AMB
 

 
This is explained in detail in the help here.

I've installed the update a few hours ago and I am getting pops and clicks on all my projects.
Never had this before. I checked all my audio settings to make sure nothing was changed.
I have not enabled the new core balancing.
 
Anyone else experienced this after the update?

slyman
I've installed the update a few hours ago and I am getting pops and clicks on all my projects.
Never had this before. I checked all my audio settings to make sure nothing was changed.
I have not enabled the new core balancing.
 
Anyone else experienced this after the update?

I have a very large project (100 minutes in length and 32 tracks), and the update seems to have coincided with more dropouts than I experienced before (which were few and far between).

I tried enabling the new load balancing option but it could not play more than a second before a dropout occurred so I switched that off again and it's better now.

UPDATE:  
I should have mentioned that I was originally running 2016.07 and jumped to the pre-release 2016.09 (skipping 2016.08).  I have gone back and forth between 2016.07 and 2016.09 and they both seem to play about the same (i.e. with minimal dropouts).  However, if I enable the new feature load-balancing in 2016.09 (pre-release) then I have issues.  Note that my project is probably very much an edge case given the size of it, but I am providing info to Cakewalk to learn more


 

Noel Borthwick [Cakewalk]

outland144k
Here's a strange thing: with load balancing enabled, the first thread is getting very little of the load, but the seven remaining threads are looking pretty even in handling the remainder. Thoughts?
 
Originally, the first thread was running about 20% higher than the remaining seven threads. All told, I thought this was pretty even, but now, the load seems to be avoiding the first thread.

In Load balancing mode if you are using the "audio processing load" cpu metering mode, the per core meters only tell only a part of the story so you can't take it too literally. Every core is indeed being used for processing. We may try and improve the display accuracy but it got very complex to represent with the new model where now every FX rack is potentially being load balanced.
 
If you want an accurate picture of what is going on from the OS point of view, watch the CPU metering mode (right click on the meters) to show the system load. In that mode keep in mind that it shows the use of your cores for ALL concurrent processes on your PC not just SONAR. Arguably that is a better metric to watch since it tells you exactly how the cores are utilized globally.

 
Thanks, Noel. This is a great new feature and, as I've mentioned, might help me get more life out of my current somewhat aging system.
 
BTW, all things being equal, what is better for Sonar: a higher CPU speed or more cores? Where is the trade-off? I've got a i7 2600K quad OC'ed to 4.5 gHz, thinking of putting an i7 oct (not sure about OC'ing on that yet). I've got 16 GB RAM now, but will go to at least 32 GB and maybe 64 GB.
 
Also, is there a projection as to when the Robin's Egg Blue for the plug-in "screen" in the FX rack will be editable in Theme Editor? I'm just looking forward to matching it to the rest of my themes.
 
Thanks as always for all your work, comments, and help! I can't express how much I appreciate where Sonar has gone and seems to be headed.
 
 
 
 

The 8 physical core I7's (16 virtual cores) are amazing. Definitely recommond those. More cores over a marginal CPU speed increase is definitely preferable for a multiprocessor capable app since it allows the app to scale load better.
 
More theme editor changes are slated for a later release. Not sure yet when it will make it but you should send in a feature request.

Noel Borthwick [Cakewalk]
The 8 physical core I7's (16 virtual cores) are amazing. Definitely recommend those. More cores over a marginal CPU speed increase is definitely preferable for a multiprocessor capable app since it allows the app to scale load better.
 
More theme editor changes are slated for a later release. Not sure yet when it will make it but you should send in a feature request.

Thanks for the suggestion on the cores. Of course, since I probably won't be able to build until about a year from now, 8 (physical) cores will probably be considered all but obsolescent by them and 16 cores will be "a more sensible, yet forward-looking option" (he said in his best imitation of a Welsh accent).
 
Is the difference between 3.2 and 4.5 gHz considered "marginal?" I ask this seriously. Wow.
 
I just posted my suggestion regarding plug-in screen color editing as a feature request. Thanks for reminding me.

outland144k
 
[font="'book antiqua', palatino; color: #003366; font-size: small"]Is the difference between 3.2 and 4.5 gHz considered "marginal?" I ask this seriously. Wow.
 

Analogies always suck, but I'll give it a try: You'll get a job done faster with 16 highly skilled workers working 3.2 hours a day compared to 4 highly skilled workers working 4.5 hours a day. The four will have more throughput on a given day, but that won't get the project done faster.
 

Anderton

outland144k
 
[font="'book antiqua', palatino; color: #003366; font-size: small"]Is the difference between 3.2 and 4.5 gHz considered "marginal?" I ask this seriously. Wow.
 

Analogies always suck, but I'll give it a try: You'll get a job done faster with 16 highly skilled workers working 3.2 hours a day compared to 4 highly skilled workers working 4.5 hours a day. The four will have more throughput on a given day, but that won't get the project done faster.
 

Oh, I get this (and I liked your analogy, except that I thought that the relationship between differing clock speeds was exponential, not linear [?]), my question was just about 3.2 gHz vs. 4.5 gHz on a one to one basis. I'm sorry if I wasn't clear about this. I didn't think that 4 physical cores could do the work of 8 or 16 physical cores, per se. 
 
So, a difference of 1.3 gHz (assuming equal number of cores for this issue) per core is a marginal difference. That's kind of scary.

outland144k
 
 
Is the difference between 3.2 and 4.5 gHz considered "marginal?" I ask this seriously. Wow.
 

 
You didn't mention what the CPU jump was in your earlier post or I missed it. 3.2 to 4.5 GHz is a pretty big jump so thats a tougher call to make. So for raw DSP processing and low latency performance you will generally get more out of the 4.5 GHz processor, but smoother performance from large projects with more cores. 
 

Bristol_Jonesey
Not had a chance to download & install yet, but does anyone know if there's been a fix for selecting multiple envelopes in one go?
 
This got broken in 08

Hi Bristol_Jonesey,
 
 I just PM'd you for more info.
 
Thanks,
Jim