I have been having this issue for a number of versions now but this description is based on what
I am seeing in 2.0.29. I get what appear to be random drop outs of the backing track.
They most often occur close to the start of the songs but not always and usually if I play the same song again a second time they do not reoccur.
I have multiprocessor off.
I preload and then part preload but it doesn’t seem to make any difference.
It is only the backing track that drops out and the global vocal stack and part guitar stack continue to sound.
I have checked that the backing tracks are same sample rate as project and sound card.
I have tried rebuilding one of the songs from scratch in the latest version of the software but does not seem to have made a difference.
I know some other live software (Gigaperfomer and Cantabile) have issues with Izotope and Waves plugins so I have removed all of these from the project.
It does appear to be a drop out rather than a start stop as when it reappears it is at the correct position in the song and I am often still in time with the backing track as the drop outs are usually short.
It possibly occurs more often in songs with more parts but this is likely a red herring as it does occur in songs with only 1 part.
I believe I have turned off everything that might be causing an interrupt and the problem persists whether or not I have wi-fi on.
As far as I can tell the dropout do not coincide with a cpu peak but as they are fairly random it is possible there is a momentary peak that I am missing.
Just tried moving some of the tracks toa different hard drive but those tracks still subject to drop outs
We have observed and fixed a similar issue, but there appears to be another such problem with audio tracks. It is a bug, so none of your attempts is likely to fix it. We will try to solve it asap.
I found the same issue using Groove Agent Tracks (copied patterns into VSTLive tracks played via Groove agent). sometimes the start events of a loop are not played. most of the time it appears at the second loop repeat after loop exit event. I thought it is delayed ‘loading’
Hi I used version 2.1.2 yesterday in a gig and still getting occasional backing track dropouts. Not as frequently as in earlier versions but still happening. No obvious correlation with CPU spikes etc.
Dropouts may occur when there is no sufficient time to preload data from the drive. This has nothing to do with CPU or audio processing. It might explain why it works when you re-locate and start over.
The question is, when and how you start playback. For instance, with automatic play after Song change, with older versions, it would just start, but preload for the tracks wasn’t finished yet. However we added a wait function for that, and you are obviously already using newer versions.
Another instance is when you “jump locate”, that is, while transport is running, locate to a different position (“on the fly”). While this is deliberately supported with FlexLoops (well, best it can do), a manual jump locate may well cause dropouts, because transport continues to play regardless of not all media beeing preloaded. Depending on how much there is to process, this may lead to dropouts.
It should always work when you locate and leave it some milliseconds before starting.
Typically when one song ends it moves to the next but I don’t start the next immediately (I manually start seconds/minutes later ). Once I start I just let the song run and I am not trying to jump around etc.
When you say preload data I assume you mean it loads the entire audio file into memory before playing? (In my case each songs backing track is a single audio file) Is this also done as part of preload or is that just the plugins?
One odd thing I thought I noticed but now can’t recreate. When I first installed V 2.1.2 it loaded up with MP on and I ran through the set a couple of times with no dropouts. However the next time I launched it I was getting constant loud clicks and pops (even with nothing playing) which stopped when I turned MP off again.
No way, it’s a streaming process. It continuously loads as much as necessary (currently, approx 3/4 of a second) to safely start to play and stay ahead for playback. If too much is going on and it cannot catch up, the preload buffer may be empty when audio is supposed to play, that will cause a dropout, and depending how soon the background process can “breathe” again, will drop in again sooner or later.
Audio (and other media data) preloading is always active. When transport is located to a new position (always the case when switching Songs), buffers are discarded and need to be re-filled again. That’s why dropouts are to be expected when you “jump locate”, because it is likely to not make it in time - depending on how much else is going on, of course; with just one audio track, you will hardly notice.
With Song change, despite “Preload” applied, there is always much going on, so it also depends what other processes (channels, plugins etc) are active.
I guess the answer is a more powerful laptop then? Is there any advice on how best to set it up to minimise the issue on the meantime? I currently have a global vocal track with compression verb etc and each part has guitar rig 7 stack and a few have kontakt organ or other synth. As I say, 1 stereo track per song. Could I load a global guitar rig and change patch with automation?
I will certainly give it a go. It is a little disappointing though given that it makes the concept of parts somewhat redundant (in many cases) and it is not that far away from what I was doing in Cubase before moving to VSTlive. Doing it in Cubase was an absolute pain to set up but it was rock solid on playback.
No it’s not, guitar rig is not a lightweight something, (but for eg neither can I load 2pcs of UAD Marshal Plexi on one DSP, so amp syms are usuall resource intensive)
Well it is to me dude!
Like I say it takes me back to the process I was using in Cubase.
A better solution might have been to have stacks completely separate from parts. That way I could define a handful of stacks to be loaded on preload and within the parts just specify which stack to point to, avoiding the need to load and initialize on part change.
As it stands, I cannot rely on backing tracks to run glitch free which is literally a show-stopper and my only option to rectify this seems to be to revert to adding loads of automation. A process I found quite painful in Cubase. So, if it is ok with you, I will carry on being disappointed but thanks for the suggestion anyway.
Hi! Downloaded, installed 2.1.4 and seems to me a very good build. Can you try it out?
Also I can offer, if you export me a song (or your project), will try to load in my system to see if that is producing such problem and if producing, what might trigger it. Then we both can provide more information to developers.
Hi, I personally think that using stacked parts for guitars and bass is the best way to go, as it allows for detailed editing of the sound for each particular part (different presets for verse, solo, riff, etc.). Once you have set up each stacked sound, you save it as a preset, then drag it to the corresponding part, edit some details, and you’re done. Even in the parts where the instrument doesn’t play, you don’t put the stack in, and it doesn’t play, thus avoiding sounds by mistake. My workflow includes a stereo track, an audio track with a recorded click, and some extra tracks, in case the drummer or guitarist can’t come to rehearsal, then at the live show these are muted. It took me a lot of time and experimentation to find the right simulator, that doesn’t destroy the CPU, or the RAM. Neural DSP was my first intention, but after four or five songs, I was getting audio dropouts (not clicks), the guitar was taking a while to get into the sound. Amlitube, on the other hand, was filling up the RAM when there were too many stacks in the setlist. I finally managed to get everything working flawlessly with TONEX as an Amp simulator, and the delay and other effects are added in another insert when needed (Tonex is just a snapshot of a rig in a certain position, but it sounds really good, and there are no problems with CPU consumption, clicks, etc.). This way I have all the setlists built, with more than 150 parts + Stacks, very detailed, and it really works very well. I use it on a MAC, with two systems, one desktop, M1 Max, 32 gb ram, and the laptop, M1 pro with 32 gb ram. There are no clicks or stops in the backing tracks, not even in part changes.
That is a generous offer. I will try the latest build and I am also going to try moving the tracks to a faster drive again. The glitch has a good degree of randomness to it and although it most often occurs at the beginning of the song it doesn’t seem to correlate to any subsequent change of part within the song. This leads me to think it is an issue with pulling the stream from the disk rather than with the initializing of the VST etc. I am away for a week but will take you up on your offer when I return if that is ok.
That is interesting info re TONEX. My set up is similar to yours and for similar reasons I think. Being able to use song parts to change things up was big plus for me when I first bought VSTLive. I would really like to keep utilizing them fully if I can. I have a growing suspicion that my problem is related to the streaming of the audio from disk, so I am going to experiment with using a different disk. Finger’s crossed.
One for the devs:- would it be possible to make the size of the stream buffer user configurable?
Regarding guitar amp sims, may I add that i’m acrually using Amplitube 5, only 1 istance as global stack, then i save as many preset as i need INTERNALLY (amplitube 5 save preset, Not vstlive save preset). Then in amplitube 5 you can assign each saved preset, to a from 0 to 127 program change number.
This way i only need a midi track in each song, to send program changes to amplitube via virtual midi out (corrisponding virtual midi in set ad midi in in the global stack), no need for single parameters automations.
Yes that is a good solution and the way I would likely do it if I need to go that route. I wasn’t sure program change to a global stack worked so good to know you have that working.
I am less and less convinced my issue is with the vst though. I have just had the dropout on a track that has no vst other than the global vocal and an empty stack for acoustic guitar.
