[2.2.80][2.2.82] CPU Usage High After Switching Song Parts/Songs

VST Live
1

I have been seeing this behavior where after changing from a somewhat VST heavy song to a lighter song that the CPU usage does not drop and stays the same. So there is a CPU usage build up over playing songs.

Basic steps to reproduce:

  1. Open a project with 2 songs 1 empty, 1 with parts/single track/shared layer(s) throughout all the parts.

  2. Switch between songs.

  3. When on initial project load switching between songs is ok. CPU usage behaves as expected. After just changing parts in the non-empty song, switching to empty song CPU usage does not drop to zero/minimal.

This might be related to this reported issue:

Issue from [2.2.21] to [2.2.32] cpu bar go to full switching more song - crackle - no reset - VST Live - Steinberg Forums

And here is a video with the behavior, on my main project where the CPU usage is very apparent:

https://youtu.be/clwT3Ck4zE0?si=CoNx-qG8y5hlUa6R

And here is a clean project, not much cpu usage/leakage but it is still there.

https://youtu.be/iVGaCYRSI5A?si=pWmKt392bTde3Pbb

I saved this newly project in the video and restarted VSTL and opened again. Just changing songs no CPU build up. But once any parts in the non-empty song is selected or transport initiated, moving to empty song CPU usage appears.

1 Like
2

Forgot to mention that this happens on 2.80 and 2.82 Windows. I will check on Macos as well hopefully tonight.

4

I tried UAD PolyMAX Synth and it alone took 50% of CPU.
So the UAD instruments for use in VST Live is total dead end. Don’t use them. If you don’t play them live, then render them and insert audio.

To answer to your question - I don’t have such behavior you have. One song loaded 4 layers where one UAD instrument takes 50% CPU, but 2 Halion and 1 Kontakt takes less than 1%, then switching to empty song frees CPU meter and it shows no activity. So the problem is somewhere else, not in the area you showes in video. Do you have something in Mixer loaded in global channels like groups or main out?

1 Like
5

Same thing happens with just single aurturia piano v3 it is just hard to show since its not much load.

I put opal just to be able to show some meaningful load on the cpu meter.

I will try to replicate it without using uad and on Mac as well when I get back home.

In the second video it is just a clean new project just clicked new and started recording.

The issue is not high cpu usage, it is as if vstl somehow can’t release resources from previous song but only after transport.

If you just select songs without transport it releases the resources..

It is one of those hard ones to explain and show :frowning:

6

You did Preload/Autopreload. This is why VSTL “can’t” release resources. All those hard plugins are loaded in memory even if you switched to empty song.

In Cubase we see that VST3 plugin don’t eat resources while it’s idle. I’m not sure if VSTL can do the same in situations when there should be zero delay on song transitions. So I wouldn’t say that this is bug.

In this case the release of resources when selecting songs without transport could be a bug or realised VST3 idle feature.

1 Like
7

My understanding was that when preloading we are just putting all the needed plug-ins into memory ready to go but in a non-processing (frozen?) state. So that when you switch a song with a VST which needs to load a 10GB sample library or checks for online license you don’t wait for that on song load.

Again, I thought this is one of the main reasons why we don’t have seamless song changes. If everything is active all the time a song change becomes pretty much a glorified part change, no?

While looking at my problem a little deeper I found another issue which might be related to this:

From what I gathered from @musicullum’s post here and others:

Feature Request - Enable/disable layers - #2 by musicullum

In a hypothetical 3-part song with all shared layers, if I want piano + pad in part 1, only piano in part 2, piano + pad in part 3. There are 3 ways to go about this:

  1. Remove the pad layer from part-2: This keeps pad layer active in bg, disables input, but keeps sustain.

2-1-2 RemLayer
2-1-2 RemLayer1920Ă—399 138 KB

  1. Mute pad layer in part-2: This freezes pad (stops processing) until unmuted in part 3, no sustain, abrupt sound loss and possibly abrupt sound from sustain when unmuted

2-1-2 MuteLayer
2-1-2 MuteLayer1920Ă—399 149 KB

  1. Bypass/disable layer in part-2: Same as 1, but you can assign this to a cc from actions&shortcuts so you can then mute/unmute manually keeping sustain while playing the part. (Needs confirmation)

2-1-2 BypassLayer
2-1-2 BypassLayer1920Ă—399 147 KB

Now 3rd option is quite recent for me and does not actually work how I expected it to work. Even 2. option (muting) made me doubt my understanding. Let me explain:

If the pad layer is muted in part 2, when moved to part 2, cpu usage drops very late as if the process is not frozen but only the channel is muted + input disabled while sustain still happening on the bg.

If bypass/disable is selected for part 2, when moved to part 2 nothing happens, pad is still active and playing. But while still in part 2, selecting/deselecting bypass manually works.

Here is a video showing these two behaviors: (start around 1:25 mark to skip creating of the new project)

What I’m suspecting is, maybe while implementing this “bypass” option to layers something creeped up and broken the freezing of VST’s on song change. Since to my eyes now both mute and bypass functions are not working 100% as they should.

Then again, I might be completely wrong about how they should work. If someone from the team be kind enough to look and confirm it would be highly appreciated. @musicullum @Spork.

8

Further testing results:

Mac OS 2.2.80: Same behavior, resources are not released.

Went back and installed 2.2.10 on Windows. 2.2.15 is the version where layer bypass is introduced. So wanted to see if my suspicions were correct.

  • On song switch all resources are released on 2.2.10
  • Did the mute test again on 2.2.10 and switching to muted part very quickly releases resources, instead of sustain processing happening in bg.

Then installed 2.2.20 and guess what, 2.2.20 does not release resources on song change as well.

So:
2.2.10 → No Problems
2.2.15 → Layer Bypass introduced (can’t test no download available)
2.2.20 to 2.2.83 - > Resources not released on song change. Mute & Bypass not working correctly

I’m strongly inclined to say that the culprit is something got broken when layer bypass is introduced and this has been going on for a while. I haven’t been using VSTL between 2.2.3X - 2.2.80, but I see that a lof of CPU threads after 2.2.15

Specially this thread seems to have a similar observation about song switching and resources not releasing, some improvements made in later versions, but no one identified what I see.

Issue from [2.2.21] to [2.2.32] cpu bar go to full switching more song - crackle - no reset - VST Live - Steinberg Forums.

9

a) not everything is active, it is loaded and ready for activation (which should happen in no time)

b) unfortunately you couldn’t be more wrong. Each Song needs to have at least a dedicated Transport system, tempo Map, Mixer, and some other assets. Remember each Song is like an entire DAW (like Cubase) project. 2 Songs playin concurrently is quite a challenge. But we have it on the list.

10

As for the shared Layer not stopping, that should work again with the next version, thanks for helping with that. Let us know how that works out for you then.