Am I th eonly one haveng problems with soloing a track since Cubase updated to 12.1?I had no such problems before. My computer data is below, Windows 10 operated.
Best regards
Stefan Sinko
Best regards
Stefan Sinko
Hi,
What kind of problem do you have, please? Could you be more specific?
Hi! The specific problem is that if I have a track soloed, in the project window, it works for like 1-2 minutes, then it goes silent, though the project "plays on ", so to say. By the way I have UR242! If I stop the soloing, then everything is OK. If I press the solo button again, the problem also starts again after 1-2 minutes. If I mute instead, there is no such kind of a problem.
Hi,
It seems there is a performance issue when solo a track. There are users experiencing drop outs when solo. It seems you have the extreme case.
It surprises me that a solo track uses up more of computer performance than all tracks together in the same project?.. I was about to guess a bug, but I am not a professional.
Anyways, thanks!
Stefan, Your processor, AMD A10, does not have the power to run Cubase properly. It is fine for email, browsing or word processing. I’m afraid you’re going to be very frustrated trying to use that system for digital audio
I had the same problem with soloing a track. When I changed from 32 to 64 bit float in system set up, that seemed to solve the problem.
This issue is already confirmed.
It’s related to the solo function, but doesn’t appear on all systems or in all situations.
We (some users in the German forum) try to find the reason for the bug,
but couldn’t narrow it down at the moment.
This doesn’t help in all situations.
The discussion in the German forum:
What does latency mon say.
I agree with @Randy_Livingston , with such a CPU, you will be limited very quickly, and it is far from delivering optimal performance.
Hi there !
After thorough investigation, I’ve came to the conclusion that this issue can only occur when there are FX Tracks/Sends in the project, but please read the post entirely to understand !
The issue isn’t actually triggered by using Solo, but on the contrary, when no audio is playing.
However, Solo (and more importantly, Mute) still plays a part in the issue but you’ll learn more about that later in the post.
Here’s the ultimate proof :
For instance, I used the Demo Project by Mendel Bij De Leij - MIXED.
This is important because this particular project is set up in such a way that the issue will occur.
Required step :
- After opening the project, play it for a few seconds then stop. This is required to “activate” the audio engine (don’t ask me why, but if you don’t do this, the issue won’t occur with the first test).
- You can eventually press F12 to bring the performance meters.
With Cubase idle (transport on Stop position)
-
After a moment, usually less than 2 minutes (that time seems to be fixed), the ASIO-Guard meter will start ramping up on its own, though this process takes only a few seconds. After hitting the ceiling, the three meters will go down to 0. The red overload indicator will show up, but if you click to reset it, it will come back immediately.
-
Cubase is now in a glitched state and will stutter heavily. Try moving the performance meters around, scrolling through the project or resizing tracks and stuff. The stuttering is occurring in a fixed pattern. When Cubase is in this glitched state, CPU usage will greatly increase, as will the temperature, because the clock will get stuck to its maximum. This kind of CPU behavior is usually due to a memory leak or an instruction that is stuck in a loop.
-
- When Cubase is in the glitched state but no tracks are Solo, Playing the project will immediately remove the issue.
-
- If at least one track is in Solo, playing the project won’t remove the issue. It will keep glitching until you disable Solo.
-
- Muting the Output track (muting every track) before playing the project won’t remove the issue until you Unmute the Output track.
-
- BUT, when the issue is still occuring, and a track is in Solo state, clicking Solo two times on the Output track will set all the tracks to Solo and remove the issue ! That’s why I think that this is more an issue with Muted tracks rather than Solo, although Solo is definitely involved.
The issue above occurs whether the tracks are Solo or not. There is absolutely no difference between leaving all the tracks unmuted and enabling Solo on one or several tracks.
Toggling Mute/Solo on tracks during the “build-up” time doesn’t delay the issue, it will always happen after a fixed time, starting from the moment you Stop playing the project.
However, it is important to note that when a track is Solo when the issue occurs, it prevents the issue to be cleared out, but only if Muted tracks are also present along with the Solo tracks.
With the Project Playing (transport on Play position)
-
Enable Cycle to loop the project.
-
Solo a track and Play the project. I doesn’t matter if you Solo the track before or during playing.
-
After a moment, the issue will start occuring and the audio will cut out.
-
- Like in the idle test, the issue can only be removed by completely disabling all the Solo states. If you Stop and Start playing again while some tracks are still in Solo, the issue will remain. When the project is playing, the audio will come back as soon as you put the last remaining track out of Solo state.
The issue can also be triggered the following way :
- Mute the Output track (that causes all the track to get muted)
- Then Solo the Output track (all the other tracks should stay muted)
-
- However, when the issue is triggered this way, it doesn’t go away by clicking the Solo button like we’ve seen earlier, because doing so will switch it to Mute. The issue actually goes away when you Unmute the Output track. As long as the Output track is Muted, tweaking the other tracks Solo/Mute won’t do anything and the issue will remain (probably because no audio is actually played internally).
The issue does not occur in the following situations :
- When ALL the tracks are set to Solo, either by enabling Solo from the Output Track or by switching them manually.
- When all of the tracks are Unmuted (no Mute, no Solo).
- When tracks are Muted and there is no Solo.
- When Muting some tracks from the ALL Solo state.
Additional testing :
- The issue also occurs when you play an empty space of the project, and then it doesn’t matter of the tracks Mute/Solo. It’s the same as leaving the project on Stop position, because no audio is actually played.
However those findings are good because when the issue is happening and you play through an empty space, there is no way to clear out the issue. The only way is to move the project Cursor to a place where there is audio content, and eventually disable Solo states if there are any.
- One way to remove the issue is to change the buffer size. That causes the audio engine to reset and the issue goes away.
- Changing the ASIO-Guard settings did not help.
- Disabling ASIO-Guard did not help. The only difference is that on the Performance meters, it’s the Realtime and Peak meters that will go up and then they will be stuck to the maximum instead of going to 0.
- Removing track inserts did not help.
- Disabling channel EQs did not help.
What prevents the issue from occuring :
Certain plugins in FX Tracks !
Trust me or not, but yes, that was the trick !
I first tried deleting the FX Tracks and immediately noticed that the ASIO-Guard load was lower and steadier than when the FX Tracks were present.
Without the FX Tracks, the issue was impossible to reproduce.
I have narrowed it down even more to the RoomWorks plugin. An FX Track that contains RoomWorks is the actual source of the issue ! Without deleting the FX Tracks, if you bypass the FX Track containing Roomworks, then the issue is gone !
I’m not telling that RoomWorks is the only plugin causing the issue, in that particular demo project, that was the cause of the issue. Maybe other plugins can also trigger the issue.
And maybe, the cause of this issue isn’t even related to FX Tracks and certains plugins, because the issue is not there on the UNMIXED project, although it contains the same FX Track with RoomWorks.
So, I let you guys decide. I worked on that one for almost 10 hours and that includes the time spent to write this down.
I don’t want to hear about this issue anymore. I’ve had enough. Just joking, seriously, this one was a pain in the ass to troubleshoot because we have to wait two minutes everytime we click on something.
More seriously, appart from those issues we are currently experiencing, Cubase 12 performance is insane, I must admit it. I can run projects with a hundred tracks and the CPU doesn’t even flinch. I wish you the best luck in fixing that. Cubase really is a great DAW, but the bugs guys, the bugs.
12.0.20 Update :
The glitch issue doesn’t happen anymore.
However, something else persists.
Still in the same demo project and with the transport on Stop position, the VERB FX Track containing RoomWorks is still causing a bit higher ASIO-Guard activity. If you bypass the FX Track, the ASIO-Guard meter will stay lower and be more stable.
If you add several RoomWorks in the FX Track, the ASIO-Guard usage will go even higher and as soon as you bypass the inserts, the usage will instantly go back down. This becomes very obvious if you do that.
If you add several instances of RoomWorks on a normal track instead, the ASIO-Guard charge will never go up like that. It will go up only when playing the project.
We know that VST3 plugins save processing power when you don’t play any audio and they aren’t bypassed. Therefore inserting many plugins on an Audio Track won’t increase CPU usage until you start playing the audio.
I took RoomWork as example, but it does that with any plugin. RoomWorks is actually a bit CPU heavy, that’s why it was obvious with it, but if you put any CPU demanding plugins in FX Tracks, it will do the same.
In conclusion, plugins that are inserted on FX Tracks do not go in power saving mode. And this is an issue.
And that probably was the cause of the glitch issue explained in the previous post. There is something wrong with the VST3 power saving mode when they are inserted in FX Tracks. Something was getting stuck in a loop internally and was causing Cubase to glitch after a certain time.
I’m sure that I’m into something with this one.
It is reproducible in any project.
This is important to say that Windows power plan is set to Normal so the CPU clock can move.
If you set it to High Performance the clock goes to the max and you can’t really see any change in the ASIO-Guard meter, but it all depends on your CPU.