Doktor Avalanche
Noel I had a similar issue, only this is a clear bug that's been reproduced by everybody and yet has been marked ... Contact tech support... It's clearly not an environmental issue and not hard to repro.
Did you get my PM a few days back?
Thanks.

Noel Borthwick [Cakewalk
Yes I did. The tech support person clearly mentioned that in the report that they coouldn't repro the issue as stated in the recipe.

 
There was no comment whatsoever. I know 100%. I've now gone and checked again and now there is a comment with same date stamp. Weird!!... I have absolutely no idea.
 

Noel Borthwick [Cakewalk
As mentioned above, support does not actively monitor the forums, so its your responsibility to add more details about the bug if available to the bug report itself so that tech support can evaluate it better.

 
How am I supposed to do this when the problem report is locked completely for comments?

Noel Borthwick [Cakewalk
Sending me a PM is not the solution since I don't necessarily have the bandwidth to investigate every problem report. TS is much better equipped to do that.

 
I totally understand about your bandwidth but for me that was the last resort, I could not comment on the problem report. I also appreciate QA tried to reproduce the issue.
 
.. but sorry but this is where the disconnect happens.
 
* I bother spending MY time to get an issue validated in problem reports forum BEFORE I send it to QA, I got it validated by two users. I do this in order to save YOUR bandwidth (make sure I validate before I log the problem report) so I am pretty sure you get something reproducible rather than a waste of time.
 
* I make the issue as clear as possible. I also post a link in problem reports forum for QA to look at, did they click on it?
 
* Issue gets withdrawn and I'm supposed to contact tech support.
 
* To add to the confusion there is a field there that states "reproducible".
 
Questions...
 
A) What was the point of me spending time logging the issue in problem reports forum in this instance?

B) Why wasn't there any attempt to communicate through the problem reports forum, there wasn't just one user who could repro it there were multiple people? Pool the resources! (It's probably extremely unlikely it's system specific as multiple people could repro). Please make use of this forum!

C) Why does the problem report state reproducible? (that's something you gotta sort out too confusing).

D) How am I supposed to comment on a locked problem report?
 
Phoning up tech support wastes MY bandwidth and MY money. I'm based in the UK. International phone calls are expensive.
If I did that with all the issues I have logged I would be on the phone all day and tech support would have a nightmare. So I tend avoid tech support as much as possible.

Why isn't anybody in Cakewalk using the problem reports forums, where you have more users who could give you feedback. I see staff in there very very occasionally. It's rare, and sorry, I'm not going to spend my time phoning up tech support everytime I discover a bug.
 
Thanks.
 

Alex, I recall the thread where you were asking about this. I was going to add some insights as to why this may be occurring based on observations on my own machine but you seemed more interested in reproduction/confirmation which a) you got and b) I was not at my DAW and because of my suspicions about this behavior I knew it was repro-able to a certain extent but not specifically due to a "bug" in Sonar.
 
Let me explain...
 
I find that pretty much any procedure involving quickly accessing and manipulating data directly from (and to) the drive(s) is where about 90% of my problems occur. Things like audiosnap, time stretching, fast comping, etc is where this quick back and forth seems to lead to dropouts, crashes and corruption. Especially when trying to do it with real time playback stuff (I constantly get dropouts when fast comping tracks that have a massive amoutn of takes). Scrubbing, since it's trying to read the data while at the same time trying to calculate real time changes in speed would fall under one of those processes.
 
I've had success in minimizing problems when using these features by increasing my Read/Write buffers so that seems to confirm it. On my system the problem is amplified because I use HDDs (not SSDs) and I STILL haven't fixed up my system to have my programs and data separated (it's all currently on the C drive).
 
Reading the reply from Cake in your screencap actually reinforces my s-u-s-p-i-c-i-o-n (stupid filter) that this is a read/write issue because they are likely doing their tests on finely tuned, properly setup systems with SSDs (which you may be using as well but I'd imagine their test systems are ultra refined so they can all but eliminate the possibility of system problems which is why they said to contact Tech Support).
 
Essentially if that is the case this would not be a "bug" per se but instead how Sonar communicates with the drives in general which may be less efficient than it could be. IDK because before Sonar I only ever used a DAW for pure recording, playback and basic mixing.
 
I think this may also be why we are seeing this push into the ARA stuff. I don't fully understand exactly what ARA does but it seems like a very efficient and reliable system for this type of fast realtime data manipulation. As a totally non technical person IDK but using Melodyne (which is using ARA) is a lot smoother than some of the other other time/pitch stuff (this may have also been what was making V-Vocal act like such a jerk).
 
So perhaps if scrub were designed under the ARA stuff or you were on an ideal system like the Cake Tech guys likely are this issue may not manifest itself as consistently.
 
I mean I can almost guarantee if I am Fast Comping a track with a lot of takes and splits I'll get audio engine dropouts. I can reproduce it very easily. But since I know what I know about my system and increasing my buffers and/or lowering the clip count seems to reduce the dropouts I can conclude that it's not a "bug" but the system getting borked out by all the data flow.
 
Not the answer you are looking for I know but in this case I think perhaps "reproducible" does not necessarily = "bug". Just perhaps inefficient data flow for whatever reason.
 
Cheers.

@beep you will notice it cuts out in the exact same places... If you don't then clearly I need to find more steps. Anyway not going to hijack this thread about this specific issue. There's a thread in problem reports forum to make use of. I hope cakewalk can make use of it, we could have had this conversation over there.  However if I had stated that the problem report was withdrawn hosts would have locked the thread another brick wall. The main comment here in this thread is the experience with problem reporter/problem report forums/communication breakdown.
 
If QA withdraws two way communication is totally cut off in all forums. There is no opportunity to find better steps to repro if necessary, or pool resources.

Noel chiming in on threads like this is a privilege, not a right. Please respect the time of others. Thank you.

alewgro
haha ok fair enough...   lets end this thread, smile, and enjoy the sunshine 

Can we have wine too?  :)

Anderton
After reading through all this, I think one simple fix to a Cakewalk response would be to replace "working as expected" with "working as intended." People can have different expectations of what something would do, but only Cakewalk would be 100% sure how something was intended to work. If there's still a problem after finding out the function works as intended, then the logical follow-up would be to discuss whether a function operates as people expect.

If we are talking about the OP's thread would say "by design". There is however a bug he didn't log and an enhancement request needed which is what I think Cakewalk was inferring.
If there was better communication (see my previous posts) I don't think this thread would have existed IMHO.
 
Cheers..

Yup point taken.