Nuance and context are not the strong points of a text-only medium. If the underlying context of "works for me" is "you're an idiot," then that's a problem. If the underlying context of "works for me" is another data point that could lead to a solution, that's not a problem.
 
For example if someone says "I have a problem with Kingston when running plug-in X and didn't have a problem with Jamaica Plain," then it's logical for the person to think there is a problem with Kingston...right? However, if someone else says "I'm running plug-in X with Kingston and it works for me," then there's a very good chance the issue is not with Kingston, so maybe the person having the problem should look elsewhere.
 
Think of all the times in these forums when someone had a problem with a plug-in that was due to having an older version (or interface issues due to an outdated driver), and not realizing an update was available. Under those conditions "works for me" can lead to a solution just because the person with the problem knows that a solution is possible.
 
If everyone experiences a problem (e.g., tempo changes not reacting properly when upsampling was first introduced), it's a no-brainer the problem is with the software because no one can say "it works for me" when it doesn't. However if some people have a problem and some people with (seemingly) identical circumstances don't, then it's important to find out why there's a difference. There's no incentive to look for a difference unless it's clear there is a difference.

I agree with this. When I have a problem, if someone says "it works for me", then I know I have to look at my setup - where if a few people say "it doesn't work here either" then I know it's probably not a problem with my setup, and maybe some thing's broken.

I guess it's different if you're being an ass when you say "it works for me" - but Steve is hardly gonna do that ;-)

RPeveler
Hi - regarding Kingston update, I noticed straight away that both Iris and Breaktweaker produced loud noise when inserted.  I emailed cakewalk immediately but as yet still no reply.  Plug ins work fine in stand alone and in older install of sonar x3 and were fine until this update.
I share the frustration that I don't want monthly updates when they break things, particularly when distributed on the eve on a long public holiday in the US.  A case of "get this problem off our desks and onto those of the users".
Thanks and happy holidays guys.

I agree with the post here. I'm currently back to Ipswich after 2 unsuccessful updates. JP - scan VST issues and delay on some synths - K - scan fixed, delay apparently better but didn't test all - however, I opened up one project and my SubDestroyer VST recently purchased didn't work. Now I'm seeing other synths like Sylenth and Breakweaker having issues and as I own them, I'm reticent to even start using them. Trust = zero. 
 
Having said that there's been an offer of help from Ben Staton, which I appreciate and which I may seek out if I get the time. Having been through updating JP and rolling back 7-odd times, I would rather use a version that works and I can get on with making music, rather than problem solving why 2 updates are causing problems, when all updates up to JP, worked fine. On the other hand, this is what my subscription pays for right?
 
I would like to suggest that testing and problem-solving issues 'apparently' caused by the last 2 updates, isn't part of my subscription agreement...but of course this is software and 'smooth sailing' isn't guaranteed. I just want those 'clear skies'.

Could anyone enlighten me about the process of rolling back to previous updates?
Are you just creating a restore point in windows before updating and then going back to that, or is there a cakewalk specific way to do it?  If the former I must make a mental note to create a restore point at each update!
Thanks

You roll back in the Command Center (CCC). Just RH click on SONAR and there is an option to roll back...

Aha - many thanks!

mettelus
This will kick the hornet's nest, but needs to be said. The "works for me" (a.k.a. "sucks to be you") is a terrible stance to take in a public-facing environment. 1) It very much implies "finality," meaning that no effort to identify/resolve the issue is intended and 2) this seems to come from assigned beta testers in defense of "I did my job."
 
True finality comes from a customer being made whole. First step is prevention of field failures with as much due diligence and sense of urgency as possible, and if something cannot be verified... wait. Nothing gives a "branding black eye" more than field failures, and the monthly release cycle is taking precedence over "wait" - a significant Achilles heal to consider.
 
There are enough Harvard Business Reviews out on this topic to wallpaper a room. If someone has an issue, it is much better to get clarification to drive to root cause/(true) resolution. "Works for me" doesn't show any concern for a customer's issue or intent to resolve it.

Your statement would make a little more sense if it were directed toward the company's tech support organization. This forum is not that. I'd be annoyed if I made an official trouble report and got that response from the company. It does legitimately happen, though: "unable to reproduce".

As far as this forum is concerned, though, I imagine it would be pretty useless, even if less offensive to some, if every volunteer on this forum who goes out of their way to test the reported scenario just keeps quiet whenever it works for them.

I gotta agree...    the "works for me" replies may at least give someone hope that an issue is fixable for them, where no replies at all from the same people could be deafening if no one is able to reproduce the issue.   
 
This is assuming that the "works for me" comment isn't followed by a bunch smileys.   That's just cruel.   
 

scook

RPeveler
Hi - regarding Kingston update, I noticed straight away that both Iris and Breaktweaker produced loud noise when inserted.

I cannot comment about Breaktweaker. Don't have the plug-in. When it comes to Iris, both 64bit VST2 and VST3 format Iris and Iris2 seem to work OK for me in Kingston on Win10.

I finally was able to make the VST2 format fail for both Iris and Iris2 by enabling the 64bit Double Precision Engine in Preferences > Audio > Driver Settings. I normally do not have this enabled. The VST3 format which I use does not seem to be affected by this setting. Disabling the 64bit Double Precision Engine also appears to restore the VST2 to normal operation. Of course, the setting should not affect how the synth plays. I expect CW will address this in a future update.
 
HTH

That up thar ^^^^^ is exactly why when scook says "working here" it is a massively useful data point when doing risk assessment.
 
He don't pizz around. Lots of posters like that.