[CWBRN-40261] another bug -- Selection change, perhaps has to do with "end of song"

If you are reporting this suggest you state exact Sonar version and CWBRN. Cheers.

williamcopper
Herr Doktor: both of the recent 'bug' posts are going, appropriately as I understand, into the main sonar forum for others to agree/disagree/confirm/deny as per usual. 

In the OP all you did was write the recipe, one thing I've learned from people and applications... never assume anything...
 
As you asked so nicely I've been able to reproduce this in Platinum JP  and I agree.
 
 

Well it's certainly "confirmed" so it can be properly reported. The Bakers can decide whether is by design or if it is indeed a bug or a "Feature Request".
 
It's just this habit of willy's to constantly call everything a bug (and using the term in his thread titles which is misleading to people looking for info on Sonar) that I find inappropriate.
 
I would like to know exactly what real world procedure he is performing on a regular basis where "This hidden little bug has caused me and perhaps many others much lost time".
 
I ain't seein' it.
 
If it IS that big of an issue then I'd recommend inserting some blank tracks before going into these super important range selection procedures so if need be they are there.
 
I'll apologize to the fine forum folks for being cranky on this but I'm in a lot of pain today and these "dredger" threads make me crankier.
 
So, william... you have your confirmation. Submit a proper report.

I don't think it's a bug per se, it seems more like a consequence of what track is (or is not) selected when you insert the track. I tried to reproduce based on the steps in the OP, and could not. Eventually I found the specific circumstances under which I could reproduce it.
 
When you insert a new track, the timeline region selection changes to the clips within the selected region for whatever track is selected (i.e., track number bright blue) when you insert the new track. If you try to get around this by de-selecting a track first before defining the region, as soon as you select a region, whichever track you selected last will be selected.
 
If no track is selected, then there are no clips included in the selected region, and inserting a track will always leave the timeline region selection alone.
 
Then the question becomes how you can select a region and not have a selected track - as soon as you drag across the timeline, if no track is selected SONAR by default will do a selection, as detailed above.
 
As I don't know if this is a bug, and I don't know if will be deemed a bug and therefore need to be fixed, there's a simple workaround. (This "feels" like a "deep in the code" kind of thing as regions, selections, and tracks seem very dependent on each other. I get the sense that if you tell SONAR to select something, it feels compelled to select something.)
 
1. Create a dummy folder track.
2. After selecting a region, click on the folder track to de-select any selected tracks.
 
Now when you insert a track, the region boundaries will be preserved.
 
 

Doktor Avalanche
If you think this isn't a bug, then I can only conclude you must be arguing it is by design and is expected behaviour.

 
First of all, I'm obviously not arguing anything. And no, that's not what you can only conclude. Let's make sure we get our terms straight before continuing so you know on what I'm basing my conclusions...from technopedia:
 
A software bug is a problem causing a program to crash or produce invalid output. The problem is caused by insufficient or erroneous logic. A bug can be an error, mistake, defect or fault, which may cause failure or deviation from expected results.
 
I never said it wasn't a bug; I said it seemed like a consequence of the track selection process, which may or may not have been designed to produce this particular result, as it accrues from a combination of circumstances that may or may not have been anticipated. Or it may be following the design rules exactly, which just happens to produce this result. I don't know. 
 
There is no deviation from the expected results, because having found the relationship between track selection and changing of the region boundaries upon insertion of a new track, I can tell you what to expect any time you insert any track, under any conditions. This is why I said: (This "feels" like a "deep in the code" kind of thing as regions, selections, and tracks seem very dependent on each other. I get the sense that if you tell SONAR to select something, it feels compelled to select something.)
 

Craig this can obviously be worked around but that isn't the point here.

 
Of course it's the point! Williamcopper has found something that, bug or not (I'll leave that for argument fans to argue about) is problematic to him. I'm not capable of going into the code and determining whether it's a bug, but I am capable of researching the problem, finding out the precise cause and effect that leads to the described conditions, and offering a solution that will at least make williamcopper's life easier if he chooses to take advantage of it.
 
The point to me is solving a problem to the greatest extent possible under the circumstances. I would assume williamcopper is more interested in a partial solution than no solution at all. He may be picky and critical, but he's not irrational, and he needs to get his work done.
 
Frankly, I'm getting tired of people assuming that because I offer a workaround to solve a problem, I am negating their complaint. I am a solutions-oriented guy and have offered a temporary fix. People can choose whether or not to avail themselves of it.

williamcopper
This one has truly cost me many many many hours over the years. 

William, I hope you take my suggestion in the spirit in which it is offered...click on the dummy folder track before inserting a new track, and you won't run into the problem you describe - the region will stay however you specified. Granted, I didn't go into the code and fix it, but I would like to think trading off many hours of frustration for a one-click solution that takes a couple seconds will be helpful to you. You don't strike me as the kind of guy who would prefer to whine endlessly about wasting time if there's a way to prevent wasting that time...even if it's not a "perfect" solution.
 
Sure, it's a band-aid. Granted it would be better not to get a cut in the first place, but if you do, band-aids can be useful 

Anderton
 
 I said it seemed like a consequence of the track selection process, which may or may not have been designed to produce this particular result, as it accrues from a combination of circumstances that may or may not have been anticipated. Or it may be following the design rules exactly, which just happens to produce this result. I don't know. 

Sorry Craig but seriously what does this mean and is it relevant? .
When it comes to QA testing we simply looking at the actual  behaviour, not what people anticipate.
 
The rules here are really simple ...
 
a) Is it expected behaviour
b) Is it not expected behaviour.
 
If it is (a) then it would be deemed either by design (won't fix) or needs a feature request to fix it (will fix with enhancement).
If it is (b) then it is a bug.
 
It's pretty obvious that resetting a selection when adding a new track is not expected behaviour, unless people can list any reason at all why this is desirable behaviour and by design (if you can come up with an argument for that then you can deem it expected behaviour). Remember the behaviour is the selection gets "RESET" the behaviour isn't "Opps we didn't think of this".
 
 
You aren't looking at any other factors whatsoever (just noise otherwise).

Cheers!

williamcopper
How does it waste hours?   Some of my critics have asked, politely.    It's like this:   I have perhaps a 100 track project, mostly midi and Kontakt instruments.   Methodically, I need to select a certain section to bounce to audio: the flutes, maybe, the sopranos, the double bass: whatever.   Eventually I'm going to want to work with 8-15 audio tracks all created by bouncing.   I set a range for all the bounces.   Then I remember Sonar's other flaw with naming audio tracks: if you don't name the track BEFORE you bounce, you're screwed, the name will be hopelessly meaningless.   So I insert an audio track, name it, then go back and select the tracks wanted (thinking that what i had selected seconds before is STILL SELECTED).   Now I bounce to track (record, inaudibly, using "fast bounce",  the audio output from a software synthesizer driven by a group of midi tracks).    If I didn't notice this BUG, I'd then go out to the audio program (could be sonar, or anything) I use for merging audio tracks, pick up all the relevant tracks, and place them all so they start at the same point.   But lo and behold, they are out of sync.   THIS is the source of countless hours of mystery and frustration. 

So, you are unable to identify the newly created track you just bounced to and rename it after the fact? Should be pretty obvious which one it is (and I work in very high track count projects as well... not a problem).
 
You cannot anticipate you are going to do a multitrack bounce before you start selecting things and insert a track before hand? Simple workflow that is easy enough to get into if it's THAT big a deal. I adjust my workflow all the time to accomodate things like this.
 
This should NOT be wasting as much time as you are saying. Still... you've had the issue confirmed by multiple users and given a bunch of workarounds. All that's left is for you to make a proper problem report and leave it up to the Bakers.
 
I would also recommend not always putting "bug" in your thread titles before the matter has even been explored and discussed. It's poor form at best.
 
Good luck.

Doktor Avalanche
Sorry Craig but seriously what does this mean and is it relevant? .

 
Yes. I'm saying there a third possibility beyond bug/not bug. Notice that I have not stated with certainty that it is or is not a bug, because I don't know. I don't care. I'm interested in finding a solution, which requires quantifying the issue.
 
This is not some random thing. The results are completely and totally predictable. So while it may not have been designed to do THIS specific thing, it could have been designed to follow a specific set of rules regarding regions and selections, and it is following those rules exactly in a totally bug-free way. 
 
So, why is that important? Isn't it just semantics? I don't think so. Let me emphasize AGAIN I didn't say this wasn't a bug!! Nor did I say it was a bug. But if someone files a bug report and following the "steps to reproduce" doesn't reproduce what's described, that's a waste of time. I think my specifying that it's a consequence of a particular logic regarding tracks and selection would be far more helpful in terms of solving the problem, even if that's not the root cause, because what I presented IS reproducible and quantifiable, 100% of the time.

williamcopper
And, please, some of you.  Why do I bother to come here?   Because I use the software and I'd like it to be as good as possible (selfish); because I know how frustrating mysterious unexpected actions can be in software and I'd like to help others (altruistic); because the problem, whatever it is, has broken my concentration and I need to make some steam (childish).

I hear you, bro. Been there, done that. That's why I hope you find my workaround useful. It won't fix the software but I truly believe it will help ease your frustration.

Craig, I'm going to predict that the results are NOT "completely and totally predictable".   I've had too many odd selections.   Your lead as to ONE track selected may be right, but I'm gonna guess that with multiple tracks selected (AS THEY ALWAYS ARE IN MY MOST RECENT WORK) there's another fish in the fry.   
 
[edit] this is a guess, no more; I may have been wrong before occasionally.
 

Doktor Avalanche
Sorry Craig but seriously what does this mean and is it relevant? .

 

Anderton
Yes. I'm saying there a third possibility beyond bug/not bug. Notice that I have not stated with certainty that it is or is not a bug, because I don't know. I don't care. I'm interested in finding a solution, which requires quantifying the issue.
 
This is not some random thing. The results are completely and totally predictable. So while it may not have been designed to do THIS specific thing, it could have been designed to follow a specific set of rules regarding regions and selections, and it is following those rules exactly in a totally bug-free way. 
 
So, why is that important? Isn't it just semantics? I don't think so. Let me emphasize AGAIN I didn't say this wasn't a bug!! Nor did I say it was a bug. But if someone files a bug report and following the "steps to reproduce" doesn't reproduce what's described, that's a waste of time. I think my specifying that it's a consequence of a particular logic regarding tracks and selection would be far more helpful in terms of solving the problem, even if that's not the root cause, because what I presented IS reproducible and quantifiable, 100% of the time.

Craig obviously people need to file good steps to reproduce. That's not really what I'm addressing here...
 
This is what is important...
 
1) Are the steps reproducible? (Yes/No). Goto step (1) if not reproducible until you can reproduce or give up.
2) What is the expected behaviour?
3) What is the actual behaviour?
4) Does actual behaviour = expected behaviour. If YES then either improve it or leave it. If NO it's a bug and fix it!
 
So this points back to (2) then... What is the expected behaviour? That is the meat and potatoes of it all.
 
IS the expected behaviour when you insert a track:
(a) It inserts a track
(b) It changes the scope of what is currently selected.
 
If you can argue the case for (b) it's not a bug. I can't find any way to argue a case for that myself!!!

I don't see this as a bug at all. I think as Beepster said you should insert the track before doing anything else. When you make a selection Sonar assumes you are going to bounce to an existing track or whatever. When you then insert a new track it probably says hey wait a minute he's wanting to lay down another track. In other words if you are going to do a bounce you need to have somewhere in place to bounce it to first. There is no way Cakewalk can make a software that does everything exactly as each individual wants it to work. I would bet that inserting the track before a bounce is the expected behavior, but then again I could be wrong. I thought I was wrong once but I wasn't.

williamcopper
I KNEW there were mysteries in selection.   

This to me is of far more interest. The main things that trip me up are move to/move by, having something to snap to that I'd forgotten about so it snaps to a clip or marker that's real close to what I want, and of course, the infamous snap to audio zero crossings, which seems to default to ON. I've gotten into the habit of going into preferences and turning it off as soon as I open SONAR.