Installed the last update (8.0.2) when it was released and had to uninstall because the crackles, pops. & the Performance Meter was peaking every 10-20 seconds.
Ever since 8 I can no longer open older projects. Crash EVERY TIME. (This is the biggest problem for me) <<
The Window bar on top does not line up with the text if you are using fonts @ >100%
The push pins do not work in the inspector panel for instruments so you can’t have more than 1 drop down open.
I can go on and list every single issue but seriously would probably get to angry typing it…
New projects work relatively well if they were created within this version…outside of that, All bets are off!
I love Cubase. Every DAW has it’s issue.
That said,
What is going on throughout this release is mind boggling.
Can someone please post a link to d/l Cubase 5. I’m going to have to install 3 different versions of Cubase which is absolutely ridiculous.
To open more than one tab in the inspector strip at once hold down ctrl while clicking the tab.
Crashing of older projects is indeed a serious concern. Can you try on a different machine, or share with other CuBase users to see if it crashes their system too?
Obviously older projects might not find everything installed on the system it was using back when you made it, but they shouldn’t ‘crash’ on you
If you’re looking at the VST monitor (tap F12 and it pops up), but otherwise things are working/sounding fine…ignore the little monitor meter!
Crackles and pops can usually be tuned out through the right balance of options in VST Device settings.
Also, not all crackles and pops are from the DAW or even originate within the Digital domain. I.E. I have an old Delta 1010 that I could power up without any audio stream at all, and it would sometimes produce ‘snapping/popping’ sounds at random. I tricked the breakout box into powering up, plugged it into an amp, but had NO computer attached AT ALL…and got the snaps and pops. The Fix? I found bad capacitors inside, as well as a bunch of really dusty mode buttons that needed contact cleaner. Took about 20 minutes to order new caps, and about an hour to clean and replace things.
I have a budget Tascam interface that works really well…but it’s also pretty noisy on the 1/4" inputs.
That VST ‘performance meter’ is confusing so many it would seem.
Here’s what seems to be going on with my system.
ASIO Guard is there to help get rid of unwanted latency for the track you have armed and recording.
Anytime you have a track armed for recording, the ASIO Guard engine will indeed take priority and do what it needs to do in order to minimize the impact of latency on the track you’re recording into. It can easily peak out despite your actual system resources (CPU, Memory, bus bandwidth, etc.) barely even being tasked. It’s normal for that buffer to fill up and spike at times…particularly as the number of audio streams across the bus increases, and many plugins are triggering lots of small samples from memory or disk at once.
Example: Some plugins open a new stream for each new instance you start, or, you might have something like H5 that lets you configure multiple output streams for a single instance. The more of these streams and effects you add to the mixing matrix, the harder ASIO Guard will need to work to help you record on an armed track with minimized latency issues.
This spiking of the VST performance meter does NOT necessarily mean that CuBase is struggling to play back all your VST tracks.
If you’re getting drop outs, clicks, bad audio, etc…it’s usually a matter of fine tuning the ASIO buffers. Then there may well be some other issues to troubleshoot. If it’s just that bouncing meter that has you concerned…ignore it as long as everything works/sounds good…seems to me all it does is show how hard ASIO GUARD is working in regard to whatever track you have armed for ‘recording’…if you watch your actual system monitors…you’ll see that your PC itself probably isn’t even breaking a sweat.
Occasionally I run into really large patches with lots of large sample layers that give me problems (no matter what DAW or VST Host I try to run them in ). In these cases, it seems to be a problem with my nearly 10 year old budget build computer (AMD 1090T @ 3.6ghz on a DDR2/SATA2 platform), and it usually only happens when I have something ‘armed’ to record. I can try the same project in my spare PC (Similar age/spec to the AMD build, but on a worn out Intel 2.4ghz Xeon Quad, DDR2, ‘modded’ into a not so good Core 2 motherboard), and it doesn’t behave the same. Note, both of my machines are quite old and have developed issues over time…it’s just what I have to work with right now.
A work around for me in the case above is to use a light version of the patch while I’m composing/recording. In the later editing, mixing, and refinement stages, I’ll go back to my huge 40 layer patch, and make tweaks with editors, and do my automation lane tweaks while ‘no tracks are armed for recording’. If it burps a bit due to my under powered system, I just ignore it and keep mixing, as I know the burp isn’t going to be there when I render it. Once I’m fairly satisfied with the resource demanding VST track…instant render it to audio and mute/disable/hide the original MIDI track (can always bring it back if I need to change something and re-render). Of course I realize this isn’t very practical for someone doing 200 track projects on a deadline…but that sort of person is probably going to be running Nuendo on multiple/synced enterprise class machines, with server hosted VST plugins, and more…I.E. systems built specifically for the task of managing really large projects.
Tip:
Unless you’re recording on a track, disarm all tracks (toggle record button off, so it is NOT red). At that point, you’ll notice that ASIO Guard isn’t being asked to do anything, and the VST ‘Performance Monitor’ will appear to be in a much more idle state.
In some cases, you might have a system that does better without using ASIO Guard. Without ASIO Guard, you’ll see in the VST monitor a higher level of average activity, but you might see fewer patterns of what seems to be ‘idle and spike’ activity. If you don’t use the Guard, you’ll probably need larger ASIO buffers up front depending on your audio device, processor, memeory, etc…as the project grows, you might need to increase the size of those ASIO buffers.
I also got spikes (and audio stutter), even with small projects. Real time at 5% and avarage load on about 40%.
I am hunting for plugins that might be the cause. But I suspect it is the graphics or other issues within Cubase 8.0.20.
PS. Not the same problems with Studio One 3 or Reaper 5.
Anything on the mouse movement/graphic card hickup? Or is it just a rumour?
I have a nVidia card with the latest driver (i think), GeForce 340.52. Any problem reported? I know there was a no go for the latest driver some time back.
What happens if you disable ASIO Guard and go with ASIO buffers 256kb and larger?
In my case, CuBase with ASIO Guard on is the ONLY DAW I’ve tried where I can use Buffers below 128k. Reaper’s demo did really well on my system as well, but even there I needed larger buffers out of the gate.
With the Avid stuff (Sibelius) I tried, I had to crank the buffers up as high as a megabyte before VST plugins were solid performers! With the large buffers, it started working quite well.
I’ve also run into issues with some models of SATA3 SSD drives (PNY). I’ve no idea why, but plugins report disk loss errors and produce clicks/studders when trying to stream from them! Didn’t matter which DAW, or even in stand-alone modes. Tried the drives on multiple host-controllers and such…they just don’t want to work well streaming samples, or as system-pagefile drives. I got rid of those drives, and even with slower/older SATA2 stuff…my ‘vst glitches’ went away. I’ve since moved to Samsung for my SSD media, and gone back to some older Raptor class SATA2 stuff I had sitting around for larger audio tracks…smooth sailing since
CuBase 5 should be under the “Unsupported Products” tab.
If you need to go ‘way back’ on Steinberg software/drivers (Atari and DOS days), they also have a tiny ftp server link at the very bottom of the downloads page.
Regarding viewing the crash.dmp files that can be found in:
%USERPROFILE%\My Documents\Steinberg\CrashDumps
You can also sometimes find various text based logs that might be helpful in the different directories found under:
%USERPROFILE%\AppData\Roaming\Steinberg
These can be opened with any text editor.
For me, it’s pretty normal to find things unassigned, or hooked up wrong when I load up an older project (sometimes even from the same DAW version/installation!), where I was using totally different devices and plugins. In my case CuBase typically throws up the “VST Connections” window with things highlighted in red that can’t be assigned properly. At that point I have to point it to compatible devices, or leave them parked (unconnected).
In the case of missing devices or plugins, it still gives my track and lane data…it just might no longer have any input/output assignments (or the wrong ones).
Sometimes the project loads, and finds what it thinks should be a valid/working plugin (I.E. Wrong version, or maybe a plugin looking for a patch or library that no longer exists on the system). When it hands that plugin commands to load and initialize itself as intended…the plugin just might crash, and in some cases might bring down CuBase with it.
Examples:
[*] Maybe I made a project with an older version of ARIA player, that is now updated and different.
[*] Maybe the project calls for a vstpreset that’s asking for a patch or preset in the plugin that has changed or no longer exists.
If you suspect a plugin might be crashing right out of the gate…try disabling ALL of the plugins in your VSTPlugin folder, and loading the project again. Of course it won’t be able to find the VST/VSTi plugins, but at least you’ll get messages to that effect instead of a CRASH. From there, you can reactivate plugins one by one until you find the culprit. (Note, always make sure to keep an untouched copy of your project somewhere as a backup…don’t be afraid to save more copies as you trouble shoot and make notes as you go).
So far in these cases, I can usually close out the problem plugin, save a new copy of my project, reopen it, and then rebuild the plugin instance.
Example:
I once tried to open a project that used an SFZ patch I had made to work with the ARIA player. Not only was the project built with a much older version of the ARIA engine, but I had also added and removed various patch libraries since making the problem project! When CuBase asked ARIA to open up all its patches, ARIA never found what it needed and became fundamentally broken. It was bad enough that it would throw up error messages and bring down CuBase when I hit ‘play’. At that point, I cleared the problem patch (discovered by looking at the ARIA engine crash logs), saved my instrument set from inside ARIA itself, exited the ARIA instance, and saved a new copy of the CuBase project.
For good measure I closed out CuBase, rebooted the system to start fresh, loaded my new copy of the project, checked the connections and let it roll a few bars in case something else is wrong as well, started a new ARIA instance, reloaded the instrument set, and at that point everything worked but my ‘missing patch’. Alas! I had remembered to save a copy of my missing SFZ along with the project…so I put that back into ARIA properly, and went back to work.
What if ARIA (or any other plugin) were crashing at a point that I couldn’t even see any useful error messages or get the project loaded, let alone salvage any of ARIA’s settings? That’s the point that I would have done as mentioned earlier, and deactivated ALL of the VST/VSTi plugins in CuBase, then methodically reactivated them one by one until I found the culprit. Etc…
You might need to save several copies of your project as you go…but the general idea is to pull out as much information as you can about what all you were using in the project last time it worked, and how things were set up in case you need to rebuild some plugin settings from scratch (or roll back to previous versions…install missing libraries, or whatever).
The point is…if a project loads, but doesn’t ‘crash’ until you try to play the project…you might be able to recover most of the project by weeding out the plugins and stuff one by one (and preserving as much as you can of that work in the process). If you can’t recover any data from the plugin, you can at least get the project loaded without the bad plugin information and rebuild that instrument later.
If it’s crashing out of the gate on you despite having launch a clean CuBase session (no VST/VSTi plugins active), and does the same on other systems, then I suppose rolling back versions until you can get the project open at least long enough for data salvaging is about all one can do?
You might find some other CuBase users you trust enough to try downloading your project from somewhere and opening it on their system.
These days, before I pack up a project for storage, or before I ‘update’ any of the software/plugins/or the OS itself, I take a moment to export all of the elements of the project (track by track, preset by preset) into the project directory. I’ll drop a text-file in the project directory that tells what plugins/patches I was using along with their version numbers.
If it’s a really important project that I know I’ll need to pull up again at some point…I just go ahead and clone all relevant partitions in the entire system to some backup media (or better yet a plug and play drive)…OS and all!
I like to make a second copy of the system partition, one that’s an identical clone, and second copy that’s had a sysprep run on the system partition (in case I have to run it on a different motherboard). While it might not be practical for you now…in the future, consider only purchasing an enterprise license of any OS you buy…that is NOT locked only to a specific motherboard. The idea is…you want something you can run a sysprep on and put in the closet, so you could hopefully plug and play it in any motherboard that’s relatively close, but not necessarily ‘a perfect match’ to what you made the project with.
What’s a $90 hard drive compared to weeks or months of working on a project?
I’m a computer hobbyist, in that I’ve built all my PCs for over 20 years. Used to be, I’d have fun trying to trace all this down, etc. For now, I’m just wanting to make music, and I’m tired of all this. C8 SERIOUSLY slowed my system down. I’m back to using C 7.5 for now, but I’m considering other options.
Nothing wrong with having more than one DAW (a plan B) at your disposal. Can’t say I blame you for being upset either. It is indeed very frustrating. I can pretty much assure you that similar things will happen with any of the DAWs and complementing software on the market. They’re always leapfrogging each other on stability or some feature set, and they’re always fighting many of the same personnel, technical, and economic issues.
Even in 2015 I sometimes find it better to pull out older ‘less digital’ gear. The more complex these systems get, the easier it is for the tiniest little thing to toss an expensive glitch in your production.
Over my 25+ or so years of working with many products/companies to produce digital video, audio, and midi, I’ve yet to come upon a perfect solution that works well at every single release/version with every random configuration of gear and software. Even in million dollar pro studios, running all enterprise class ‘stuff’, with tech-support hot-lines and full time engineers on staff…sometimes things just don’t work so well so they quickly (and hopefully unnoticed by the studio client) go to plan B and keep right on ‘creating’.
Long ago I learned to clone my system on a regular basis. If I need to roll back to an important project, I just swap out the entire hard-drive. Decent speed hard drives are fairly inexpensive these days, so any moderate to serious DAW user should probably have a couple of nicer system drives to rotate out, and plenty of backup storage for archiving partition clones. It’s a very worthwhile investment. Even if you’re on a tight budget in a small home studio, it’s not a bad idea to at least stay one backup deep with a plug and play solution.
Try the demos of new stuff in your spare time, on a clean system drive/partition, that way you don’t unwillingly destroy your former environment workflow, or prematurely spend funds on an upgrade you can’t use right away.
In the past few years in particular, we’ve seen quite a few revisions in how motherboards are designed (different ports, speeds, memory types, and lots of emulating and bridging hardware busses into a single chip-set that often don’t work so well with older drivers). There have been several OS roll outs (Windows 7, to 8, to 10, as well as a few Mac OS upgrades). To top this off, there’s tons pressure to make hardware more ‘green friendly’ and even run for 12 hours on battery power (portable PC revolution)! That means more and more hardware is designed to go into low-power states that simply aren’t suitable for DAW use yet…so we wait for drivers/methods to force that hardware into a performance mode, then find it needs extra cooling to run that way (or simply can’t do it for very long without shutting down, throttling back, or even frying)…etc. People do still have lots of really nice ‘older gear’, but no ‘drivers’ for the newer OSes and motherboards are likely to see the light of day for reasons I’m about to rant about in the next paragraph.
There also seems to be a trend for the consumer/budget user in the way hardware companies put together a project. They’ll ‘contract’ an international team…put together the design and software/drivers (usually mostly based on the reference kit that came with the chip-set)…do the production runs…put it on the market for dirt cheap…and that’s pretty much the end of it. The design team might then be instantly disbanded and everyone goes back to where-ever on the planet they live, and they take on new jobs/projects that can make it nearly impossible to invite them back on a contract to do new drivers or custom BIOS tweaks. Even the production facilities are big ‘mobile camps’ that can move around the world at the bat of an eye. The plus side is: “It cheap…no work? Just by another!”. The downside is…it’s sometime impossible upgrade software and find driver updates and such…so…
It gets insanely annoying for the average budget-small studio owner. All this has occurred in a fairly short time period, all at once, and all with enough differences to break tons of software/drivers. With all of these changes, and so many people and companies involved with the process…issues are destined to pop up for a larger number people. It’s pretty amazing any of it works at all!
Probably more than ever, it’s important to demo things in an alternate setup (I.E. clone to a new hard-drive and put your old one in a safe place) and give things some time to settle with all the Windows 7 and 8 to 10 transitions going on.
There is a Horrible Video Lag happening now when I drag or move parts
Also my PD and AI Controllers no longer function. They still light but Cubase no longer accepts their Messages.
Sprinkle in a couple of snaps and crackles and well…
Once again, Gotta roll back to 8.o1.
This one is UNUSABLE. for me. YMMV
Video to come about the Video lag issue.
Also, gonna uninstall a few things …some driver checks and will report back
