Delay time-shift audible while tapping! – at least bucket brigade

Forums Forums dLive Forums dLive General Discussions Delay time-shift audible while tapping! – at least bucket brigade

This topic contains 14 replies, has 3 voices, and was last updated by Profile photo of SteffenR SteffenR 5 years, 1 month ago.

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
  • #63140

    Hey folks! Was playing around with the FX rack earlier this evening and I noticed an issue with, (at least,) the bucket brigade delay: When you tap tempo and signal is going through the delay, you hear audible time/pitch shift. Not particularly cool in a live environment when moving from one song to the next, or shifting from a 1/4 time tap to a 1/2 time tap. …or any time really. I do not want to hear that shift.

    As you can imagine this is a common issue with most delays in a DAW environment. Most live consoles I’ve worked with get around this through discrete ducking that occurs when you tap tempo. VENUE did this I *Think* by muting the output until after the time shift was complete. I have been able to duplicate that by using ableton as a parameter controller for VST/AU delay plugs so that when you tap tempo, output quickly mutes, tempo taps, then delay output quickly fades back in once tap is finished. (Ableton is controlling Fab Filter Timeless 2 in that instance.)

    Is there a plan to address that audible artifact issue on dLive delays? Thanks so much!

    Profile photo of pete.j


    but this is kind of a normal behavior in most delays. And – as a lot of my colleagues at least do – Delay send is altered so in a scene change the delay is “off” anyways.

    Also: if you just “re-tap” the delay during a song (because the band are changing the tempo slightly) it is the better thing, that there’s NO mute on the delay as the altering in tempo (and therefore artifacts) are minimal. But a “dropout” in the delay would be more obvious.

    Did you ever use a “real” delay machine, like RE-201, DRV-2000 or such? The real things do the same, so I won’t call it a “bug” as it’s how delays act in tempo change.

    Cheers Peter


    Oh absolutely. It happens in every delay, and the easiest workaround is to mute/reduce the thing while tapping. I guess I’ve just been spoiled on systems that have a ducking mechanism built in to the tap function. (IE VENUE.) Try tapping any of the delays on an avid desk while the fader is up – you won’t hear the pitch shift at all. I noticed this one pretty clearly when moving from a 1/4 to 1/2 time tap on the Allen and Heath, which is something I do with a fair amount of frequency. In that sense, I would consider it a bug for a high-end digital console designed for live sound support to not have a ducking mechanism tied to the tap. I mean, I could burn an fx slot and have one on a half time, one on qtr, but that seems silly. …and really, I can think of about four additional work-arounds for that audible shift, but it would be nice if it was just a feature of the dLive.

    Thanks for the insight though sir!

    Profile photo of SteffenR

    Venue Delays can also pitch the audio while changing the delay time,
    sometimes it is a wanted effect

    since the delay FX in dLive are emulation of classic units the behavior is part of the models


    Makes sense, thanks guys!

    Profile photo of pete.j

    yapp, Steffen is right. Only the simple Digidesign Delay (short, meduim, long) don’t do pitch-shift I think. But for me I more often use EchoFarm or H-Delay on Profile and there it happens two. It also happens in my DAWs (ProTools, Logic) if I use these plugins. So as already said – it’s not typical to dLive, it’s typical to “analog” Delays – or let’s say “continuous” Delays.

    Just keep in mind: Chorus, Flanger, classic PitchShift are also done by varying the delay time in a short frame! There you working explicit with this “artifact” of changing time in a delay.

    Regards Peter


    Yessir, and in those contexts I want that audible shift; but I do not want them when I’m trying to have a tempo-locked tap delay that is as dummy-resistant as possible for volunteers, while trying to maintain a high level of mix quality across the board. In that situation I don’t want any remote possibility of audible shift.

    I will say: it’s funny you should mention H-Delay. I actually use that in a current Pro Tools rig for a couple of live streaming situations. I use H-Delay because the tap is midi-mappable, unlike Fab Filter’s Timeless 2, wherein TIME is mappable, but not tap. (How weird is that?) I didn’t realize Echo Boy was also mappable in the same way, or I’d have bought that one instead. At any rate: I had the same issue with the audible shift in H-delay when switching taps, so I built an automation layer using Ableton as a time-based parameter controller: LPD 8 is mapped to have a “TAP,” button that corresponds with Ableton’s internal tempo tap, second LPD8 “Go” button is mapped to a clip launch that has two layers of automation parameters: 1) cc that smoothly/quickly turns DOWN the output of the H-Delay, 2) 4 midi notes mapped to H-Delay TAP, 3) CC that then smoothly returns the H-Delay OUTPUT to unity. That series of steps, in a triggerable midi clip, works incredibly well as a workaround. Not an ideal solution, but it does the job!

    Profile photo of pete.j

    I don’t know, if I get you right:

    time is mapable, also you can sent “song tempo” (BPM). So if you control via ableton, why don’t you simply send midi tempo and set H-Delay to BPM/Midi-Tempo. So also there I don’t really see the weirdness, as tap is more seen as a “on the fly” thing. You can define a MIDI-Controller via MRRCEditor btw. to be assigned to Tap, but therefore the H-Delay has to be open in MultiRack.
    In MultiRack you can also define a “session” tempo to have all delay-based FX set at once.

    But sorry again: I don’t see, why I should have an Tap-Delay opened while drastically changing it’s tempo? If you “re-tap” because the band is slightly varying in tempo, the shift won’t be that audible. In any other case (drastic tempo change in the song) I’d kill the delay-input anyways, because it will give me some trashy information (not only the shift, but rhythmic information, that’s nonsense in context of the song).

    But saying short: because the dLive behaves in this case like every Delay I know and every used, I don’t feel it’s an issue and rather appreciate to see A&H to implement some more common and useful features (like DCA-to-Monitor function or so). But only my thoughts …

    Regards Peter


    I think the point is that it’s noticeable if I go, quickly mid-song, say in a bridge part, from a 1/4 note tap to a 1/2 note tap, there’s quite a bit of time difference between the two, so you will get an audible shift. I’m definitely not talking about small shifts in tempo, those are tolerable. Even then, song to song isn’t as much of an issue, it’s just when the band does things like, need a big reverb-y half-time moment in the middle of a song and then I have to quickly snap back out of it – that’s where it becomes problematic.

    Already on the Midi mapping functions! Thanks for the heads-up. I have a shortcut set up that lets me use an entire bank of faders/buttons as contextual controllers for outboard Multi-rack processing. I’m using Live Professor as opposed to SoundGrid, but same idea. I *think* Live Prof is slightly more flexible in show controls/mapping/custom cues than Soundgrid, but I could be wrong? At any rate, the midi functionality of this thing is off the hook. (Sans no custom labels on the custom rotaries.)


    …and to answer the, “why wouldn’t you just map it directly?” point -> Ableton was acting as intermediary for contextual, musically-flexible time-based automation parameters. In this case, kill delay output, change tempo tap, return delay output. Again, it’s really an end-user decision: all the volunteers see is that they tapped the tempo, things happened, and it sounded good. (On the Fly, no audible pitch-shift.) I use Ableton for a number of other musically-timed automation controls as well: lights, console fades (X32 on occasion, which is built on OSC,) filter parameters, video cues, and so on. It just made sense to me to use it in this application.

    As an engineer, I totally respect and understand your position on delays; everything you’re saying makes sense, for engineers, or users with any base level of mixing skill. On the other hand, I have to be concerned about unskilled user interaction in a fairly comprehensive way; hence my obsession with delay “artifacts.”

    Thanks for the interesting conversation, appreciate your perspective sir! I’d still like to see the availability of a delay on dLive that behaves the same way as VENUE short/med/long, but I definitely agree there are other things that are deserving of attention before then.

    Profile photo of pete.j

    … the limitations to MultiRack are there, you’re right. At the other hand it’s quite simple and straight forward, what is what many engineers need for using as “virtual” FX- and/or Insert-Rack with a simple yet (for most cases) satisfying Snapshot system. But for more sophisticated use, you’re absolutely right there are other things (I never use LiveProfessor but used forte which may be similar). But when it comes to heavy usage of PlugIns with real low-latency MultiRack SoundGrid is hard to beat at the moment.

    But anyways this wasn’t the root of this discussion. And yes, there are uses, where you change from 1/2 to 1/4 or other. As a touring and studio engineers I have lot of use of this too. That’s why I always have in my templates at least 2 Delays setup (also for altering between heavily filtered delay to more standard one ore so).
    And – this is where in my understanding it’s bit different – it’s kind of unmusical having an “outringing” delay whilst changing timing (be it 1/4 to 1/2 or changing some beats) – for a smooth transition I’d then use a second delay OR bring it down anyways before the tempo change.
    Also – not saying you didn’t find a really interesting and well thought solution for this application – as I do lot of lecturing and sound engineering workshops I typically more tend to teach people thinking about what they’re doing. So if your volunteers are into “really good sounding mixes” – or least in such a detail that they change the tempo of a delay during a song for more sophisticated art of mixing – I’d rather would talk about when it makes sense to ride a delay on send and when on return and how a transition can be done smooth or what happens in the box.
    I more tend to give them the craftsmanship than the “voodoo-tools” (“voodoo” on this case, because the tools do things they don’t realize and understand and therefore in case of error they can not control or fix or transfer it to a similar situation but with just basic tools).

    So: I really think you’re did some quite tricky and clever workarounds that not many people would’ve done so easy. But – also in my view as an touring engineer – I also tend to keep things simple or break it down, because there is always possibility of failure when I’m not there and then nobody’s able to fix it and run the show, because I made the system too sophisticated.

    So at this point you’re absolutely right – different perspectives and/or needs and therefore slightly different approach (even I think you might be doing pretty similar sounding things with the delay as I do 😉 ).

    Regards Peter


    Absolutely agreed! Keep it simple when you can! I have a handful of individuals who can handle more than the “voodoo,” tools; and when people are able to actually learn/use that information I give it to them and have them learn the proper way to actually use the tools. (For what it’s worth, I even have a couple of folks working through Bob Katz concepts right now.) Unfortunately, I also work with a handful of individuals whose learning just caps off at a very basic level, so I do have to have a few of those tricksy tricks in my bag for those folks.

    I do agree that having a second delay on fader is equally useful, and just as good a workaround. I typically end up fading one out before the swap anyway. I guess part of where I’m coming from there is that it’s one more thing to keep track of/accidentally fade the wrong one (for certain individuals;) and I’m also used to working consoles with very limited channel strips/resources, so tend to compress returns to as few as I can get away with. In the Pro Tools example, the engineer also had to deal with not having any snapshots, or automation whatsoever; so not having to worry about the position of the delay fader was a big plus. (We were simultaneously recording multi-track, janky rig I know.) Obviously dLive doesn’t have that issue; and with the addition of modular dsp/fx racks, the sky’s really the limit. …or at least your DSP host Processor/RAM capacity is the limit.

    Profile photo of SteffenR

    are you shure that this is the right place to discuss the problems of other vendors?

    if the delay time changes between two taps what you expect to hear?
    The change is a dynamic process, if there is any audio passing through,
    you will hear the change in delay time
    if not, the FX is muted until the change is done
    that means as long as you tap you have no delay at all


    Apologies, I was only attempting to provide reference for what I perceive to be a lacking feature.

    I guess what I’m expecting to hear is a seamless transition between 1/4 and 1/2 note taps without burning another FX slot/return channel, or having to do a quick fade out/in. VENUE’s one delay does a pretty good job at that, and I’ve come close to the same effect with the Ableton automation layer I mentioned earlier. I absolutely understand it’s a dynamic process. What I’m saying is: in a digital system, with digital delays, there should be a built-in automation mechanism that provides a user with an option to remove those audible shifts entirely, without it sounding weird/unnatural. Is that so odd a request?

    Profile photo of SteffenR

    what I said already… if the change should not be audible you will get a short moment of silence from the FX because it has to be muted during the change in delay time

    on classic emulations this is not wanted because the originals will not act like that

    the challenge is to use the change
    you can do some wild things with the RE-201 and the clones tweaking the time or tapping with different “tempi”

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic.