C-11: Delay is Irregular in First Bar After Bypass Automation

Linked below is a video where Cubase plays through a few bars of a compositional sketch using a 1/4T Ping Pong delay. Instrument on delay is a HALionSonic SE custom piano.

The two areas where the delay skips a bit (sounds irregular) are colored in red. The first is subtle, but present.

The second is more pronounced but as with the first, self-corrects at the end of the first bar after the delay bypass - in this case as the drum track starts to kick in. There are only two notes in those bars, one at beginning and one a mid point (.3)

This screenshot from the video shows where this one starts for that one bar.

I’ve noticed this happen with other stock delays. And it’s not consistent, sometimes it’s more pronounced, then less. I can’t be just a playback issue since the exported .wav reflects this.

I make sure there aren’t any off-grid automation points in the track just to make sure, but it doesn’t make a difference.

Behringer UMC204HD USB audio buffer is at 256 samples, Project is 44.1 and Input Latency 7.302, Output 7.506. No MIDI signals are coming in from any external source.

Hopefully someone has some wisdom to share.
Thanks.

Delay Skip - 0:50 min video

Why not upload a video that only highlights the issue. It’s difficult to pinpoint with such a loud string pad over it. For example, the problem part + click. Everything else muted.

Did you check for small tempo changes?
Did you check that the parts are exactly lined up?
Which delay plug-in are using?
Is it an insert or a send?

Happy to look at the project if you want to attach it.

Not all the automation is not sample accurate in Cubendo, a lot of parameters are only sent and processed once per buffer, which means the automation could be off by an asio buffer size at maximum. This is the source of the inconsistency you are seeing.

2 Likes

@TakashiWatanabe makes an excellent point about the automation, I could not see that clearly as I was viewing on telephone originally.

1 Like

@Phil_Pendlebury - Point taken on keeping section simple for this purpose. I could reply to your inquiries, but since you offered to take a look at the project, it should be self-explanatory. Here is what it looks like:

I created and backed up a very stripped down version with only the piano, MIDI click track and what I use as a click track (very basic EzDrummer drum based track based on Led Zeppelin’s “When the Levee Breaks” pattern. I rendered it to a .wav since you may or may not have EZdrummer.

I don’t know where most people park such files, I have it at my Google Drive and the .zip folder for this stripped down, partial project is at link closing this post.

But here is some additional info to keep in mind:

My “click track” is purposely more laid back, all hits are slightly late for that is the feel I want. It sounds better than the MIDI click track IMO, even in this stripped down project.

The very simple piano intro part for an A-B-C semi classical crescendo composition in the works is as you can see, totally quantized, and no, there are no tempo changes, it’s 52 bpm.

As stated in my OP, the delay used is Cubase stock Ping Pong. But as I have also said, this quirk happens with other stock delays, namely StereoDelay.

The irregularity isn’t consistent on my system, sometimes it’s more pronounced than other times - to use an analogy, it “coughs” differently at the Bypass automation from On to Off.

Not good. I don’t know if this will happen on your system, but run it through a few times, see what happens.

PING PONG DELAY SETTINGS

Last, here is the .zip file with all parts needed for this cpr project at my Google Drive. It will only be there for a limited time for I’m a bit security conscious about public links.

Anyway, thanks for the offer to help.

PROGRESSION - Partial for Delay Issue

OK got the project and will check it asap.

Meanwhile did you see the @TakashiWatanabe message?

1 Like

@Phil_Pendlebury & @TakashiWatanabe - Your observation may very well be spot on, but if so, what is the fix, and what other pertinent info should I provide?

As stated in OP, I have a Behringer UMC204HD USB audio buffer is at 256 samples, Project is 44.1 and Input Latency 7.302, Output 7.506. No MIDI signals are coming in from any external source.

@Phil_Pendlebury
I should have thought of including the below for the delayed H-KEYS Track (piano):

HALionSonicSE 3 Piano preset
– PIANO SOFTER.vstpreset (135.1 KB)

Cubase Ping Pong preset:
– QUARTER D.vstpreset (2.2 KB)

LATER EDIT: The piano HalionSonicSE preset is pretty basic, two different pianos (one hard, one compressed). But maybe some setting in one or the other may be triggering the problem, or not.

Oh, and the only other preset in the project for the piano is the stock RoomWorks - which shouldn’t be causing the problem but here it is:

– PIANO REVERB.vstpreset (4.1 KB)

I do have a Native Instruments/KK Raum effect in the main project for the piano track to widen the ambiance, but I don’t know if relevant or that you have it.

I may be over-thinking all of this but maybe one of these presets are affecting what @TakashiWatanabe brought up, or not… Figured better give more info than not enough.

I think the Bypass also cuts the tempo sync, that’s why it behaves weirdly when you toggle it during playback. It does that with any tempo synced plugins, so there really is no need for all these posts. Automating Bypass was never a good idea anyway (on any plugin, not just delays) as it can produce audible artifacts. You should use the mix or volume knob instead, or just render the wet delay on a separate track and cut the parts you don’t want and add fades, etc.

@Louis_R - That’s what occurred to me also. Bypass is not a subtle approach and I agree on your assessment of causing artifacts.

As to “… so there really is no need for all these posts” - granted, I tend to do a bit of TMI overkill in all of my OP (and make a discussion thread a bit long).

The rational is that since I’m asking for help, courtesy prompts me to be as thorough and detailed as I can. I’ll try to be a bit less TMI. :sunglasses:

@Phil_Pendlebury - Please see posting directly above. @Louis_R 's observation dissolves the need for you to look at the .cpr. But I appreciate your offer of assistance.

You’re welcome !
No problem about TMI, I also do that sometimes :wink:

That’s not true Louis. Try running a vst3 plugin that displays tempo, automate bypass and during that state, write tempo change on the cubendo. You will see tempo changes on the bypassed plugin. Or just simply watch plugin that shows timeline like stock FXModulator, autoPan, waves tune and etc. The timeline on the plugin moves while in bypass state.
Bypass in VST3 is just an event sent from the host to the plugin and it is up to the plugin developer how to handle it, you know there is some plugin that does not react to this message, so there can’t be “all” plugin react the same way. All the data transmitted from the host still arrive at the plugin, there’s no difference between the normal and bypassed state in that regard.

But I’m not talking about automation, of course the plugins parameters will still visually match the automation even when the plugin is bypassed, the problem isn’t here.

I am talking about the tempo sync, normally when using tempo synced plugins, the DAW sends tempo click to the plugin so that the delay settings are synchronized with the project tempo.
Here the problem is that when you get out of the bypassed state in between two ticks, the plugin doesn’t wait for the next tick and the delay will start right away.
This will create one out of sync delay, plus the one on the very next tick, and this indeed doesn’t sound great.

You don’t need any automation, nor VST2 vs VST3, nor complex setup to do the experiment. Just load any tempo synced delay on a track and play with the bypass button.

I am aware that plugins with tempo synced LFO like the one you mentioned, work correctly when using bypass, simply because the LFO acts as an automation, but in the case of delays or reverbs, the audio will start getting processed as soon as it gets out of bypass, it means that if you have a delay at 1/1 setting and unbypass the plugin at say, bar 20.4, the 1/1 delay will be based on the 20.4 position, and not the next click, which is supposed to be on bar 21.1, the delay will then be late by one beat until its feedback ends.

In reality I agree that it does not cut the tempo and click information, but you get the idea, I just was’t specific enough. :wink:

I am not talking about automation either. I am just saying plugin receives timing information during in bypass state and it is all up to plugin how to handle that.

Bypassing delay does not wait for the next delay tick. Your expectation sounds like aux send on/off to a delay FX, but bypassing is not turning the processing ON/OFF. It just disengages the processed signal and the processing keeps going. If a delay is set to the feedback of more than 100%, that makes a ‘texture’ of the self-oscillation and this keeps going when bypassed and then starts again immediately after un-bypass. It has to work this way and it is.

Just try it :wink:

Try what? Feedback > 100%? Have you tried it? Or are you expecting like send on/off? I know it is tedious but that is how it should work.

Let’s think about a bypassed compressor. If a compressor is bypassed, what would you expect when bypass then unbypass? Should reduction already going according to the signal during the bypass or should it start reducing as soon as unbypass? If the delay starts on the ‘next tick’ as you like, the compressor should start reducing on the next transient as well. But for compressor it isn’t how you would like, is it?

Hmmmm. His explanation has some incorrect info. But no worries. Cheers. :slight_smile:

What’s still getting outputed by the plugin after unbypassing it is the audio that was on buffer BEFORE bypassing it. When you bypass a plugin the audio stops feeding into it, just, wtf are you talking about, you’re not even trying to understand my point.
If you clear the delay buffer, bypass it, hit play, then unbypass it, it will only start process the audio as soon as it is not bypassed, it will absolutely never process the audio during the bypass. Jesus.