The Unofficial list of Sonar issues

1- Crashing after so many midi edits unless you keep saving
2- Setting that do not stay put and have to always be reset every time you start a new project. Example - Opening a midi file to make a new project. The  Lens is ignored and you have to re arrange your pages,
3-The export setting do not stay as you set them. Everytime you export you have to make changes. ( see# 7 )  
4-Bugs in the track templates that will randomly insert a new Master buss. I'm never sure what will be part of a saved template. 
5-Automation can make a huge mess of things and needs a complete overhaul 
6- COPY/ PASTE of even the simplest midi track results in random weirdness that cannot be explained.  
7- User preferences should be set in stone and we should not have to keep resetting settings like Comping. I don't use comping yet it keeps being reset to this and I keep having to change it back to Overdub. There are many more settings that we should be able to set in preferences once and forget. There are many setting that should be but are not included in preferences, like the Export settings.  
 

Plugins having their controls reset both when the project loads and during working on the project. Huge issue for me which was the #1 reason why I jumped ship. This was a very long standing issue with Sonar in many guises, but most recently affected Waves and Fabfilter EQ's for me. Made the program completely useless. 
 
Also horrible instability in large projects which caused the program to hang and sometimes crash when I did something as innocuous as click the playhead to another part of the project and hit play. 

Crashing

- disk overrun error appears in situation related to application memory management not really disk related for instance in such weird cases like even after finishing playing project (not recording!). It happens with very simple project like 3-4 tracks, 2x VSTi (like drums+bas). Just recording next versions of audio (even not in lanes, just delete old and start new one)
- adding more and more plugins during play often leads to hanging of Sona
- often in history there was showed not proper name of actual operation to be undo/redo
 

I sure there was mention of new code. New flagship so this post is really irrelevant.

No

dappa1
I sure there was mention of new code. New flagship so this post is really irrelevant.

 
If you read the stickies the new owners are asking for input from forum members. It doesn't hurt to ask and now is the time to make the changes. If they do base the "new DAW" on the old Sonar coding it would be a shame to carry over any bugs and quirks. 
 

Cactus Music
1- Crashing after so many midi edits unless you keep saving
2- Setting that do not stay put and have to always be reset every time you start a new project. Example - Opening a midi file to make a new project. The  Lens is ignored and you have to re arrange your pages,
3-The export setting do not stay as you set them. Everytime you export you have to make changes. ( see# 7 )  
4-Bugs in the track templates that will randomly insert a new Master buss. I'm never sure what will be part of a saved template. 
5-Automation can make a huge mess of things and needs a complete overhaul 
6- COPY/ PASTE of even the simplest midi track results in random weirdness that cannot be explained.  
7- User preferences should be set in stone and we should not have to keep resetting settings like Comping. I don't use comping yet it keeps being reset to this and I keep having to change it back to Overdub. There are many more settings that we should be able to set in preferences once and forget. There are many setting that should be but are not included in preferences, like the Export settings.  
 

I have had my pan law setting randomly changed in projects many times and it was a huge PITA as I wondered what was different about my mixes. I've also had my snap magnetic setting changed on many occasions and that's also hugely frustrating. Like plugin settings, Sonar should ALWAYS preserve settings that the user has specified. The same applies to any software program really - if it's messing with your work and your preferences without you touching it then it's a turkey.

PRV filter settings are not saved with the project.
In most of my projects, I have several instances of PRV docked in the undocked multidock, each with a different filter applied. When I open a project, the different PRV instances all look identical and display the same instrument, i.e. the one that was displayed last before the project was closed. I also have one particular screenset dedicated to midi drums. When I open it, the PRV doesn't show the drum map until I set it up again.
 
This issue is a showstopper for me. It's the main reason that I ended up reverting to an earlier release. I've been sticking with 22.11.0.111, which has fewer problems.

dappa1
With all these bugs I can see why Sonar went the way it did.

 
 
I have to be completely honest, im not sure why you haven't been banned again (along with your IP).
You seem help no one and only troll users on this forum.
 
 
 

I've not noticed this before in console view because I don't usually use instrument tracks...
 
Hiding/Showing midi tracks also hides/shows instrument tracks, there's no way to hide midi tracks and show instrument tracks (apart from hiding each individual midi track).

sharke
Plugins having their controls reset both when the project loads and during working on the project.

 
This. For me, the most annoying and steadfast offender has been UAD Ocean Way Studios.

Originally when I opened Sonar the audio engine would be running.  I could open a new project, start playing a synth, and I could hear it.
 
At some point, when I would start a new project or load an existing one, the engine would not be running.  I would load up a synth and hear nothing until I hit the play button.  I found that really irritating since every other host seemed to start up with the engine running.  This behavior only seemed to happen after four months into the membership program.

losguy

sharke
I logged bugs to do with looping misalignment that were never addressed and I suspected it had something to do with some core engine functionality that would have taken a big rewrite to fix. The looping issues have nothing to do with your interface and didn't just affect recording. Automation becomes misaligned when looping as well.

I had the same suspicion - just a feeling from seeing this sort of general behavior coming from large-scale software development projects. The term that best describes it for me is "fragile". Fragility can creep in with even the best-intended development teams. The day comes when no one team member has a full handle on the entire system architecture. It's a precarious place to be, especially if the sense of object inter-dependencies gets lost. At that point, the probability that bug fixes or (gasp) new feature additions can create new bugs in unexpected places goes up exponentially. It's also about the time that fixing those new bugs would lead to a cascaded chain of patches and band-aids that would only yield the appearance of working but really only add to the list of problems. This is the sure sign that a major cleanup task is in order. The desired goal for this exercise is to replace "fragile" with "solid".
 
Now, SONAR may only be in a mild state of this, or even be experiencing this in a few important places. But that feeling is definitely there. All that said, I have stuck with SONAR because I love the tool chain and the workflow. A reincarnation of this wonderful program that is also "solid" would really be a dream come true for me.

I think you're probably right about that. There has been more than one occasion when I've requested a simple design improvement or reported a seemingly trivial bug only to be told that it couldn't be done or that fixing it would break another part of the program. One example was when I reported that automating a ProChannel's FX Chain on/off button would not work unless the ProChannel in question was open in the console (same thing with the arpeggiator on/off button). I was told they were aware of it but had no intention of fixing it because doing so would break other things. Another example is the fact that hitting the "show automation lanes" button when no envelopes already exist automatically creates a volume envelope which takes control of the volume fader whether you want one or not,. When I suggested that hitting this button should result in an empty automation lane in this scenario, I was told that it was not possible for an automation lane to have nothing in it. These things suggest to me that the Bakers were restricted in some ways by legacy code dependencies and/or internal architecture which wasn't future proof and would require extensive rewrites to correct. If being able to automation the FX Chain on/off button would require a huge rewrite of a part of the program, it wouldn't be considered cost effective. Especially given that only a minority of users would ever want to actually do that. 
 
I'm sure much of this legacy code goes back a couple of decades, and that a lot of it is rock solid. But there must be aspects of it which weren't designed with 2018 software design in mind and replacing it would be a huge task, much like upgrading the NYC subway's ancient signal system (some of which is pre-war!). Things would have to be taken apart and put back together again, and who knows what kind of problems would ensue.

I've noticed SONAR is very addicting...can we fix that? -s