IMHO, Dumb User Mistake Should be Caught by Sonar X3

Okay, this is one of those things that might happen to anyone while working in haste with take lanes. After splitting up a take into several bits (for the purposes of treating those bits with differing effects) I grabbed some of those bits and drag (heading for a new track) and my finger slipped off the mouse button while my selection was moving over top of the take lanes' "master" track.
 
Result: hard crash.
 
Yes, this is something I would normally NOT do. I didn't set out to do it, but when it happens, I would expect any software to be a bit more forgiving and handle this type of situation. Either automatically add a new take lane (same behavior as dragging an audio file from Windows Explorer into a blank area of Sonar) OR throw up a dialog saying, "You can't do that! Stop it right now!" and then patiently wait for me to screw my brain back on straight and try again.
Know what I mean?
 
Just in case in needs to be said...
I really am very grateful for Sonar X3. It's by far the most well-though-out software I've used since about 1989. I've tried very hard not to complain about the little foibles I've encountered and will continue to make the effort.
 
The above statement of complaint was made in the spirit of doing my bit to make Sonar an ever-better application.
Thanks for reading.

> a hard crash means something occurred that the bakers hadn't foreseen and the program doesn't know what to do

Exactly (assuming it isn't drivers or plugins that is the cause), so you need to log an issue if you are able to reproduce the exact steps every time as it is hard for anybody to test every single scenario, it would be nice if you could please post the issue number here. cheers:
http://www.cakewalk.com/support/contact/problemreport.aspx
 

Yanno... I never really thought about it in those terms before but yeah... a popup/warning of an illegal function would be better than a hard crash and losing the work. I wouldn't even mind crashes so much if it didn't sometimes totally wipe my progress to BEFORE my last saves. Like say I'm diligently hitting the save button and experience a crash when I reopen those saves don't show up. Even if a do a Save As without closing and reopening the project I can't return to that point (but sometimes I can reopen the project but not through the "Open" dialog which I leave on because it won't show up on the list. I have to close the dialog and use File > Open then find the Save As version).
 
I get very few hard crashes though and many times it's because I'm doing something too quickly or being a dumbass but still it's a pain.
 
The only downside though to the convenience of Sonar just not allowing the program to crash and providing a popup is that they would get far less problem reports and not be able to fix those issues. I'm assuming that type of thing might be a pain to embed into the program too and might cause other issues. Frankly things seem to be reasonably stable for the moment so the less fiddling around with the core guts the better. I'm mildly concerned about what the new video features will do but I'm going on the premise that we already have two stable builds to fall back on each of which have very specific problems that are known so in the rare eventuality one of those issues pop up on a user rolling back or updating to the other should get the user to a workable build.
 
The BIG tests for me with X3 are going to be editing a large project and doing multi track time correction/stretching with audiosnap. If those two things work (and I guess in the case of audiosnap if it just works BETTER) then I'll be a happy beep. I've done a bit of tracking and already some of my problems there are gone. Mixing has never really been a problem as far as crashes and bugs in X2 unless I don't have my hardware settings right. I did not experience any significant problems or glitches mixing Beeps Creep in X2.

Maybe it's me, but I don't consider something like that a bug. To me a bug has to be something that goes awry as part or normal operating process. When one does excatly what they were intending to do and get errors,crashes, malfunctions, etc. The OP clearly stated he mad a mistake and his concern was that Sonar should handle such user errors more elegantly.  I happen to agree with the OP but would hardly consider this a bug.

In the world of software anything that causes a crash is a bug. However in the world of software it could be argued that it is a rare use case and would be minor priority (although I personally would disagree with this as any stability issue is a major IMHO).
 
Although if the steps turned out to be not reproducible then the bug would just be closed or more info would be required. Either way a bug report would need to be created in order for it to get in front of a member of the QA team.

CakeAlexS
In the world of software anything that causes a crash is a bug. However in the world of software it could be argued that it is a rare use case and would be minor priority (although I personally would disagree with this as any stability issue is a major IMHO).
 
Although if the steps turned out to be not reproducible then the bug would just be closed or more info would be required. Either way a bug report would need to be created in order for it to get in front of a member of the QA team.

Well... I'm not a code talkin' dude but the term "bug" comes from the old analog tube and circuit computing days when actual insects would get into the electronics and fry things out screwing up operations. My understanding is that in the software realm the "bug" is an improperly placed/written or missing piece of code. So if the function is one that isn't intended usage can it really be considered a bug?
 
Seriously I don't know. Werds are funny thingz. ;-)

Regardless of how you want to define the term "Bug", I think your average programmer would consider any error that is not properly trapped causing a crash to be highly undesirable, and would accept responsibility for handling it as a programming problem even if it was precipitated by an inadvertent/unanticipated/unsupported action of the user. By this time, there are probably thousands of such actions that have been identified (whether anticipated by programmers or reported by testers or users) and handled.
 
But this one needs a better recipe, because it's clearly not as simple as just dropping any selection of clips from lanes on the parent track in any project.

@Sanderxpander - regarding your following quote: " a hard crash means something occurred that the bakers hadn't foreseen and the program doesn't know what to do"
 
I respectfully disagree on your conclusion on hard crashes being necessarily the fault of Sonar.  There are many many reasons for crashes, including background services, hardware issues, BIOS issues, device drivers, device firmware, Windows issues, antivirus software, other conflicting applications, settings mismatches between audio interfaces and Sonar, plugging an audio interface meant for USB 2 into a USB 3 port, some 32-bit plugins freaking out in a 64-bit Sonar environment, errant user 'tweaking' of the system, etc.
 
Just because Sonar is running does not mean that at any particular time it has control - many times crashes occur with 32-bit plugins in control in a 64-bit Sonar, for example.
 
This of course does not mean to suggest that there are not crashes that occur that ARE caused by Sonar - and that is not what I was trying to say - I am just pointing out that there a great many additional reasons crashes occur than solely caused by Sonar.
 
Bob Bone
 

robert_e_bone
@Sanderxpander - regarding your following quote: " a hard crash means something occurred that the bakers hadn't foreseen and the program doesn't know what to do"
 
I respectfully disagree on your conclusion on hard crashes being necessarily the fault of Sonar.  There are many many reasons for crashes, including background services, hardware issues, BIOS issues, device drivers, device firmware, Windows issues, antivirus software, other conflicting applications, settings mismatches between audio interfaces and Sonar, plugging an audio interface meant for USB 2 into a USB 3 port, some 32-bit plugins freaking out in a 64-bit Sonar environment, errant user 'tweaking' of the system, etc.
 
Just because Sonar is running does not mean that at any particular time it has control - many times crashes occur with 32-bit plugins in control in a 64-bit Sonar, for example.
 
This of course does not mean to suggest that there are not crashes that occur that ARE caused by Sonar - and that is not what I was trying to say - I am just pointing out that there a great many additional reasons crashes occur than solely caused by Sonar.
 
Bob Bone
 

Sweeping generalizations are always wrong. :)
I agree with you that there are many places errors can occur. That doesn't mean Sonar shouldn't be able to deal with these a little better. It isn't the soundcard driver crashing even if it does tell Sonar something unexpected, it isn't Windows hanging, it isn't toasted RAM. I don't think 32-bit plugs should be able to crash any version of Sonar to be honest. Not work, sure, but crashing, no.
Perhaps these are very unrealistic demands for such a complicated program with so many features. But generally speaking (here we go again) I have seen a little too many random things crashing Sonar on my system while Ableton both (8 and 9) has been solid as a rock with the same plugs and soundcard.

> Perhaps these are very unrealistic demands for such a complicated program with so many features
 
If everybody managed to trace the bug so they could reproduce the error on demand, wrote down the steps exactly and threw it into Cake problem reporter then no, not unrealistic at all.

However ultimately I don't think it's the responsibility of the end user to meticulously trace bugs. That's the responsibility of the developers or, possibly, the beta testers.
 
You mean QA. Responsibility or not, if you cannot reproduce it again, the chances of somebody else reproducing it will be extremely hard and time consuming. When Sonar crosses threads with itself it is extremely difficult to reproduce, and issues with third party software or drivers are impossible to reproduce. Only a certain amount of time will be spent on testing until a wild goose chase is declared.
 
Hence the reason why you still have the bug. Responsibility or otherwise that is the reality.
Didn't you know you are the beta tester?

This is getting pretty banal. Once again you seem to disagree with something I'm not saying.
And in turn, you seem say it's fine if people charge money for unstable software and wait for the user to point out problems?

I'm out, you can count yourself one up again.

@Sander What exactly were you saying then? You stated it was the developers etc responsibility to trace bugs and I disagreed, I stated it is in fact the users as it's almost impossible for s/w companies QA dept to trace particular bugs, and to be honest it should be a team effort.
 
I didn't mean to annoy you, you are entitled to your opinion as I am to mine. Nobody said you were stupid or anything, aren't we able to debate things here or show our opinions?
 
In what way does a difference of opinion become an argument unless there is some fact getting in the way?

And let's be more specific here:
 
> And in turn, you seem say it's fine if people charge money for unstable software and wait for the user to point out problems?
 
All software is unstable and full of bugs. It may not be fine but it is the norm.

Again I'm sorry if you perceive this as an argument. I guess you are an idealist and I'm a realist here. As an idealist I'm prepared to accept what you say, sadly it's not going to happen the other way around... I'm sorry you took it personally.