I’m encountering what appears to be a runaway real-time processing loop in Omnivocal when used in Cubase 15 (latest release).
Reproduction steps (100% consistent):
Launch Cubase 15 (latest release)
Create a new empty project
Add an Omnivocal Instrument Track
Open the Omnivocal editor
Insert a single note using the editor
(The transport is never started at any point.)
Observed behaviour:
Cubase Audio Performance meter immediately jumps to 100%
The peak indicator is hit
The meter continues to bob at very high load indefinitely even though:
Transport has never been started
No audio input is present
Monitoring is off
Closing and reopening the project causes the Audio Performance meter to spike again immediately on project load
Disabling the Omnivocal plugin instantly returns Audio Performance to zero
Freezing the Omnivocal track also immediately returns Audio Performance to zero
ASIO-Guard:
Behaviour is identical with ASIO-Guard enabled and disabled
Expected behaviour:
With the transport stopped (or never started) and no audio input, the plugin should enter an idle state and release the real-time audio thread.
Why Freeze is not a usable workaround:
Freezing the track does return Audio Performance to zero, but this is not a practical workaround. Omnivocal becomes unusable in its intended role as a real-time instrument. Freezing only demonstrates the fault; it does not mitigate it for actual use.
What this suggests:
Omnivocal appears to continue executing real-time DSP / inference while idle
The behaviour is triggered by editor note entry
The plugin does not appear to exit its processing state
Offline rendering (Freeze) behaves correctly, suggesting the issue is confined to live real-time processing
This is not a general “AI plugins are heavy” issue — the load persists indefinitely while idle, transport stopped, and with no input. Cubase itself appears to be behaving correctly, as removing, disabling, or freezing Omnivocal immediately resolves the issue.
Happy to provide full system details if required — the issue reproduces reliably in a clean, empty project.
Update: Increasing the ASIO buffer size to 1024 samples allows Omnivocal to idle correctly (Audio Performance returns to zero).
However, at normal working buffers (128–256) the Audio Performance meter immediately hits 100% after entering a single note, even with transport never started.
This suggests the plugin’s real-time processing requirements currently exceed what is viable for interactive use, rather than a permanently runaway loop.
You don’t mention the specs of your system, but I haven’t seen that sort of behavior with Omnivocal on my system (Intel Core Ultra 9 285k, Windows 11). I’ve mainly used it at 96 kHz, and I generally set sample buffers at 256 for tracking (which is equivalent to 128 at 48 kHz with respect to latency). Though I haven’t used it much, I expect to try it again on my latest project in the relatively near term (maybe as early as later today).
Note that, if you’ve got the Omnivocal instrument track having the focus, unless you have a different setting than I do for instrument tracks and monitoring, Omnivocal will be in the real-time thread because it has to be ready to play sound if you play a key on a MIDI controller. It doesn’t need the transport to be running to do that.
FWIW, I did finally get around to using Omnivocal again on my latest project. I added four instances, two with the female singer and two with the male, all for doubling my own background vocals. I did not see any CPU spikes. I should make the caveat that I was working at mixing latency, but also with loads of plugins active, including a CPU hog mastering plugin, UAD Sound City Studios on most of the instrument tracks, etc. But I haven’t noticed issues in past uses when I was working with tracking latencies (but I also was likely only using one Omnivocal track at a time, and not a lot of other heavy CPU plugins, in those earlier contexts).
My specific use case here was to use VariAudio to extract MIDI from my real background vocals (which had already been tightened against the lead vocal and tuned), then use the Key Editor to clean up the MIDI as needed while entering the lyrics. That took a while, mainly because of the amount of MIDI cleanup needed. Once I got everything as good as it could be at that level (i.e. with live OmniVocal tracks with lyrics and plugin settings as I wanted them), I rendered all the OmniVocal tracks to audio, not due to performance considerations, but because I wanted to do further work on the audio tracks. Specifically, I used Waves Sync Vx to tighten timing and pitch of each rendered Omnivocal audio track against the live background vocal track whose I’d used with VariAudio to get it’s MIDI data. (This was largely working around the inaccuracies in the MIDI extracted from the audio.) While that was probably a lot more work than using one of those plugins (or online services) that simply changes one voice into another (e.g. IK’s ReSing), I don’t have any of those, and this worked well enough. I do expect to use the Omnivocal parts to layer with my BGVs when I mix the project.