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.
Brad
Hi @brad
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.
lg, Jeff
OK, thanks for that I’ll check it out when I get a moment. Are you running it in Cantabile x86, or in x64 via jBridge?
Brad
in x86 without a bridge.
Helm & Kontakt in x64 also without bridge.
All in test-stage til now…
Eclipsis looks interesting!
I think Synth 1 also has that flush problem. When i switch back, some sounds have that tail from the last played part.
2 Likes
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.
3 Likes
I have this in reaper also with Synth1, delays have a silly effect when switching presets, best is indeed to have a reset preset in between.
1 Like
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.
1 Like
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?
Bugger - not really sure.
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.
Brad
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 .
1 Like
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.
Neil
1 Like
Hey Neil, here’s a bank with flush at 128 and some long release stuff in the first 4.Flush Synth1 VST64 1.cantabileFxb;fxb.cantabileFxb (8.6 KB)
1 Like
Just When I Thought I Was Out, They Pull Me Back In!
@brad
Valhalla Shimmer does not really play ball with flush tail. It certainly reduces by a large degree, which means that whatever you’re doing is certainly in the right direction, but not all the way.
Can the flush function be more effective or is this really in the hands of the plugin author?
Long time since I looked at the flush tail sounds, but I believe what it does it just keeps processing the plugin and sending it’s output to nowhere until it drops below a certain threshold or times out. I could probably increase those limits, but there’s always going to be a plugin that needs longer.
Brad
HI Brad. So what is the effect of, say, an 8 second reverb which is sent nowhere and then is required to operate again within that that time frame?
For context, I’m trying to kill a reverb with a condition that all notes are off and sustain is released, and that a new note will reactivate a ‘clean’ reverb.
OK, so I just reviewed the code for flush tail sounds, this is how it works.
- Plugin processing on the audio thread is stopped.
- Back on the UI thread…
- The plugin is told transport has stopped
- The plugin is sent All Sounds Off MIDI event
- The plugin is sent note off events for any note known to be held.
- The plugin is told to process audio buffers until the output level is less that 0.001f (scalar level), or 8 seconds of audio has been processed.
Notes:
- audio processing during flush tail sounds is done “offline” and not in real-time. 8 seconds of audio should usually take less than a second to complete.
- flush tail sounds is only done for VST 2 plugins.
So answer your question…
…the 8-seconds of processing will be done as part of suspening/stopping plugin - so you can’t re-enable it again during that period.
2 Likes