We’ve created this thread as a place to discuss the announcement and answer your questions.
If you have any questions, concerns, or feedback about the plans outlined on the page, please share them here. We’ll follow the discussion and do our best to answer your questions.
Please take a moment to read the full overview before posting, as it covers what information may be collected, what is never collected, how your privacy is protected, and how you’ll remain in control of your choice.
Does diagnostic and usage data collection affect performance?
No. The system is designed to run efficiently in the background with minimal impact on performance.
I wouldn’t mind the collection of my data to help Steinberg as described, but with an old computer that i feel is always on the edge of being overwhelmed, “minimal impact” may be too much impact, and I’d be hesitant at this point to give it a go.
The way the system is designed is to write usage data events to disk for upload by another process separately as a low-priority activity. That way, the main application is not slowed down in any way by networking connections. The impact should be negligible.
Keep in mind however that if you use this data for developing enhanced or new functionality that you’re going to have users that aren’t using some functions because they aren’t working properly or are incomplete. Take VCAs for example; I use them within certain boundaries but I know there is a fair amount of users that just stay away from using them at all because they are either not understanding how they’re supposed to work, or are incomplete in their functionality, or are simply malfunctioning (won’t get into depth here).
So other ways of figuring out what’s requested of you are still necessary.
For tracking issues and bugs however I think this is probably a great addition. I’ll for sure turn it on.
Any existing data collection will be replaced by this new system.
The scope will likely change and we’ll publish more technical details as we get closer to the roll-out.
As the FAQ on the website says, each product will implement their own data collection specific to that product, rolling out gradually. However, there will be a central account-level switch to turn it on/off which every product will respect.
20 years ago I would have said, “No problem”. Now, after all that has transpired since then, I turn it off/opt out whenever I can. I trust nothing and no one at this point in my life. (Except my wife!)
That’s entirely fair and up to you! We’re certainly trying to go about this the right way and explain why this information is of value to us and, ultimately, will be of value to you – but always giving you the choice.
That’s a very commendable approach and I wish more companies would provide a global “off” switch for their data collection.
One of the things that worries me, is that the collected data - even when interpreted entirely in good faith - is over-interpreted.
I think it’s fair to assume, that power users are more likely to turn data collection off - so that could create a systemic blind spot in the data.
In addition, I’d surmise, that your power-users are also the best evangelists for your products, so if you become overly confident in the collected data, you may inadvertently reduce the positive overall impact of your power user community.
I couldn’t find a statement one way or the other, if you intend on collecting info about 3rd party plugins, extensions, MIDI Remotes, etc. being installed and/or used. I think that’s an important bit of info I would really like to know.
I believe @Nico5 said it best. I’m sure by analyzing the data you collect you’ll be able to recognize users that use Cubase professionally and employ the most efficient workflows. I’m not sure what the percentage is for users like me, but if you were to follow my workflow I think the first thing that would come to your mind is “what the heck is he doing?”. Heck, I still get stuck on stuff like is this “Ctrl + 1 or Shift +1”. I consider myself a N00b even after 15 years.
Regardless, I hope that you’re able to use this info to create and tweak Cubase into an even better piece of software.
I’m chuckling at this comment. I haven’t been using Cubase nearly as long (I started in late 2018 at 9.5, only making it my main DAW sometime during 10.5), but there is a lot of, not so much “who moved my cheese?”, but more like “where is that cheese again?”), that I encounter in my Cubase use.
Just to give one concrete example, yesterday I was wanting to get the chords from the chord track to a virtual instrument track. I knew I’d done it a small number of times before, but I couldn’t remember where it was, and all the places I thought were the most likely locations weren’t. I finally did find it, but then I wanted to try a different option (I think I’d done the default chord types and wanted to try guitar types or piano types), and I had to do some more poking around to find that.
The reason this comment, in context in this thread, makes me chuckle, and potentially smile, is that if this is the sort of “user error” stuff these diagnostic tools can detect and report, maybe there is actually hope for eventually making Cubase’s terminology, menu locations, and overall user interface less confusing and more streamlined. And that might make me much more inclined to turn it on. (In most cases I leave that sort of stuff off in any plugins and applications that request it.)
I’m totally fine with this. Users always complain that they want more stability, but I don’t see how that is achieved without being able to pinpoint exactly where the processing went wrong. I predict we’ll hear a lot less complaining about crashes after this gets implemented.
I’m a person who cheers when Flock cameras are cut down. I don’t want the government to spy on me. I don’t want other citizens to spy on me. I suggest people worry more about the entities that don’t ask your permission or offer an opt-out, and stop worrying about Steinberg who is just trying to improve the customer experience, which I’m sure they hope leads to more purchases. I’m in.