That is a nice looking beast! I went for two sticks of RAM because it had a slightly better first word performance over four, and 96GB is enough most of the time.
I am using studio drivers, and the GPU / NVMe are not shared, they have 16 and 4 lanes to themselves. No tweaks other than XMP.
Nothing in OneDrive; VST folders are in the root, and all my project files are on a Windows based NAS (also not being OneDrived from there).
I’ve been playing around again and think that most of my issues do seem to be Spitfire related; I’d done some tests yesterday that seemed to suggest it was Cubase by itself, but I just made a 128 instrument template with Metro Ark in every slot and it took 7 seconds to disable all of them, vs 3 solid minutes to disable 63 BBC SO tracks in a separate template. So good and bad news I suppose!
I did some testing the other day that seemed to suggest it was Cubase but having just done some further testing you seem to be correct; 7 seconds to disable 128 Metro Ark instruments in one template vs 3 minutes to disable 63 BBC So instruments in another.
It doesn’t help that there are forum entries on both Cubase and Spitfire where all of these things are being mashed together, and I probably haven’t helped it
On the plus side, it looks like Cubase may not be too bad after all!
I got 256GB in my 285k system. ASUS/Kingston partnership for RAM overlocking, lets me use four sticks of 64GB each at 5600 (CU DIMM). Was super easy and super stable. I got that crazy amount of RAM mostly because of OT SINE player. It doesn’t support memory sharing (it is the only major sample player that doesn’t) and so loading up two copies of an instrument uses twice the RAM as one, and unfortunately with my workflow I need several copies loaded, so 128GB would not be enough for me. I’m just lucky I bought before all these price increases happened.
I do wish Orchestral Tools would fix that in their player because it is a big problem for me. 128GB ought to be enough for anybody (famous last words, I know).
Heads up for those that have been following along and are interested, I have posted 2 follow up articles on the Windows and DAW’s series.
Part 2 : Multiprocessor Resources v Real World DAW Performance !
Summarizes and covers the work and testing done and reported on with the initial DAWbench DSP MIX sessions, which shone a light on DAW thread management and associated dynamics with the respective audio engines.
Part 3 : Cubase 14/15 : Core Handling v ASIO-Guard : The Ongoing Enigma !
Covers the more recent investigation when we revisited the testing 18 months on, and the discovery that the thread management and ASIO-Guard issues being navigated on Windows on the larger core systems, had also cross pollinated over to MacOS once higher core counts come into play.
As always, thanks for all your hard, investigative work.
I’d be lying if I said a feeling of hopelessness isn’t tangible after following along from when the MMCSS mess was first unveiled up until today. Cubase holds a special place in my heart, like I’m sure it does for many on this forum and I just want it to be the best of the best.
@Matthias_Quellmann: Would it be possible for you to find out what happened to the Processor Optimisation menu that was tested in beta in Cubase 13, as evidenced in TAFKAT’s extremely interesting research, in this article?
Why was it never implemented? Is this one avenue you are still investigating?
Lastly: Are there any news on a timeline for when the poor core-handling may be addressed now?
I attach a screenshot from the Steinberg video with the beta option menu.
Those might have just been beta testing utilities, sometimes development builds have all sorts of other nicknacks that don’t go into the production copy.
@Matthias_Quellmann, I would so appreciate it if you could reply to my above post.
I am very very interested in hearing about this from the horse’s mouth, since an improvement of Cubase’s core handling is the one major area - the only one really - where I feel Cubase is under-performing today.
Matthias is out of office and probably is busy / has limited access.
The processor optimisation menu was available in a beta version and has been removed as the processor strategy selection has been automated with later builds.
Thank you for replying, Fabio. Are there any news on a timeline for when the poor core-handling on the latest multicore processors may be addressed now?
The engine team is already very actively working on a couple key aspects, but it’s not my place to state dates or roadmaps, I was merely replying about the scheduling dialog because it was temporary and Windows-only, Matthias might have never seen that.
However, anything that deals with architectural, structural or scheduling cannot be addressed in a maintenance update, I’m afraid. I still hope we manage to ship improvements, though.
Thank you, Fabio, that does indeed sound promising. I would give a lot to know a bit more of about when these improvements may be expected. I understand that they are bigger than maintenance update stuff.
But I will dance and sing with joy the day the multicore performance is finally addressed and brought in line with the latest processor generations.
Do you really think they’re going to go into detail about their proprietary confidential work in a public forum? Not sure why anyone thinks they even have an obligation to answer these.
Its been an interesting 7-8 years, thats for sure.
There isn’t much we can do as end users but monitor and report the results of the ever shifting dots with what ever the devs are doing with the engine. I have thrown up my arms more than once, but this isn’t going to get resolved by playing ostrich , no matter how much some others here would wish that to be so.
As I noted both on this thread and in my article, as much as it doesn’t seem to some that I am coming from a position of good faith and/or intention at times, I am doing this with a deep love of the application that I have been using for 35+ years , and a genuine wish to improve the experience for all end users. It’s because I am covering areas that are not overly positive, that the intention can be skewed when viewed from that perspective lens.
Already noted that in the article, but still doesn’t answer why it was featured and included in the official Club Cubase release walk through video at the time after the release.
And what exactly the settings represented.
They have now been automated by some proprietary magic, that supposedly can adjust the different threading algorithms and routines per respective CPU architectures and session logistics , and we are all reaping the benefits of that magic, apparently.
As I noted in the article, the first setting is obvious, enabling/disabling the C12 core affinity routine , which would be of direct benefit to non hybrid CPU’s like the AMD Ryzens and/or earlier non hybrid Intel’s like the 10980XE.
How has that panned out ?
We are 2 years in from reporting that what ever core affinity routines they applied is confused regards correct thread management to the Ryzens, essentially ignoring the top 16 logical cores, and thats the tip of the iceberg, because some how, magically, that proprietary code practice seems to be cross pollinating over also to MACOS when higher core count AS CPU’s are in play.
I am not expecting any clear response, nor am I under any illusion that Steinberg have any obligation to respond or even address anything I have brought forward , but its not going to be as easy for them to continue ignoring and/or delivering sub/par amendments moving forward.
And I haven’t even touched on the associated ASIOGuard premature collapsing.
By the way, the above wasn’t directed at you specifically, this is just an overarching response to the ongoing subject matter.
