Aux send introduces delay

[SonicBlue555]

There's a way (other than duplicating all the various sends to all the wrapped tracks) to get rid of the delay?
Is it particularly annoying with side chaining, since I couldn't figure out how to get the correct delay compensated signal.

[rosesbyrosex]

That kind of delay is mostly a thing of real time playing, when you export the audio most of the delay should be gone (the ones of internal sends, sidechains, outputs to another tracks) because the processing is diferent and takes all the time it need to process, just don't click export at 1x speed.

To compense in real time you can use voxengo delay compensation, but when you export audio it may be bad if the plugin is activated, is mostly useful in sample based intruments specially to compensate legato delay if the sampler don't have automatic latency compensatio.

http://www.voxengo.com/product/latencydelay/

[klangbastler]

There's a way (other than duplicating all the various sends to all the wrapped tracks) to get rid of the delay?
Is it particularly annoying with side chaining, since I couldn't figure out how to get the correct delay compensated signal.

are you using plugins with long processing latencies on returnbusses? or what is the exact exact routing scheme and what plugins are involved.

latency compensation is not happening in tracktion in some cases.
you may check that out with support, so they can tell you exactly what is compensated and to what extent (length of latency).

[SonicBlue555]

That kind of delay is mostly a thing of real time playing, when you export the audio most of the delay should be gone (the ones of internal sends, sidechains, outputs to another tracks) because the processing is diferent and takes all the time it need to process, just don't click export at 1x speed.

To compense in real time you can use voxengo delay compensation, but when you export audio it may be bad if the plugin is activated, is mostly useful in sample based intruments specially to compensate legato delay if the sampler don't have automatic latency compensatio.

http://www.voxengo.com/product/latencydelay/

Thanks, but it doesn't seem to do the trick. The part is misaligned even exporting it.

are you using plugins with long processing latencies on returnbusses? or what is the exact exact routing scheme and what plugins are involved.

latency compensation is not happening in tracktion in some cases.
you may check that out with support, so they can tell you exactly what is compensated and to what extent (length of latency).

I'm using Independence (but it does the same thing with TX16Wx and Structure 2), to trigger some drum samples that I have routed with its internal mixer to be outputted to separate channels. Then, with the Plugin Rack, I send those outputs to their respective channels in Waveform. The problem starts when I want to send (in this case) the Snare channel to a Reverb that is then gated with the Snare as a sidechain input.



I've noticed that even if you disable the Aux Send and bypass the Gate, just the fact that the Snare is selected in the Gate Sidechain input, generates a delay.

[rosesbyrosex]

Some time ago I got delay when using sidechain in trackspacer, and couldn't get rid of it at all, but changed to the waveform built in compresor and it worked well, so may it be a thing of third party plugins?
you should check this via tracktion support and make shure you are have installed and using ASIO Audio drivers in waveform

https://tracktion.zendesk.com/hc/en-us

[SonicBlue555]

Some time ago I got delay when using sidechain in trackspacer, and couldn't get rid of it at all, but changed to the waveform built in compresor and it worked well, so may it be a thing of third party plugins?
you should check this via tracktion support and make shure you are have installed and using ASIO Audio drivers in waveform

https://tracktion.zendesk.com/hc/en-us

Unfortunately not, it's the same with Waveform's own plugins. With the ASIO suggestion, you gave me hope, I was ready to throw my Mbox 2 Mini out of the window, since its ASIO driver usually are, how can I say, "particular". In this case, it works as expected, I've tried lowering the buffer to 64 samples, while it manages to play it better (with some crackles if I turn on other instruments), there's still a latency, you can notice it if you enable the Click.

I'll try to contact Tracktion directly, thanks!

[HansP]

Because of signal delay / latency issues,
I used rack instances in place of (aux effect) sends and returns, as there was a hint somewhere telling that built-in sends do not compensate latency.

If the rack is not too complex, it seems to work.
There's a preset rack that's just wires, and I did extend just that one, for a simple send.

For the send instance, I have to set "dry" to 0 dB and "wet" to -INF. L/R in and out levels: out = -INF, in = send level.
(optional: Quick control parameter = left input level.)
For the return instance, settings are similar to an instrument plugin.

In a rack, plugins with different latency must not run in parallel, nor with some direct signal bypassing that consists of a simple (zero-latency) wire. This would break the compensation algo once again.

Compressor sidechaining seems difficult, when there is variable lookahead. I used rack instances, and got some stuff actually working.

[klangbastler]

yes, latency-compensation does not work correctly with return-busses ... especially with higher latencies. i never went on to test if the compensation is maybe limited to a certain latency amount. this should be checked with support.
i don't know, if it is the reverb or the gate (is lookahead/pre-open active?? this is introducing latency) that throws in the latency, but i would test these two and maybe exchange with some plug that does not introduce latency.

i hope that in the future we will have a solution for this in waveform.
it is probably quite complex to exactly calculate latency-compensation send/return configurations, as the send can be inserted anywhere in a pluginchain on a track.

[HansP]

I think they did a good job already, but it's a pure math task, likely with iterative sorting and recursion, and when you go beyond some level of complexity, the recursion might blow up, or at least should tell (can't compensate any more, redlining plugins that are falling out).
It's worth an attempt. Compensation around the racks is kind of revolutionary, and I could get some constructions to work correctly.

[rosesbyrosex]

Also the audio buffer is very important when using sends i have problems when using a size larger than 1024, i alwas use 256 the minimun.

[HansP]

FYI caution about buffer size,
comparing results between 256 and 2048, with the "nulling" method, I get a pattern of artifacts.
T6 on notebook with i7, Win7Pro, realtek sound chip. using exclusive windows audio (no other program can use the soundcard while T6 is on)
obviously, 256byte has an issue here.
at first I compared the output (rendered) with 256 vs 2048, then I did the 1:1 test comparing input and output files with no plugin in place and volumes on 0dB.

[Mr Coffeehouse]

Sure Enough - Sends' delay compensation in Waveform doesn't work..

It pretty much makes them useless, which is most unfortunate.

This is a thing that -really- needs to be fixed if possible.


Best, Michael at The Coffeehouse

[dRowAudio]

Can i just clear this up and state that it's not that "Sends' delay compensation in Waveform doesn't work", it's that multiple send delay compensation doesn't work. (This includes the case where you have a Rack before a send).

The problem is that we don't currently have a way of delaying audio by more than a single block on any given track. (It's actually a bit more complicated than that but I can't explain in a concise way here).

If you stick to a single Rack or send per track everything should be in sync. Not ideal I know but that is the current situation.

[Mr Coffeehouse]

Thanks for clearing that up dRow. I was doing my tests with multiple sends per track indeed. I can certainly create ways to make this work similar to what I was going for with some creative routing.

Of course, I hope this is something the devs can tackle at some point.

Cheers, Michael at The Coffeehouse

[HansP]

Would it be a workaround in the programming, to do the following:

* Have a - perhaps recursive - algorithm that computes an ideal delay pattern for the whole project (every plugin analyzed and respected) and stores this in a comprehensive way, resulting in some xml also.
It does not care what we _can_ do, but is all about what _should_ be done to get a clean sync.
Later on we will talk about 'virtual plugins', and these have to be respected in the computation in a different way than the real plugins. (These are not part of the goals by the user, i.e. no audible influence on the ideal results is expected, but they are parasitic in a way they silently improve the situation with the unwanted flaws in the delay compensation.)

* Have another algorithm, that sets the delays on track level (I mean that what Waveform already can do), then reports all points where it failed to complete the requirements.

* Have one more algo, that inserts "virtual" delay plugins between the critical plugins, especially around racks and sends, and have the GUI show them in some dotted and greyed form, and they are numbered. On clicking, they show real and reported delay in samples and milliseconds.

Thus I suggest to create a paradigm of virtual tool plugins, that can use the common environment and JUCE functions, but are computed by the DAW for correction of certain issues.
Note that with a bigger reported delay (latency) rather the actual delay (which might be sufficient to be a constant zero), negative values may become usable.
The reported latency of the virtual plugin is not something to correct, leave out that branch, but is added up in the temp result of the track, as something that just happens, and happens to zero out the delta which was our flaw in the first place.

The goal is to iterate with step 1 a couple of times, respecting the newly created virtual plugins, and these are configured so that some of the requirements will zero out. This should make step 1 omit a certain path of recursion, and the whole thing should converge.

Each level relies on the meta data that the predecessor has created. But the first analysis as the "should be" remains in place and results are compared with it, to create a delta structure for next iteration.
At a certain point it will show the white flag and give up.

With this, it either works, or else something shows in red, and the user can attempt some different routings until things are ok.