Well, I mean....since you asked,
 
WHY?  Why, when I delete a softsynth, in the dialog box the "delete associated tracks" is unchecked, the program then creates a new audio track and a new MIDI track (which I always have to delete)?    ☹

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).

bvideo
Not sure they had a working bug tracker any more. There is certainly the problem reports forum for anyone to see.

surely the best place for these http://forum.cakewalk.com/Problem-Reports-f77.aspx
 

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.

Thanks everyone so far. For those who don't understand my creation of this thread, as I said it seems for now we have the attention of the developers and a quick overview of issues that drive some of us nuts I think is timely. 
Some are not bugs but user error I see already.  Please only stick to the topic of listing issues about Sonar that drive you to drink.  Even if it is user error, it's educational to see where people have difficulty using the software. I personally think that those issues are just as hindering as bugs. 

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.

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.

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.

Wow some of these are really odd. I've experienced a cople, but the resetting of plugins (touchwood) seems to have been fixed. And it was fixed, when I got a new beefy computer. Perhaps there's a link? It would be an odd one, for sure. Memory perhaps memory leaks and plugins resetting?

The issue with Sonar not remember export settings or getting stuck...that one I have, but it's not a deal breaker, because this is one of those 1st world problems lol.

I don't use a lot of those other features like lens, as someone has mentioned this as a problem. But for me Sonar has been rock solid for months. And I've been pushing the system since I got a new computer last October. I can get 60 odd tracks, 10-15 busses and aux tracks with a slew of Wave's plugs...48khz and 64bitfp and 64bitfp audio files. Best decision ever, because my old computer just couldn't cut the mustard. I still think that a lot of the problems listed here are hardware related. I could be wrong.

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