Questions & Answers

Recommendation: Have Studio One's Performance Monitor show 1) show the overall CPU load spread out across all cores (new functionality) in addition to 2) the maximum CPU load of the most stressed core (current functionality).

Example:

Overall CPU: ~8%

Max Core: ~61%

Background: Studio One's Performance Monitor currently only shows the CPU load of the most stressed core. This certainly contributes to Studio One's reputation as a "CPU Hog." Example: a new user loads a CPU intensive plugin in Studio One and sees 60% CPU usage on the Performance Monitor, while Reaper shows 8% CPU usage,

Meanwhile, if you look in Windows Task Manager's Performance tab, CPU usage may be nearly identical between both DAW's.

Impact of Current Functionality: Users come to the conclusion that 1) Studio One is much less efficient than Reaper (or buggy), and 2) they can only run one instance of the plugin, neither of which are true.

As I think about the current-state more, I also realize there are some gaps: 1) I don't know which core is the max (most stressed) core, and 2) I don't know what's loaded on that core. Suggestion:

1. Have S1 show the average CPU load per core on the main Performance Meter (I believe that complaints of high CPU and spiking will drop just from the change in default performance calculation)

2. In the detail view (when double clicking the Performance Meter), show the average core up top, with the individual core loads beneath that so users can see which core is stressed.

3. In the list view, show which core each instrument/effect is currently loaded to.

With this information, I may see that I have a high CPU synth and its effect chain all running on the same core, and that I may be able to create an effect buss for that instrument output to lower the CPU usage.

The reason S1 (and most other DAW's I would assume) show you the status of the core that has the most load, is because if one core overloads you will run into trouble playing back your song in realtime. You want to remove our ability to actually see this pretty vital information. And for what? So that users can be deluded into thinking the reality is much better than it really is?

If this change were to be made (and I highly doubt it will be), you'd have a equal amounts of posts from people asking why their audio projects can't play back in realtime, when they're only using 10% CPU, as both stated by S1 and their OS' CPU meter.

The result is that you just moved the problem, removed vital information and are now showing information that we can already get from the OS' CPU meter.
While I understand your reasoning for this request, it's important to note that this is not the solution.

@ Photontic,
I'm not suggesting Studio One replace the existing functionality, I'm suggesting they ADD to it. I want to see BOTH the max stressed core, and the individual core usage. Sonar manages this via an easy to understand graphic.

The goal is to get more information about what's happening. Look at the current situation: every few days I see complaints about how a single plugin might use 60% of the CPU in Studio One and only 10% in Reaper. Then everyone has to explain to these people that the two hosts show CPU usage differently and it's not an "apples to apples" comparison. Then someone else will inevitable jump in with the same observation and the process begins again.

Clearly, the current state is confusing users, and creating an impression that S1 uses way more CPU then Reaper, when the differences aren't that great. My suggestion is simple: show us the max core load for troubleshooting purposes (i.e. keep the current state), and add information about the "overall" CPU use (that's in addition to current).

Adding to it means we're entering the land of UX (user experience) and you have to ask yourself: Is this helpful to users? You argue that the current method is confusing. Even more so your argument is mainly based around competing with another DAW, so to speak.

To me neither of these are good arguments. Just because some other DAW shows it differently it doesn't mean that S1 should just follow suit and move away from something that is the correct way.

Adding all cores? That'd be 12 for me. 12 bars. As we move forward this will only increase for users (as CPU's are getting more and more cores). That's too much information and people who already don't know what the single readout in S1 means now would just be even more confused. You're creating an overload of information that is only going to help those who already know how to read the information. Those who don't - those we need to help and educate - will just be even more confused than before.

As it is now we can easily explain what S1's CPU meter shows and why this matters - why it's the most important thing to show. Then we can always elaborate and tell them how to see individual cores, if so needed. There is no reason to flood S1 with this information as it's not really relevant, and would likely have an overall negative UX effect.

Again I can only recommend that PreSonus write a blog post detailing CPU/multi-core usage and the how's and why's of it relating to S1, to better educate people, so we'll see less confusion. Adding more unexplained information into the mix isn't going to reduce this confusion.

At the end of the day this is about educating users about what's actually going on. Your suggestion does not solve this. What could help is a tooltip when hovering over the performance section briefly explaining what it's showing. Likewise text could be added inside the performance monitor window that also briefly explains what's being shown. This would go a long way.
If it isn't already there (I honestly haven't checked) it could be added to the manual as well, perhaps detailing it a bit more.

I understand your reasoning, but as someone with a fair bit of UX knowlegde I just can't agree with you.

I do however agree with you that some of this could be put into the performange monitor window. I have no issue putting all cores etc. in there - that'd be just fine.

Likewise the idea of being able to see what core a plugin is on could help "troubleshoot" these things for advanced users. This, however, is only really relevant if things generally stay on the same core. As I don't know enough about OS scheduling in this regard, I can't speak to how frequently things might get shifted around on cores as load changes. If the latter is the case, it would be a mess because you'd be playing whack-a-mole basically. :P
But if it is generally pretty locked down, then yes, it'd be a nice bit of extra information for sure!

I just spent half a day trouble shooting Studio One because the CPU usage looked way too high. It took me hours of trouble shooting and then looking through forums to finally figure out that studio one is not giving me an overall monitoring of my cores. I only figured this out when I monitored the CPU through task bar, compared it to Studio One’s CPU bar ... and started to realize something didn’t make sense. Then I started researching.

I should not have to do this. It should be labeled as such or it should have added functionality. To say it’s a user experience issue is insulting to the user. Most people who know how to use a DAW, know a good amount about tech and software, and want more information .... excuse me ... ACCURATE information , and options.

Studio One is my favorite DAW, but I was getting so frustrated with the CPU load, I started downloading free trials to start switching to another platform. How silly would it be to lose a customer because the CPU monitor bar is confusing for many people?