Issue with "Full Bank" state behavior

1

I really like the “full bank” state behavior - a lot of my racks have an EQ plugin at the end with this behavior enabled. This allows me to have a specific EQ setting for every rack state - great!

But I’ve come across an issue with this:

  • I have a rack with Velvet in it, plus a FabFilter Pro-Q2 after it. Specific EQ configs for each rack state
  • When switching EQ configs, Q3 creates a little “click” when there is audio still running through it - probably due to loading a full preset. Fundamentally not a big problem
  • But when I switch song states, but stay within the same rack state (so theoretically no need to switch an EQ preset), this click still occurs - looks like the EQ is re-loading the same full bank preset with the song state change

This is a bit annoying - I’ll go back to plugin presets for the moment for this specific EQ purpose, but it would be good if this could be cleared up and resolved. No need to re-load a plugin bank when the rack state isn’t changing…

@brad ?

Cheers,

Torsten

2

I remember I ran into the same problem a year ago or so. I blamed it on the plugin I’ve used. It took me a very long time finding out that it was the entire bank parameter that caused that issue.
If you check every parameter individually instead of the entire bank it should work though. At least in my case that worked great.

3

Yes, I was thinking about this. Problem is that with FabFilter Pro-Q, I tend to be a bit creative with the number and type of EQ bands - some states only have a highpass and a peak filter enabled, in others I play with up to 5 filters. If I want to use exposed vst params, I’ll have to be a bit more disciplined in my approach.

Well, a bit of re-working never hurt…

Cheers,

Torsten

4

Hi @Torsten,

I’ve had a look at this. Some notes:

When switching between song states where the rack state is the same, it will try to ignore redundant state changes. (switching to the same state as the currently already loaded state). However there are a couple of instances where redundant state loads can’t be ignored, including:

  • If the song has the “Also Reset the Rack” option selected for the rack state you’re switching to
  • If the rack has exported state behaviours.
  • When initially loading the song, or first inserting the rack into a song.

Also, however… before doing an entire bank load on a plugin Cantabile first reads the plugin’s current entire blank, does a byte for byte comparison and only loads it again if it’s different. (see code snip below)

So there’s two checks in there that should prevent this from happening. The first one can be bypassed if you’re using Rack Reset or exported state behaviours. The second one can be bypassed if the plugin has any volatile data in it’s persisted bank state (eg: random memory contents, save time stamps etc…)

Does that explain any of what you’re seeing? If you really want to track this down, I’d probably have to put in some additional logging.

Brad

// Load entire bank?
if (behaviours.Contains(Behaviour.EntireBank))
{
    // Get the bank blob to load
    var data = _blobManager.Get(state.BankBlob);
    if (data != null)
    {
        // Get the plugin's current bank blob
        var currentData = PluginData;

        // Only load the bank if it's actually different...
        if (!StructuralComparisons.StructuralEqualityComparer.Equals(data, currentData))
        {
            try
            {
                // Load it
                PluginData = data;
            }
            catch (Exception x)
            {
                // There's not much we can do if the plugin chokes on its own data.  We want the state
                // switch to succeed so we'll quietly suppress the error but this plugin will be left in 
                // an indeterminate state.  Just log it...
                Log.WriteError($"Failed to restore plugin data for {this.FullName} - {x.Message}");
            }
        }
    }
}
2 Likes