I used to have the same problem with 10.5 at my old computer.
I found that the more I worked on a track, right near the end of the whole work, the session would start having some serious issues, running slowly, would have pops and crackles (which most times would disappear when I would highlight a disabled track (???) and one of the bugs was that the write function would get stuck.
When I would start working on a track, even with heavy instruments and effects, all would run fine for a few firsts sessions in the same Cubase file. The more I worked (not necessarily adding instruments/plugins) the worst the situation got.
It’s definitely a Cubase issue. A MIDI loop is unlikely, because the issue wouldn’t happen at the beginnings of my work on said Cubase constructs. It must be a program bug.
I think Martin is onto something, especially as he has seen cases where this is the issue before and my issues only started after I installed loopMIDI. Doesn’t explain why its happening now that I’ve uninstalled it but maybe something is hanging over. I’ve never had this issue until recently.
Martin … to add meat to this … from my experience, once it starts locking in write mode, the only way I have reliably found to stop it is to reload the project.
The current project I’m working on is using my KeyLab 88 with DAW controller mode active through Mackie Control. I am also using the Android tablet to control CC information (ie sending CC1 and CC11 - pure MIDI no “DAW controller” parameters)
Yesterday it locked in write mode once. I restarted the project (not Cubase - just the project) and it went away.
I’ve been working on the same project this morning for about 90 mins and have no issues.
Hi Martin. yes correct. I was using one for in and one for out. I have since deleted the loopMIDI application (a week or so ago) and removed the ports from Cubase. The ports no longer show up as valid MIDI ports in Cubase.
In my current config I do NOT have my tablet attached, and I have removed the Mackie Control setup for my Keylab, so the key lab is now operating as a bare bones MIDI controller and I still have the same issue occurring sporadically.
Today I had a project that refused to move past this stuck write mode when restarting the project. If I close the project and reload it the stuck write is gone but on the very next write pass it one again sticks. This was repeated 6 times. each subsequent write would stick.
If I unplug my Keylab completely I still have the same issue.
If I quit Cubase and restart it, the project behaves.
If I now quit Cubase and restart with my Keylab plugged in it now behaves.
I totally understand your reasoning for thinking this is a MIDI loop issue, but I’m struggling to see how it could be with all external devices unplugged.
Appreciate this is frustrating and hard to track down and appreciate your efforts.
Martin is correct … you need to configure two ports in loopMIDI one for in one for out. Unfortunately I couldn’t find this info on the loopMIDI website but the website for the Stream Deck Cubase plugin does contain a page that shows how loopMIDI must be configured → StreamDeck Cubase plugin information
Unfortunately there are devices (like SSL DAW controller) which are using virtual MIDI Port (loopMIDI) and require the very same MIDI Port as In and Out. Then they make the MIDI loopback. And there is no way around.
But if there is some hardware that requires only 1, doesn’t this lead us back to Steinberg finding some kind of solution to avoid the automation system from getting stuck in that state, regardless of the cause of it? Moreover, it seems like it’s happening for reasons other than LoopMidi.
I know Martin has done more digging on this so I could be wildly wrong but the stuck write has occurred for me with no hardware plugged in at all, so I’m not sold on the MIDI loop. Also if that was the problem I would expect it to be repeatable under the same conditions.
I get the logic behind a timing issue, but I’m struggling to figure out why it would be so inconsistent. If it was an erratic timing issue you’d expect it to be random (even if the timing issue doesn’t trigger all the time).
The fact that it happens in batches and then goes away … sometimes forever … is the weird one.
I have no hardware except a REALLY basic cheap Midi Keyboard (Swisssonic EasyKey 61 ) and a sustain pedal plugged into it.
I write automation by hand via mouse 100% of the time.
I never heard about midi loop but I did have Divisimate installed and I remember something related to “loopback” as part of it’s function.
I also have loopback active on my audio interface driver but seems like that’s not meant. When I turn it off the issue remains.
BUT!! I recently did a full system reset (wiping out everything except my personal files including divisi mate and can’t find any files called midi loop or loop back in my entire system - searched via the software Everything)
and after just 2 days after the reset and while starting my first project just now I get that issue within a few minutes of working on the project. That’s the first time I wrote automation on a freshly installed system and I get the bug!
Interesting detail: Whenever this bug occurs I’m unable to use the undo and redo function.
As soon as I disable/enable the affected the track the undo function back too alongside getting the automation “unstuck”. However it keeps happening on every track in the same session as others have reported. And if it happens on multiple tracks the undo/redo function only comes back when all tracks have their stuck automation resolved.
Video here of the whole nonsense.
If I do other tasks afterwards like adding a track it shows that I added a track in the history but I can’t undo it. Not even from within the history. It all starts working again after “unstucking” the automation on the tracks.
This is an extremely weird detail and I wonder how hardware could ever make core features of Cubase vanish and then pop back up disabling/reenabling the track.
It’s a fresh system basically with nothing except browsers, backup software, 3 versions of Cubase installed via Steinberg Manager (for testing - I have tons of other issues).
It might be better to redo the automation made while having the bug.
In my case it causes a huge amount of nodes/dots. It seems this can cause problems.
In the automation panel “settings” I adjusted the node reduction level from 50% (default) to 0% so I get as many nodes as possible for a lot of detail - many nodes like in the case of the bug where I got tons of nodes even with the 50% reduction level. It kinda bypasses the reduction which is another weird detail.
But now that I turned off the reduction manually I immediately got trouble with plugins reading the automation in the new mode with many nodes. One plugin didn’t read the automation at all till enabling / disabling the track. It was NOT stuck in write mode.
Another plugin also didn’t read the automation till I opened the plugin! Just opened it!
It was also NOT stuck in write mode.
Although I get such a crazy variety of crap with Cubase and other plugins that I might just be cursed and you can disregard all that.
I’ll at least always redo my automation from the bug, even if it’s not stuck anymore since that somehow doesn’t seem to matter.
EDIT: I still have the problem with the one plugin (Movement) eve though I removed the many nodes and redid it. Not completely from scratch but there are only 4-5 nodes per automation lane rather than hundreds. And it still only reads when opening the plugin. So it might be a plugin issue.
Not sure about the other but just mentioning it = Valhalla Space Modulator. That automation works after redoing it. So, not sure if it’s plugin bugs or down to the many dots/nodes.
So I guess if you get the bug only every once in a while it might be safer to redo it without too much hassle. If it happens all the time… DECISIONS…
What a “professional” software.
Little update on this - the automation lock bug always happens on the SECOND project I open for the day. The first is usually fine. The second, on the other hand, will not connect to my Komplete Kontrol keyboard and immediately exhibits the bug when entering write mode. Closing and re-opening Cubase clears the bug.
Let me know if anyone can reproduce this, particularly if you use Komplete Kontrol keyboards.
Ok, after more testing, this bug is 100% reproducible now on my system. I open one session, automation works fine, and Komplete Kontrol keyboards connect to Komplete Kontrol Software.
Close that first session, and without restarting Cubase, open a second session; Komplete Kontrol keyboards will not connect, and any automation triggered anywhere (using komplete kontrol keyboards or not) will immediately be “stuck” in write position.
Workaround is to always close Cubase before opening another session, but curious if anyone else can reproduce this behavior. Now that it’s reproducible maybe we can get it fixed.
Can’t reproduce, despite having bug occasionally. I also doubt it has anything to do with that in my case, since I almost always force quit Cubase since it barely ever closes on it’s own. And it’s extremely unlikely I ever open another project without restarting Cubase for that reason.