I am using mono-delay to create some interesting sounds by automating the delay time in milliseconds, the trouble is as the loop cycles it is quite different each time. Is there any way I can ensure the sound is the played the same on every loop? I have no idea what is triggering the delay, clearly it is not the position in the arrangement or the waveform of the sample. I would just render a long series of loops and pick the best one but the effect is on drums at various degrees of wetness so this is not really the best solution.
Nothing is triggering the delay… it just delays the signal by a given amount of time and feeds the output back to the input. It does this with all signals that you send to the delay.
It should not change if the loop is not changed, but keep in mind that it doesn’t “reset” on the end of the loop, it just processes the signal all the time.
Maybe you should use a different plugin? Or automate the send and return levels too.
If the audio event is being delayed from the same start point each time i.e each sample of the audio then why does the delay sound different on each loop?
This should be a very simple and predictable effect, take one sample and repeat x milliseconds later, I don’t understand where this randomness is coming from.
Note I can start the loop with zero feedback to cut out any looping feedback but it is still a random sound.
It’s because (as @st10ss points out) there is no “trigger” for the delay. As soon as you hit “play”, it will delay whatever you feed it, and it will not clear its delay buffer if you go around in a loop. In other words, the trigger for it to start delaying your audio is when you hit “play”.
As far as the “randomness” goes, you’re just hearing the delay tails when you go around in a loop. For example, if your loop is, say, 800 msec long, and you have your delay set to 100 msec: When you first hit play, the delay buffer is empty, and you’ll start hearing your delay tails after 100 msec. After 800 msec, when your loop cycles, you will hear the last 100 msec of the end of the loop as your delay tail.
So that explains it, but I understand your use case. It sure would be nice to have a “clear delay buffer” setting that could be triggered via automation, a nice #feature-request (you should tag your post as such if you/others concur).
One thing you might want to try is to simply mute the delay for the length of your delay buffer at the beginning of your loop (this is easy to do via automation). That way you won’t hear the delay tail from the end of your loop, and you should be able to achieve what you’re trying to do (I think!).
The thing is I can stop the transport, go to the beginning of the loop and press play then press stop after the event and repeat this process and the effect is still playing randomly, so it doesn’t appear to be starting the delay from when I press play.
The begging of my loop (which is is quite a few bars) has the mix and feedback all the way down to zero, it’s like this for at least a bar. So I would expect the buffer of the delay to be empty at the start, especially if I am stopping play back and starting from the beginning of the loop.
Can you make a video of what you are describing? I think it will help others understand what you are describing.
What if you disable the automation of the delay time? Same behavior?
It seems if I have a constant delay time then there is no randomness, I suppose if the time delay amount is on a ramp due to automation this will inevitably lead to rounding errors (given there is feedback going on as well). Not sure why the rounding errors would be different each time though.
Wait, you say you change the delay time on playback?
And you really wonder that it’s changing?
It shouldn’t be a different sound each time the loop repeats, yes it should change over time of course.
Yep, there is something going on which I cannot really explain.
Best to test with a simple setup: 4 bars of quarter notes with quarter rests, playing a simple sample, so you have a consistent test signal.
Now insert MonoDelay (or StereoDelay), zero feedback, no filters, 30% wet or so. Let it play in a cycle loop. Seems consistent, no problem.
Now draw in some automation, e.g. with the triangle tool. Just some slight variations, not massive jumps, just alternating for 50ms or so. Now, when playing in a loop for some time, I notice a continuous shift in rhythm, until the repeats nearly align with the original signal, then they go back. As if slowly moving from a shuffle to a straight beat.
This cannot be explained anymore by the automation of the delay time, imho. Some buffers not being cleared or whatever.
But it is only when playing in a loop, else the delays work correctly (tested with render in place and a null test)
I did the same test with ValhallaDelay (Digital Mode, similar settings) and the repeats stay consistent (apart from the time modulation, of course).
Quick Fix: Use ValhallaDelay. Sounds much better anyway 
Thanks for checking, I guess there is no current way to make it work or least be able to hear how it’s going to render. I think I’ll freeze the track and hopefully the randomness is going to bake in something that sounds good.
It would be good if Steinberg could fix this.
If you freeze/render in place, everything is created correctly, as is when Cubase plays the first pass of the cycle loop. The issue only appears in the subsequent passes of the loop.
I confirm there’s a issue when reading automation on delay value.
Just did the test with a triangle automation on a one bar loop with snare on beats 1 and 3. The automation nodes for these beats have the same value, so it’s supposed to sound the same, but for some reason it reads a slightly different value every time and this makes the delay sound random.
Doesn’t happen on reverbs pre-delay and any other third party plugin. This is on Steinberg’s delays.