jatoth

Beepster
 
Seriously, based on ALL the "evidence" posted by the OP (which we had to pry out of him) the ONLY problem is that bouncing to the new track (which solves this entire "issue" completely) is that bouncing to a NEW track doesn't name the clip how he likes.
 

Beeps, have you tried working with 100s of bounced files in the project folder with the auto generated names?
I can totally see the OPs point. Not being able to see his point, and dissing the OP is NOT helpful to anyone.
But, as you said, you are not feeling very well today, so you get a pass. Maybe it's time for a chill pill.
 

No, really I don't (and today is a new day... I'm feeling better and still annoyed). I let 99.9% of things like this slide but OP does this ALL the time.
 
I do MANY bounces... like dozens at a time of various kinds and I get by fine. I know exactly what OP is trying to do and claiming the problem is.
 
This is a very minor workflow adjustment to get EXACTLY what he wants. These CONSTANT complaints over non issues (and seriously I am not entirely convinced this is not outright trolling or corporate sabotage) takes away from LEGITMATE issues that need addressing. That's why I have, in this case, thrown out my chill pills. I need automation to work better. Other folks need other urgent improvements for their workflows. This, and many other of willies (and possibly his alt's) threads are fluff that distract the Baker's from their work and the TRULY altruistic forum members from providing help to people who really need it.
 
Seriously... I freaking automation fixed. Others want drum maps fixed, Staff View fixed, colors more flexible... etc. Those are REAL problems. This is not an issue. OP needs to set up a bounce track BEFOREHAND or take the 5 seconds to rename his clips after he bounces.
 
Are you seeing NOW why this behavior ticks me off?
 
The hilarious part is I'll likely be the one getting a polite message to cool my jets from the mods over this so I'll move on to actually working (relatively smoothly) on my current project.
 
Peace.

Beepster
 
Are you seeing NOW why this behavior ticks me off?
 

 
No, I don't see it. I LOVE Sonar. But, I am also totally aware that there are MANY such issues with Sonar. Things that got overlooked when adding this or changing that. ALL of these issues should be addressed. Otherwise OUR software will keep having these "little" annoyances, which cause a brand new user to sit and scratch his head. Sure, many of us have been with Sonar for years so we know of many of these idiosyncrasies and have found or developed "workarounds".  But, that does NOT make Sonar the "best" DAW out there.
I'm calling for a "new feature" moratorium. Let's just get ALL the existing features working correctly. IMHO, that will make Sonar the "best", most friendly, intuitive DAW on the market.
 
Really? Flexible colors are more important? We ALL have our pet peeves that we want fixed don't we?
 

Adq
Beepster, you are wrong. Disregarding others needs and wishes, you discredit the idea of fixing this "poor designs" and improving workflow. Yes, everybody need different things, but if everybody will argue that others' suggestions are stupid and should not be reviewed, it will be worse for all. It is already the fact that developers prefer to implement new features in marketing goals, and if there would not be consensus that current features should be improved and cleared of this strange and annoying bugs, in every part of program, it would be hard for Sonar to became really much better. Also this small and minor bugs need much less time to fix.

Nonsense. You know full well I support any and all legitimate requests for advice and help and even the non legitmate ones in the interest of offering suggestions for anyone searching for solutions but stumbled across those illegitmate threads.
 
Don't address me again. I ignore you for a reason and it ties into EXACTLY what I am referring to here.
 

jatoth
Really? Flexible colors are more important? We ALL have our pet peeves that we want fixed don't we?
 

Considering the MOUNTAINS of requests we get for it (including from people who are visually impaired because that's the ONLY way they can work) and the fact the is a very real ceiling to what can be done with color schemes as of now (compared to previous incarnations of the program that may have been an important factor to many devoted Sonar users workflow) then yes... I'd say it's more important than the topic of this particular thread.
 
Colors don't affect me as much because I am fully sighted and have other ways to identify elements in Sonar. I have seen the reasoning behind the color complaints though and they make sense... the most compelling of which are from the folks who are legally blind and NEED those options to work. I also notice some of those members are no longer around either which leads me to believe they may have moved on.
 
I am disabled myself so I know the sheer frustration of not being able to do things over something simple. The instant it was put into THOSE terms it became extremely apparent to me the importance of color options... which BTW, were removed (edit: but being slowly reintroduced much to the credit of the Bakers who ARE apparently listening... sorry, should have made that clear. Just not to 8.5 levels of options yet but I'm sure they are working on it).
 
Puts it all in perspective... ya?

Doktor Avalanche
So then I will ask you this question Beepster, are you prepared to give a straight YES or NO answer, and if YES why YES?
 
1) New project blank template
2) Drag audio into the track view from browser 3 times creating three new tracks with audio.
3) On the time ruler mark a selection (by dragging your mouse over it).

4) Insert track

Expected

Track is inserted.

Actual

a) Track is inserted.
b) Selection on time ruler (made on step 3) is reset.
So again...
 
Is (b) expected behaviour or not expected behaviour YES or NO? If YES why YES.
 
This is a specific question.

Thanks...

Beepster
Simple answer is a resounding NO... but with an explanation.
 
I have always found time range selection in Sonar really fidgety as it is so I would NEVER expect a selection to be maintain if I moved away from the specific task at hand.
 
What I would like (and have mentioned in the past quite a few times) are time range selection improvements in general. Preferably a separate marker based system where you can set up boundaries using actual markers designed specifically for various tasks. They do not move or change or do ANYTHING other than sit there into you call them up for a selection or bounce or export or whatever. You set them and they stay set then they allow for all the good stuff you'd use time range selection for.
 
THAT, is a feature request though. Not a bug. Not a problem. Not a limitation. Not a nothin' but something I'd LIKE to see implemented to make things easier.
 
It WOULD fix OP's "issue" but about a million other ones as well. Lookin' at the forest, baby... not the trees... or the weeds... or the squirell poop on the ground.
 
;-)

Beep.. nope...
 
Does actual behaviour = expected behaviour.
If YES then either improve it (enhancement) or leave it.
If NO it's a bug and fix it!
 
You've already stated NO (so you've stated you agree changing the scope of what is currently selected).
The workarounds are an entirely different conversation please do not get them confused.
It's as clear as day.

Passion breeds conflict, conflict breeds greatness.
-- Lead Engineer for Microsoft Visual C++ whose name escapes me at the moment (maybe Kevin McCarthy), circa 1994

Doktor Avalanche

Beepster
You know what? My answer was actually YES I would expect that behavior. I f*cked up due to the winding nature of the query and the thread.
 
When I said NO I meant that I would NOT expect the selection to be retained which should have been gleaned from my followup.
 
My apologies.
 
but Bob has got it right...
 
We have better things to do, lads.
 
Well most of us do (should) anyway.

Losing the will to live...
Is (b) expected behaviour or not expected behaviour YES or NO? If YES why YES.
 
If you NOW answer YES you should should tell us all why
 
b) Selection on time ruler (made on step 3) is reset.
 

Is desired behaviour.
 
Nobody is answering that question...

No, you know what... I realized the bullsh*t strawman argument you put me in with your little scenario. I was answering honestly on the fly not thinking you would pull trick stunt arguments on me... of all f*cking people.
 
My answer is you're being an arse to one of the guys who's stayed at least neutral throughout your crap around here and still considered a friend/force for good.
 
But if you have that little respect for my intelligence that you'll pull lawyer levels of stunt questions on me you can p*ss off.
 
You know WTF I meant full bloody well and if you don't apologize NOW and ease the f*ck off we are done, brother.
 
Not cool at ALL!

Doktor Avalanche
Stunt trick?? I asked EXACTLY the same question is #65 and SEVERAL times before that.
 

Doktor Avalanche
Is (b) expected behaviour or not expected behaviour YES or NO? If YES why YES.

 
And I've been asking the same question over and over again in this thread.
Nobody is giving me an answer.
I guess you can't or won't answer hence your response.
 

Read my goddmaned posts and you will get your answer.
 
You want to be obtuse? Fine. We are done.
 
 

I'm really sorry you are offended in some way.
I'm really NOT trying to catch you out or anything. I just don't seem to get a straight answer from anybody not just you... I don't understand what you are trying to say.
 
Nevermind.

beepster
I have always found time range selection in Sonar really fidgety as it is so I

 
OK I should have addressed that.
 
If the answer to (b) is by design because it is "fidgety" then I'm totally lost.
 
From that perspective you can argue any well known bug in software is by design and not a bug.
My real question is still why is this desired behaviour to reset the scope of selection? 
 

beepster
 would NEVER expect a selection to be maintain if I moved away from the specific task at hand.

 
Try
 
1) New project blank template.
2) Drag a wav track in to create an audio track.
3) Make a selection on the timeline.
4) Select track.
5) Right click track clone track
6) Select cloned track
7) Right click cloned track and clone the track.
8) Select latest cloned track.
9) Insert a track folder
 
Expected
 
Selection in step 3 stays the same
 
Actual
 
As expected.
 
So that works... The only time that it resets the selection is insert a MIDI, AUDIO track or a track template.
 
... and I still can't see any reason why resetting a selection is useful. Sorry.

It may in fact be a bug, but I wouldn't be at all surprised if it were not because the behavior we're talking about is not unexpected to me. I respect that the behavior seems wrong to you and I support the idea of filing a defect report, if for no other reason than to settle the matter.
 
It's reasonable for software to anticipate that a user will want to manipulate an object newly added to the model, thus the selection change. I would expect folllow-on commands to apply to the new object and not tracks or clips I was working on previously. This is what beepster was saying imho. There is logic in the behavior.
 
I concede that there may be an advantage to the user with the behavior you say is correct in the context of the OP's workflow, but it's just as likely to break any number of other tasks that work well with the way it is now.

Lol, I gotta tell ya, I've had a lot of QA guys working on my teams; they are by nature a pedantic bunch, but I'd fire them all and hire you in a minute.
 
As for your question, asked and answered, Dok. I get your logic, you just don't seem to get mine. I don't think I could achieve a higher level of clarity by typing a bunch more words. Ask yourself, why must everyone agree with me? We just have different perspectives. It's all good.

Doktor Avalanche
Right but just because you are expecting a bug does not mean it isn't a bug.

 
Ooookay... but I'm expecting it's not, and it may be. My world will not shatter if that happens. I'm not sure what you mean here.
 

Doktor Avalanche
You need to put on your logic goggles and take an objective view. Ask yourself 'why does that selection reset'?.

 
I came into this with my logic goggles firmly in place and have yet to take them off. The selection does not "reset." A reset selection is meaningless. Something is selected, or there is no selection. Indeed, some software doesn't allow nothing to be selected. When a new track is created, it becomes the "active selection" and the UI objects change states to reflect the new situation. That's the way I'm seeing it anyway.
 

Doktor Avalanche
 The second you get personal or have 'feelings' about it... It removes yourself from he actual issue.

 
Where did I get personal? Point out a post of mine that got personal and I'll retract it completely and tell you what I really meant to say. Feelings?  Where on earth did you get the idea that I have any feelings about this? Again, you've lost me completely.
 

Doktor Avalanche
If you think the behaviour is wrong why is it wrong. If you think the behaviour is right why is it right.

 
Done that already. Please re-read my post explaining this.
 
Thanks!
 
Kevin

Kevin will the post later but I tend to write terrible posts where people think I'm directing stuff at them. When I'm just saying and thinking 'in general' from the overview of the thread. Getting drunk down pub right now :) I get what you are saying of course none of it personally directed..

Anyway just reread my post and put it in the context of agreeing with you. It was NOT supposed to be a 'I am better than you' exercise. I see what I wrote would appear that way sorry.