Cubase 12, frustrated again, this time "checking licenses" forever? <sigh>

[Milkman]

Sorry to hear folks having problems.

I have been using Cubase ever since 2018 (when Gibson torpedoed Sonar). Cubase has been good to me. It is not that I cannot get Cubase to stumble occasionally, it is just that I really must push it to get myself into a jam. Usually it is some orchestral project I am working on (with a gajillion tracks); I then wander off part way through to read mail, forget myself, open some other application for a bit (Adobe this, or that...) and then go back to music. More than one media application/memory hog and things could get ugly if I am not paying attention.

My setup is Windows 10 on a first gen i7-6700K. It has only got four *real* cores, but it is sitting on 48 GB ram. (Helps tremendously with VI Pro...) If I had to guess the notable thing about my system's stability is that it is using good-old FireWire (800) for my audio interfaces. Still using Motu interfaces and those things are solid. My only gripe with them is the display's go out after time.

You are fortunate that you happened to build one of the magic platforms (combo of CPU, MB/BIOS, audio interface) that did not experience the issue.

I requested on the steinberg forums and via email support a list of supported hardware and/or BIOS configs, but they refused continuously for over 3 years. I have steinberg *in writing* admitting this problem, and asking me to work with them over the long term to "QA and troubleshoot", but I ran out of patience and time to do this with them years ago. There was no solution offered other than "wait for the industry to change", and that just doesnt work in the face of numerous other brands working this out just fine.

-My wife's MSI laptop from 2015 - an i5 H-series 8th gen with 16GB DDR4 - ran everything perfectly without configuring anything, including ASIO Guard.
-My i7 965extreme 4/8 core with 16GB DDR3 on an x58 motherboard from 2007 (all default) had the issue and I couldnt resolve it with any changes to BIOS or windows runtime.
-My i7 7800x 6/12 core with an x299 motherboard had the issue worse than any other, but had a workaround. I had to fully disable all virtual cores, all power management, and all dynamic clocking to stabilize it, and it would STILL overload internally and pop/click sometimes(rare).
-My i9 10900KF 24 core on a z690 motherboard with 32GB DDR5 works perfectly with all BIOS features enabled. I can do anything while C12 is running - extract large archives, browse web at any capacity, download numerous files at 100MB/sec via our 1200mbit ISP, etc. C12 never glitches, real CPU and internal ASIO never overloads.

And allllllllll this time Steinberg says "there is no issue/the issue is extremely rare and you are basically alone/dont use any new Intel CPUs

[Milkman]

I started on Sonar, was on Studio One for a good long while (still a secondary DAW), gave Cubase a go as my primary DAW for a few years, finally landed on Reaper and really have never been happier with a DAW. Took longer to get setup how I wanted, really long in fact. But what a great DAW. Reaper is fast, stable, efficient, has responsive developers not trying to get you to buy into an ecosystem; pretty much the opposite of Steiny. I voted with my wallet. #JustSayin'

What you say makes a lot of sense to me. I could probably reduce my stress and level of frustration with all of this if I just became proficient in another DAW. I hear a lot of good things about Reaper, and also Bitwig.

In terms of how much this is affecting the industry and every artist in it, looks like groups of people (including ex steinberg devs) are looking to make a new plugin standard to replace VST, and the standard is supposed to specifically address multithreading. Im watching this.

https://www.bitwig.com/stories/clap-the ... ndard-201/

[Funkybot's Evil Twin]

I started on Sonar, was on Studio One for a good long while (still a secondary DAW), gave Cubase a go as my primary DAW for a few years, finally landed on Reaper and really have never been happier with a DAW. Took longer to get setup how I wanted, really long in fact. But what a great DAW. Reaper is fast, stable, efficient, has responsive developers not trying to get you to buy into an ecosystem; pretty much the opposite of Steiny. I voted with my wallet. #JustSayin'

What you say makes a lot of sense to me. I could probably reduce my stress and level of frustration with all of this if I just became proficient in another DAW. I hear a lot of good things about Reaper, and also Bitwig.

In terms of how much this is affecting the industry and every artist in it, looks like groups of people (including ex steinberg devs) are looking to make a new plugin standard to replace VST, and the standard is supposed to specifically address multithreading. Im watching this.

https://www.bitwig.com/stories/clap-the ... ndard-201/

I'm a big fan of what they're doing with CLAP plugins! Reaper already supports the format, though not as thoroughly as Bitwig.

[Milkman]

Cubase meter is a real-time performance meter. It's not the same as a CPU usage meter. Real-time performance meter counts more than just CPU usage to its overall result. It's worth to remember this to not think that 'Cubase meter is useless/stupid etc.)
Here's video explaining differences: https://www.youtube.com/watch?v=GUsLLEkswzE

Another thing worth knowing is how audio is processed in DAWs. TLDR: DAW is as powerful as the fastest single core of the CPU.
While normally DAWs can split a track per CPU core, the moment we make buses or put effects on Master Bus, all those tracks assigned to it are calculated on the same core (more or less). In other words: don't put effects on your Master Bus because this automatically cuts available resources of your computer. Leave it for the mastering process after the arrangement and mix are done. Control Room effects count for this to I'm pretty sure. Especially Sonarworks which I'm finding to be the most badly performing plugin in my collection.


Ps. I also have Ableton Live and while it may look like it's better with CPU usage when native effects are used, it quickly becomes a real pig when 3rd party plugins are used. So it's not only Cubase. Rant: not to mention how inefficient is track freezing in Live in comparison to Cubase to save resources.

Thanks for taking the time to write that. I understand all of this, as Ive explained to the last few well-intended folks who described the internal meter vs real CPU, etc. Have been working on this going on 4 years, or 22 years if you count the 2002 issue with Core2Duo. While some inexperienced folks do make the mistake of not understanding internal vs external resources, DSP philosophy over multicore, etc, the issue I am tracking for all these years is not meter related, task manager related, or aesthetics. And I hope I dont sound grumpy at all, Ive just been dealing with this for too many years to not sound a little curt lol.

Im guessing the 5.6ghz my single cores turbo up to is helping single core DSP performance. ; ) (and somehow avoiding the power mgmt / dynamic clocking pops & clicks)

When I tested Live recently in a fit of renewed anger at steinberg, I saw what I needed to see -- with ALL of my 3rd party plugins and libraries mapped, no internal or external (or audible) issues. I loaded up a project and chained together many effects, loaded up the dreaded NI Pharlight, Straylight, Ashlight instruments, physical modeling synths, etc. I didnt see any CPU issues - REAL CPU issues or internal ASIO meter.

But Im with you on the OTHER issues in Live, lol. I really cant work within that right now... and Ive given it some time. Live's workflow... just doesnt work for me, and I feel like they tried to move away from too much standard sound design / engineering nomenclature and syntax. I wish I could use Live more often!!

[Milkman]

I started on Sonar, was on Studio One for a good long while (still a secondary DAW), gave Cubase a go as my primary DAW for a few years, finally landed on Reaper and really have never been happier with a DAW. Took longer to get setup how I wanted, really long in fact. But what a great DAW. Reaper is fast, stable, efficient, has responsive developers not trying to get you to buy into an ecosystem; pretty much the opposite of Steiny. I voted with my wallet. #JustSayin'

What you say makes a lot of sense to me. I could probably reduce my stress and level of frustration with all of this if I just became proficient in another DAW. I hear a lot of good things about Reaper, and also Bitwig.

In terms of how much this is affecting the industry and every artist in it, looks like groups of people (including ex steinberg devs) are looking to make a new plugin standard to replace VST, and the standard is supposed to specifically address multithreading. Im watching this.

https://www.bitwig.com/stories/clap-the ... ndard-201/

I'm a big fan of what they're doing with CLAP plugins! Reaper already supports the format, though not as thoroughly as Bitwig.

I mean I know I was asking for it, but one of my many deleted comments on the steinberg forums was asking them how soon they would be supporting CLAP in Cubase.

Maybe a CLAP to VST emulation or proxy or something would work better than native VST.

[Funkybot's Evil Twin]

Maybe a CLAP to VST emulation or proxy or something would work better than native VST.

One of the things CLAP may do is this: a developer could create a native CLAP plugin, then use various CLAP extensions or whatnot to create VST3, VST, AU wrapped plugins from the original CLAP. It may even improve VST3 plugins because some of the more lesser utilized features like Note Expressions could be converted over from CLAP to the wrapped VST3. This is something Urs Heckman from U-he has talked about a bit in the various CLAP threads.

[SuperG]

You are fortunate that you happened to build one of the magic platforms (combo of CPU, MB/BIOS, audio interface) that did not experience the issue.

I requested on the steinberg forums and via email support a list of supported hardware and/or BIOS configs, but they refused continuously for over 3 years. I have steinberg *in writing* admitting this problem, and asking me to work with them over the long term to "QA and troubleshoot", but I ran out of patience and time to do this with them years ago. There was no solution offered other than "wait for the industry to change", and that just doesnt work in the face of numerous other brands working this out just fine.

-My wife's MSI laptop from 2015 - an i5 H-series 8th gen with 16GB DDR4 - ran everything perfectly without configuring anything, including ASIO Guard.
-My i7 965extreme 4/8 core with 16GB DDR3 on an x58 motherboard from 2007 (all default) had the issue and I couldnt resolve it with any changes to BIOS or windows runtime.
-My i7 7800x 6/12 core with an x299 motherboard had the issue worse than any other, but had a workaround. I had to fully disable all virtual cores, all power management, and all dynamic clocking to stabilize it, and it would STILL overload internally and pop/click sometimes(rare).
-My i9 10900KF 24 core on a z690 motherboard with 32GB DDR5 works perfectly with all BIOS features enabled. I can do anything while C12 is running - extract large archives, browse web at any capacity, download numerous files at 100MB/sec via our 1200mbit ISP, etc. C12 never glitches, real CPU and internal ASIO never overloads.

And allllllllll this time Steinberg says "there is no issue/the issue is extremely rare and you are basically alone/dont use any new Intel CPUs

I hear you.. yeah, I got a bit lucky.

This machine is a 2016 Dell XPS. I've modded it over time, so it has a newish GTX-1660 video card, and replaced the boot drive with a 1 TB SSD. I keep sample libraries are on spinning disks though, no need to have them on SSD, - but Kontakt and Halion can easily preload samples from disk and make use of the plenty ram here.

The only external PC card-based I/O I have is my Firewire card - everything else, USB, drives, all use motherboard I/O.

The best investment was in converting it over to a boot SSD

There is some little bit of merit in staying a bit behind the bleeding edge of technology, at times.

In other news,
I called Motu to see about getting the display fixed on my UL MK3 hybrid - they informed me they have stopped doing non-warranty work on their older models. Heck, my Ultralite is ten years old now - but, hey it works as good as the first day I got it. Anyway, they did sell me a replacement display part at a very reasonable price - I will just fix it myself. These electroluminescent displays tend to have their voltage inverters crap out over time...

[D-Fusion]

I went Back to Bitwig and this is the Last time I support Steinberg with my Money...

I got the dreaded Gpu Error again yesterday and did some Research and was amazed at how many that encounter the graphics2d.dll Error.

Everything works great on my System except for Cubase.

https://forums.steinberg.net/t/graphics ... hes/159699
https://forums.steinberg.net/t/graphics ... /43?page=3
https://forums.steinberg.net/t/cubase-k ... 005/160484

[dionenoid]

There is some little bit of merit in staying a bit behind the bleeding edge of technology, at times.

This.

[Milkman]

There is some little bit of merit in staying a bit behind the bleeding edge of technology, at times.

This.

This is true in a variety of circumstances, but the primary issues described here have existed in a *similar fashion* for over 20 years, 10 major revisions, I can't count how many x86 hardware iterations, and still they persist. And the other vendors, all along, have mostly avoided the issue. I think this isn't a case of early adoption blues at all, lol.

Also, being a career sysadmin helps new hardware and software seem less daunting, frankly. I've been a day-one adopter for 30 years on behalf of clients, customers, etc, and it is part of my skill set. But the issue with steinberg being not unable but *unwilling* to adopt some other core DSP philosophy that could at least provide a stable workaround for customers who use these very common platform components is the core issue. It's what's spawned all of this research into moving away from VST, itself, as a standard.

[sqigls]

honestly, of all the computer setups and versions of Cubase i've used since my 400mHz P2 and VST 24, this M1 machine is doing remarkably well. Considering the sheer amount of various 3rd party code this rig is churning through, it's surprisingly stable. and it's the Rosetta version of C12. Macbook Pro 16gRAM (2021), Monterey.
I doubt I'll upgrade anymore. Unless i can suddenly afford the MAX version of the Macbook M1, just to be able to use 3 external monitors.The only thing i'm really needing is native versions of The Drop and the remaining FeelYourSound plugins in VST3.

One of my mates has jumped ship to Logic, I tried, but i much prefer Cubase. Tried Studio One for about a year, tried Bitwig for a few days. Tried Logic for a few minutes, and Ableton Live lack of MIDI editing is out of the question for composing.
For me, it's just knowing when to save. I just think back to SX3 and my Pentium 4 blue screens of death and just sigh some relief. It's been worse.

[noiseboyuk]

Just a brief defence of the performance meter. I was just working on a moderately heavy setting and swapped a reverb for another (Abbey Road Plates). Straight away things seemed a bit on-edge. I looked a the meter, and the ASIO load had maxed out. I then swapped for another plate - Sunset Sound - and immediately the ASIO load dropped to a more comfortable level.

Now in that case I probably would have figured it out without the meter it was so stark, but the point is - the meter perfectly reflected the real world issues I was having. It's a helpful diagnostic tool when you run into problems.

[Milkman]

I think some of the "the internal meter is lying" and "your windows system / Mac OS task manager is lying" narratives have come from steinberg themselves. The things that prompted me to come post about this here was a) curiosity about other users' experience, b) steinberg denying the "checking licenses forever" bug that I reported, claiming it must be a "dishonest task manager" despite my real world testing. They simply don't want to address this and create wild goose chases for users instead of accepting more QA worlk for themselves.

[SuperG]

There is some little bit of merit in staying a bit behind the bleeding edge of technology, at times.

This.

This is true in a variety of circumstances, but the primary issues described here have existed in a *similar fashion* for over 20 years, 10 major revisions, I can't count how many x86 hardware iterations, and still they persist. And the other vendors, all along, have mostly avoided the issue. I think this isn't a case of early adoption blues at all, lol.

Also, being a career sysadmin helps new hardware and software seem less daunting, frankly. I've been a day-one adopter for 30 years on behalf of clients, customers, etc, and it is part of my skill set. But the issue with steinberg being not unable but *unwilling* to adopt some other core DSP philosophy that could at least provide a stable workaround for customers who use these very common platform components is the core issue. It's what's spawned all of this research into moving away from VST, itself, as a standard.

I will take the 'all the other vendors' quip as rhetorical because if that were the case, Sonar would not fall over on its face when doing orchestral comps.

I spent years writing real time embedded firmware and I will point out to anyone that listens that real-time performance depends heavily on memory architecture. It does not matter if you have 64 or 512 cores, if you have but one memory space (as all desktop computers do) They all must stand in line and share that space. Inevitably, interrupt duties on the memory bus are delegated to just one processor, just like a traffic cop. A core can only process as as fast as the cores in front of it, and they all must share time with system drivers.

PC's are amazing - but they're open to folks corrupting them with either bad devices or drivers, or maybe just too many devices screaming for time. It is rare that an application is actually at fault vs performance - if that were true everybody would be bitching and not just the outliers running esoteric systems.

[sqigls]

I think some of the "the internal meter is lying" and "your windows system / Mac OS task manager is lying" narratives have come from steinberg themselves. The things that prompted me to come post about this here was a) curiosity about other users' experience, b) steinberg denying the "checking licenses forever" bug that I reported, claiming it must be a "dishonest task manager" despite my real world testing. They simply don't want to address this and create wild goose chases for users instead of accepting more QA worlk for themselves.

That's how Schteemberg have always operated.
Just blame, no solving problems.
There's no money in solving problems.
The money is in new new new things, features, new problems