Issue 1.1.54 cpu bar asio is full range - panic don't go - stack mute must reload

ISSUE 1.1.54 CPU BAR ASIO IS FULL RANGE - PANIC DON’T GO - STACK MUTE MUST RELOAD

Same project, same latency buffer asio, 1.1.53 go well, cpu bar is just at the start.
install 1.1.54 and same condition, cpu bar bump to full scale.

tried more buffer, nothing change, after few minutes, it goes down.

Or without preload, but in 1.1.53 preload was on.

Panic button , or changing buffer asio (ur44-steinberg) mute all stack, must re-connect.

As it happened some weeks ago with many previous version.

please check

1 Like

The same happens to me.
Another problem, the output of the stack appears duplicated. The bass, for example, I have it assigned to an individual output. but it also plays sound through the main output. I have to disconnect the output of the stack, then reconnect it and it is fixed there.

Same here.
Edit:
I have tried starting a brand new project and loading up an existing song from the misbehaving project and that seems to be working ok (In fact the issues with interrupted backing rack when parts changes seems to have been fixed which is great.)
I will likely recreate the whole project from saved songs and if that continues to work I am happy tbh. Fingers crossed.
edit2:
Spoke to soon sadly. As I have loaded a few more songs into the new project the paused backing track issues seems to have returned. :frowning:

Unfortunately, you are correct. While trying to make things right, one output was added too many, sorry. Will fix asap. Temporarily, re-assigning the Stack channel output should work, but you’d have to do it each time after loading a project.

Sorry to hear that.
What is your system? And you said “or without preload”, does it mean it only happens with preload activated? And finally, do you use Stacks, and/or Global Part (and Global Stack)?
Thank you very much for your cooperation!

WIN 10, ur44 yamaha asio driver.
it happen with preload activated opening project. So , when preload is not activated, CPU go down, as previously version.

Mean bar cpu appear totally on the right, opposite empty, on the left. (speaking about 128 low latency (5ms about in+ 5 out). But works in less. (32 standad, mean 2-3 ms in and out).

While with preload activated, buffer 2048 stable, 50+50 ms… change nothing, clip and application unresponsive.

And Starting without AUTO PRE LOAD, ,if I preload manaully (mean open preload and click start, in order to load all songs ), it will do without problems. Same if I jump song by song, and loading all plugins in stacks.

CHECK about panic button, and change buffer, stack becomes mute.

No glolbal part in the project, but after, i tried to add a global stack, and it works., no cpu problem (NO AUTO PRELOAD).

Thank you very much for those details! Of course, with a similar setup (ur44, win 11) I don’t have those problems, but your hints should help find the cause.

I am seeing the same behaviour with win 10 and an RMEBabyface pro.

I am not sure if theses issues are related but I still have the problem whereby the backing track pauses momentarily when parts change (this occurs whether preload is used or not). This is a devastating problem for me as, if I cannot rely on the backing tracks to play smoothly, I cannot use the tool. Is this a recognised issue with a known fix coming up, still under investigation or (I hope not) just me?

Can say as much as that we found the bug leading to cpu clogging with preload. We will release a new version with fixes soon.
Whether that has to do with your problem is hard to say. Do you use Stacks, and which plugins for Stacks, Layers, and track/channel inserts that change with Parts? Possibly, you can try to narrow it by removing one or the other plugins of the Part that you switch to.

Hi yes I do use stacks. Testing to date:-

  1. create new project (no preload)
  2. load up an existing song with 7 parts each part has 2 stacks, a vocal stack with 4 plugins and a guitar stack with 1.
  3. Run song - no issues
  4. load another song
  5. rerun first song some pauses on change of parts but not always
  6. adding further songs increases the occurrence of the issue

Some thoughts:- it feels like it is referencing all the parts in a project (all stored in a project level list?) when it changes parts rather than a list of parts for just that song.

The vocal stack was originally in a global part only and I created copies of it in each individual song part to overcome the issues with the global parts and this may well have exasperated the problem as it will have effectively doubled the number of stacks in my project.
If global parts are working again I can try and revert to the one vocal stack approach to see if that helps.
edit:-
I tried removing the individual vocal stacks and just having one in the global part and it helped but doesn’t resolve the issue. By the time I have loaded up a dozen songs it is happening regularly. It does seem to be tied to the total number of parts in the project.

I have a workflow similar to yours, and the exact same problem. I’ve been able to partially fix it, manually stepping through each of the parts, and then playing the song. With version 1.1.41 and 1.1.50, making this procedure is very stable. As of version 1.1.52, something breaks, and those breaks appear quite often.
I use on Mac, RME Fireface UC sound card

to complete info, the project contain:

1 empty stack for vox (without insert/fx) with 4 vst on their channel mixer insert, with send to groups
2 a empty stack to connect digital piano, only audio connection
3 five groups (with some reverbs/delay ) (one eq and one reverb in any channels group)
4 one AUDIO track (as backing tracking)
5 ONLY ONE PART, about 10 songs , same plugins (only change the send i want to for the reverb group, and of course the wav of backing track), less or more.
6 NO LAYERS USED, NO GLOBAL PART ON.

ALL VST USED ARE VST3, steinberg, or waves. BUFFER LOW LATENCY MODE, 128. yamaha asio driver.(win 10, last update)
WITHOUT PRELOAD, cpu stay whole on the left, just a very little green bar appear, 5% of lenght i mean.

I observed the phenomenon better:

If Preload is on (FLAGGED), OR if you MANUALLY CLICK START (preload NO FLAG, but click start ok on bar) , it happen this:

CPU BAR, CLIP ALL, OR with a minor amount of song, is going unstable, towards full scale.

BUT: (here is the phenomenon), if NOW, click on all parts of the song, just a recall, one by one, the CPU bar start go down, down, e so… be quiet.

I think that preload put something strange, so just for now i take off preload, 'cause it is not needed for me.

NOTE about ASIO DRIVERS YAMAHA: (in short: last fresh driver update, change nothing to our issue on vst live)

I TRIED AGAIN just now, after to update my yamaha asio driver:
previously i roll back into legacy 2.04, 'cause last drivers have issue with wdm with asio on, and stopped audio in other windows application.

Now I see the new 2.1.5, that resolve this issue, of windows and i update at once., it’s a fresh release of some days ago.

BUT nothing different with 2.04 or 2.1.5, about VSTLIVE, as the panic botton ( or change manually the buffer on menu of ASIO driver) need to re-join INPUT STACK, one by one.

Hope this help, thanks

Ther` is a bug when changing Parts that clogs the CPU, we are on it.

2 Likes

We finally found this very hard to track bug (CPU spikes when changing Parts) and will provide a new version with multiple fixes soon.

3 Likes

Thanks, I hope and trust, that we can start using vst live without any other problems.

It’s time to have a stable and fixed version to work with, after many months of beta versions…