I’ve set up 8 select part actions using pgm change that I trigger from a midi controller in order to skip to different parts of a song (intro, ref, fill etc) while VST is playing. When I click a trigger while not playing, correct part is selected and the song pointer goes to the correct time. However, when I try the same while playing the part is only selected without the trigger causing song pointer to skip to the right time.
In order to actually play different parts on the fly while VST Live is playing one has to first select the part and then hit the play button for that part before the playhead skips to the right time.
I se no purpose for selecting parts while playing if nothing happens. I hope this can be fixed very soon.
Parts have 2 purposes, they know a trigger time but mainly serve as container for Layers and Stacks which they can automatically activate when triggered, manually, or when trigger time has been reached during playback.
So far, VST Live never stops or jumps to a different location once Transport is started, that would be devastating for a linear live performance progress. Deliberately jumping during performance at a certain future time (i.e. next bar) is planned for later.
A lot happens when you select a Part at any time, all of your Instruments and Stacks change.
Right now I can’t use stacks (for my vocals) because strange things happen to reverb echo etc when switching parts. I run my vocals throuh a track with efx insted. I do the same for drums using Groove Agent playing patterns, since switching parts results in strange drums if GA is in a layer. I only have a piano and a bass configured in layers, and they usually dont change during a song. In a pianobar setting using static/linear playback tracks is not ideal. You want to freely skip between parts/patterns. But I understand, better days are coming…
To replicate strange things happening , try the following:
In part one add a stack that gets input from a microphone. Then add a MonoDelay as insert and change that delay from 1/1 repeats to 1/4. You now have a very long running delay effect.
Now duplicate this part and change the MonoDelay to RoomWorks and change the reverb time to 5s
Now switch to part one an say "Hello"in to the mic and then switch immediatly to part two and say “hey”.
If you now switch between these parts you will hear remnants of the effect from the last time the part was active…
Thats pretty strange…
The correct behavior would be for the effect not to stop when switching parts but continue to run until there is no more signal at the end of the inserts chain for that part.
To mitigate this I now run my vocals through a track. This works pretty well. However if I later import a Media Project, that voice track will be deleted. This means I can’t make “template” songs that contains favorite vocal settings. I wish that didn’t happen.
Thank you, now it is clear.
With Layers, there is a preference “Layer Sustain Time” which tells VST Live how long to keep a Layer active after its Part has been de-selected. It will also wait until all notes and the sustain pedal are released.
We will add a similar feature for Stacks with version 1.1. You can set a time for how long Stacks of a Part should continue to sound after it has been deselected.
We cannot trace all plugins output for when they stop producing sound, so you will have to define such a tail time yourself (default will be 1.5 seconds). Thereafter, the plugins will also be “emptied” so to prevent old delay buffers etc to sound when re-establisched as you described.
Happy to hear “Stack ‘Sustain’ Time” is coming
ETA ?
I understand that tracking all plugins output would be challenging.
I was imagining that you are using object oriented programming and that the plugins would generate sound inside stack objects belonging to parts that would have it’s own audio out that could be monitored and reacted upon so that we don’t need to set a time-out but rather an audio level threshold for when the object should be removed from memory.
While it is far from beeing as simple as you describe it, we will do something quite similar, because many plugins refuse to implement proper flush operation. The tricky bit is to do it without affecting performance.
