Volume Spikes when switching rackspaces and using "audio tail"

This would be the same situation if you added a delay plugin to a single rackspace. They are generally just going to add the wet/delay audio to your dry signal, without adjusting the level of your dry.

I then don’t understand how a rackspace change would work any differently. Assuming you have Input Muting set to 0s.

The difference is that there is already a signal from the first rackspace present when switching, meaning the signal in the second rackspace is adding full ‘wet’ signal from the first immediately, before the decay of the tail occurs. Adding a delay plugin in a single rackspace means there will be a time(dependent on the delay time of the plugin)where there is dry signal only.

I still don’t get it. Having Input Muting set to 0s means the dry signal from the previous rackspace is cut immediately: no overlap with audio from the new rackspace. Only the delay tails from the previous rackspace will be heard.

And the immediate volume of these tails is completely controlled by the settings you have set in the delay plugin.

I don’t see how this can be considered a volume spike.

If I have two identical rackspaces, where the only difference is a delay plugin that exists in the first rackspace - the transition from the first to the second sounds completely natural to me.

It makes me think the real issue here is the volume of the second rackspace might not be leveled correctly in relation to the first.

But, happy to discuss this. I have raised issues with the transitions/tails between rackspaces in the past - which were fixed by the devs.

1 Like

Yes, but in that initial .5 seconds, the audio produced from that previous rackspace is added to the audio from the new rackspace. In those initial moments, the decay of the tail is still at a decibel level where its addition to the new signal is noticeable if one plays through the rackspace change.

You don’t even need to change rackspaces to test this result.
Consider this setup:
DelayLevelTest.gig (62.1 KB)

ScreenHunter 11

  1. The input signal to the delay starts un-muted.
  2. The output signal from the delay starts muted.
  3. While playing a repeating succession of eighth notes, engage one of the widgets and continue the same succession of notes.
  4. The input signal to the delay will be muted (mimicking the Input Muting set to 0)
  5. The output of the delay signal will be un-muted (mimicking an Output Muting of ~5 sec)

Observe the level change in the summed audio during that first 1/2 second or so.
The result is the dry audio (mimicking switching to a rackspace without delay) plus the delay trail (mimicking the Output Muting of a previous rackspace). The trail of the delay signal added to the sum boosts the db level noticeably during that initial time. Once the decay reaches a certain point, its not a noticeable boost in db level even though you can still hear the trail.

The delay in the example has a high volume, which of course will generate a boost on the first delay tail. It’s the same volume as you’d get playing this rackspace with the delay active - so I still don’t see any additional spike.

In terns of options, what would be a proposal? Is there anything GP can really do? Does this perceived spike occur in the same way if it was only reverb tails?

I guess what could be a solution is using a cross-fade: the rackspace that’s deactivated fades out, while the newly activated rackspace fades in. When using the right curve there should not be a spike. Downside is that the initial level of the activated rackspace fades in, so it takes the fading time before you have full presence.

But this solution would be a feature request, so not usable for now. Thursday I can checkout whether it is possible to imitate this behavior using srcripts. Maybe @chris_g could then check whether cross fading alleviates the problem or not. After that, a feature request can be created.

I’ve done a bunch of testing yesterday and today. I’m using the same exact preset in each of the plugins, one has the delay on, one does not, so the volume is the same. There’s a definite spike in volume for a very short period of time.

I just go back to many other devices that allow one to switch between presets with delay/reverb “spillover” and it’s completely seamless. What are they doing different than GP? It’s not a show stopper for me, but just a bit annoying. I’ll just work around it as someone above suggested…just pause your playing for a split second.

The other work around is to run the delay in parallel with the dry signal and mute the input to the delay which effectively turns it off (make sure you set the mix to 100%) and lets the repeats trail out. In that situation, there’s no spike in volume. However, this requires two plugins; the amp and a delay. In this specific case, the plugin I’m using doesn’t let you disable individual effects so I can’t isolate the delay. I have other delay plugins I could use, but I like something specific this one is doing. Oh well…

None of this changes the fact that every other VST host app like this pales in comparison to GP. Thanks again to the devs for making a great app.

Thanks @chris_g . I’ll do more experimenting as well, because the only difference between keeping everything in the one rackspace that I’ve heard, is the very quick ramp down/up of volume that GP is doing when you switch rackspaces (to avoid clicks/pops). I’m still wondering whether it is this behaviour that gives the perception of a spike.

It would be great to figure this out, because then there would be something specific we could ask the devs to look into.