I have noticed a small issue I already know from mainstage…
I have lets say 2 songs.
Song 1 has a simple Synth (Eclipsis).
Song 2 has any other Vsti.
When I play Song1 and switch to Song 2 before the remaining tail of that song/sond (a reverb, delay, release) has finished, that tail gets cut of. Fair enough.
Then, after I played Song2 - no matter how long - I switch back to Song1.
Now I can hear the previously unfinished tail of sound.
This does not happen when I switch through: Song 1 VstI1, Song2 Vsti2, Song3 Vsti1 with same preset (not a clone).
This does also not happen with pre-load setlist switched off.
So I guess it’s a matter of flushing the buffer or smth?
Also it would be nice to have the possibility to let the Vsti play til the end, despite of the song-change.
As an option maybe, cause it would affect loading time.
If I recall correctly, the most popular solution for this is to keep the first VSTi active in the next state, but to simply turn off its MIDI feed from the Inputs section. Then it finishes out its sound ok. But I know what you are referring to - it is something to do with the plugins buffers, as you suspected.
The plugin right-click menu has an option for flushing output buffers (reverb tails etc) when the plugin is suspended - have you experimented with that?
Indeed only possible in State switches. Since it’s technicaly impossbile because the vst’s are flushed, maybe it should be possible to have that function in delay? So vst’s are only flushed X times after song switch?
I didn’t see the option for flushing buffers!
That removed the tail from beeing played again, but also made that vsti to not work anymore at all after coming back…
I’ll keep experimenting to find out if this is a problem of this particular plugin.
The flush tail sounds would be the simplest solution for this but I don’t know why so many plugins have issues with it - must be something about the way I’ve implemented it that spooks some plugins.
Do you have a link the the plugin? I’ll check it out - see if I can figure out what’s wrong there.
it is this plugin: Eclipsis
Only available in 32Bit, but very cool and for free…
I’ve tested other plugins:
NI-Kontakt doesn’t even need the flush-buffer option - it does it on it’s own.
same with Helm - no problem here.
Both work with or without flush option enabled.
So, that’s at least two synths which have the issue.
Brad relies on the plugin author to include the ability to flush out the plugin. If that’s not there, as is the case with Synth1, there’s no 100% solution apart from the user forcing the plugin to shut up.
For the time being, I’m going to suggest a solution which is pretty straightforward;
Create a ‘Flush Tail’ preset for the offending plugins.
Something with its volume down and all releases / internal FX zero’d.
You would have a choice as to how best to invoke the preset from Bindings, but if the Flush Tail preset was sent anytime the plugin was bypassed, there’s no chance the tail will be there next time the plugin is activated again.
OK! Progress!
Firstly, @brad, you definitely improved things with Synth1 by a huge degree. The DDL in Synth1 is still problematic, but we now have a solution in that the On Unload binding now works perfectly.
By issuing a nulled preset with all releases and DDLs off (calling it Flush Tail for want of a better description) the user can move immediately between Synth1 patches without the DDL going nuts and also know that reactivating the Synth1 won’t produce the tail that was left behind from the last use.
One caveat that I’m not sure it’s easy to get around;
It’s not easy to use program change bindings alongside the Preset list which is available from the Routing page. The binding appears to get priority, resulting in the state being recalled with the Flush Tail preset in place instead of the required preset. It’s a battle for pole position, and Bindings are winning.
The solution is to issue all program changes to Synth1 from the Bindings window.
Next potential issue…
This could result in a really long list if this is done outside of a Rack, so the neatest way is to have the Synth1 in a Rack and control the bindings from there. As Rack States can be named, you’re not losing any clarity as to what you’re recalling; those Rack States live in the exact same location that Presets would have lived had you not been using a rack.
This is an area new users can get confused in but, for their benefit, a useful concept to understand is that everything inside a rack can be stored as a preset which, in Cantabile speak, is known as a State.
Those States can be recalled just like a synth preset - one button - bam. There it is - and from exactly the same location that Cantabile would issue a ‘top level’, non rack, preset change. No matter how many plugins are living inside that Rack, their States are recalled and presented to you under a name which you choose.
Anyway, this is how it looks, employing Cantabile’s split screen mode:
Note, the Flush Tail preset is issued so fast that the plugin doesn’t register it.
NB - Synth1 does not issue a note off command when it receives a program change command. All of the above works well unless you keep your fingers on the keys!
As an additional failsafe you can issue an All Notes Off command to fire on Song State Unload.
Not sure I’m exactly following this (probably because it’s past midnight here ). Would you mind putting together a simple example and email it to me so I can check it out in the morning?
@brad
Well, that’s that theory out of the window.
I made some Synth1 patches with super long release times and long delay feedback.
Manually changing to a ‘flush’ patch, with all release and delays off, and then switching back to the release patches, leaves a huge residue.
How is it that Synth1 manages to have all pertinent parameters shut down and still manages to leave a mess which kicks back in? I’m disappointed. I really thought that this was surefire - and until I really pushed the Synth1 presets - I thought it was a done deal.
How on earth can Synth1 be buffering all that data when a patch of nothing is in the middle of the whole procedure?
One theory might be that the patch switch to and from might be happening without an intermediate process cycle causing things not to get flushed. Or it could be something completely separate. If you’ve got a concise example that you can send through please do and I’ll see if I can figure it out.
Another idea I’ve had is to off load this flushing of plugin sounds to another thread so that they can be left to process until they really go silent without blocking the main UI thread. Currently it’s limited to 8 seconds worth of audio samples (or early bail if it detects silence) but this would allow the plugin to be properly flushed.
So…
Yesterday I set up two Synth1 test songs - one with moderate release times and delays and the other with huge releases and delay feedback. We’ll call them ‘moderate’ and ‘huge’
The ‘moderate’ song was used as the basis for the ‘huge’ song. Same bindings, different Synth1 presets. Using the same ‘Flush Tails’ preset in Synth1 (no release, no DDL, no volume) the ‘huge’ song failed to respond the way the ‘moderate’ song did, with the tails spilling over between patches.
Today, having tested the ‘moderate’ song and assured myself that it is absolutely cleaning up the residue, I used that song, once again, as the template to place the ‘huge’ patches in.
Today it works.
There is a potential click that can get into the Synth1 DDL but I’ve included bindings to kill that now and any little clicks won’t repeat.
If any Synth1 user is interested in checking this out, that would be great. Just make a silent synth1 patch where I’ve placed ‘Flush Tail’ and put a couple of long release / DDL patches where I’ve placed the Program Changes following the Flush Tail .
Great to hear that today it works!! Fingers crossed for tomorrow!
One thought I had was that in your “Flush” patch, perhaps disabling the DDL isn’t enough - perhaps you need to have it active, to allow it to run its course with zero feedback and a short delay time. Out of interest, could you post your “Flush tails” patch? I’d like to do some experimentation myself.
