Timing discrepancies in rendered tracks

Discussion about: tracktion.com
RELATED
PRODUCTS

Post

I've just noticed some timing discrepancies in tracks that have been rendered vs the original midi track/vsti. The odd thing (to me anyway) is that it changes depending on how I have my ASIO buffers set.

Here's the scenario: Midi clip playing a racked DR-008. Multiple rack filter instances on several tracks, various vst's on some of those tracks, all submixed to another track with PSP's Vintage Warmer on it. When rendered, and then played back together at low latencies, the tracks are very close in time. When I change to longer latency settings they are out of time by up to 5 milliseconds. Anyone have any ideas what might be going on here?

Another issue is that the Vintage Warmer plug is randomly getting "locked-up". All audio ceases passing through it until I disable/re-enable it. There's another instance of VW in the Master fx that also "locks-up" whenever the other does. I'm constantly disabling/enabling these two effects. I've tried Endorphin in place of the VW with the same result.

Anyone else have these kinds of problems? Any ideas what might be causing them?
Thanks

edit: I have additional info on the timing problem now. It seems that the simple act of trying to nudge the rendered track somehow corrects the timing. After I slide the rendered track ~45 ticks to the right (this corrects the timing), and save, when I reopen the project it still plays out of time UNTIL I nudge the track 1 tick to the left and back to the right 1 tick (back to the same value where it started). This resolves the timing issue until I change latency again or reopen the project.:nutter: :help: :!:
Last edited by bk on Fri Feb 04, 2005 6:50 am, edited 1 time in total.

Post

It's most likely the racks.

When used in multiple instances or as a multi-out enabler for multi-out synths it will introduce timing errors.

This is a knowm issue, and yes, it is directly linked to latency. The larger the latency the larger the timing disparity.

If you are using Racks to access the multi-outs of the Dr008, try building the entire thing INSIDE of a single Rack and the problem will go away. It gets very cluttered.

For sends I suggest using Senderella. http://www.kvraudio.com/get/1433.html

Try "Get out" for multi-outs.
http://subminimal.org/tools.php

There are other usefull tool here for Tracktion.
Last edited by P.T. on Sun Mar 13, 2005 12:27 am, edited 1 time in total.

Post

The only time I had similar issues it turned out to be because i had adjusted my latency settings:

I had a track with SIR inserted which was frozen. If I rendered without unfreezing the SIR track, the SIR rack would end up out of time. My assumption was that changing the latency of my card changed the amount of delay added by SIR, but Tracktion didn't realise and rendered the SIR track with its old PDC setting.

Unfreezing the SIR track and re-freezing it cured the problem..

Post

This is about multiple sends or using multi outs.

It won't be a problem with just a single send.

It is only apparent to the ear at higher latencies, but still exists at lower latencies and is screwing with the sound

If you use a drum machine with multi-outs and use Racks to route each drum sound to a new track, and also make a midi track of something like a simple piano part you can see the problem.

Make a simple drum pattern in midi.
Make a simple piano midi part.
One or two measures is enough.

Set Tracktions latency at something high like 40ms and render the piano.

Then render the entire drum part.

You now have 2 waves, a piano and a drum.

Line up the waves with the midi and you can see the drum hits in the drum wave and the piano notes in both the wave and midi.

The piano wave will line up with the midi, but the drums will not line up propperly with thw drum midi.

alternatly you could render the entire midi edit down to one wave and see the timing errors when compared to the midi.

Of course if you render each track individually you can shift them around to line them up propperly, but if you were to just render the entire edit down to one wave, you would have timing errors locked into the wave.

I hope I'm not rambling too much. I'm tired and due for bed.

Post

Thanks for the replies.
I can accept that racks will introduce timing errors, but those errors should be constant at this point (after rendering). I'm now ignoring the latency changes because I find a simliar shift by simply closing T and reopening the edit! I'm able to compensate for it by shifting the audio track 45 ticks to the right, but when I save the edit, close T and reopen, the errors return until I go in and move the rendered track again. I only have to move it 1 tick either direction and everything lines up instantly. :shock:

I'm going to try what you suggest PT, and build the whole drum mix in a rack to see what happens there.

re: getout. I thought racks obseleted getout. Are you saying it still has some advantages over a rack?
I'll give it a try as well. Thanks!

Post

I havn't checked in a while but I found Get Out to not have a timing problem. Or a very slight one.

I don't quit understand how it is that you are having troubles with the rendered wave changing. Once it has been rendered it should remain the same and stay in the same location.

You don't have the rendered track going back into the rack do you? Check the track routing.

Post

PT wrote: You don't have the rendered track going back into the rack do you? Check the track routing.
No, the rack input is midi only.

My recent experiments have shown that the safest way for me to do this is to build the entire drum mix inside the one rack. When rendering that scenario, I never have timing problems...ever.

Using "Getout" also works as well, but doesn't allow usage of any pdc plugs. :cry:

When using multiple instances of a rack on multiple tracks, everything is fine until I change the latency. Then it's off...forever! I can compensate and save, but it comes back next time I change latency or even reopen the project.

I've tried this with two different brands of semi-pro level sound cards (Audiophile 24/96, and Yamaha UW500), and I really have to say this is a bug in racks. I don't see any other explanation.

I'd email jules with this info, but I really doubt we'll be seeing bugfixes in T1 at this point. For all I know this may have been already addressed in T2. :?:

@PT: Thanks for the idea of putting it all in one rack. It's cumbersome, but at least it works!

Post

so how do you go about doings sends in side of a rack then?if your doing your whole drum mix in there hows it work.multiple senderellas inside a rack?

Post

Neil: Actually, I hadn't thought of that yet. :-o
The drum sample set I'm currently using has seperate samples for Dry, Overheads, and Room mics, so I can mix the individual reverb amounts in DR008. DR008 also has Aux sends available that show up in the rack that I could use as well. All the EQ, compression, and limiting I'm using is getting packed into one rack. There are an awful lot of vol/pan filters in there, and without labels it gets difficult to know which one I really need to tweak. :lol:
I think this one situation where I might actually try a mixer plug in Tracktion :!:

Post

bk wrote:Here's the scenario: Midi clip playing a racked DR-008. Multiple rack filter instances on several tracks, various vst's on some of those tracks, all submixed to another track with PSP's Vintage Warmer on it.
Do any of the "various vsts" have inherent latency? If so, try replacing them with alternatives that don't, or (if that's not an option) try inserting dummy versions of the same plugs on all the other outputs of the rack. ie: if you have the kick compressed with a look-ahead limiter, insert instances of the same limiter on the rest of the rack outs with "bypass" (no gain reduction) settings.

Post

Neil G wrote:so how do you go about doings sends in side of a rack then?if your doing your whole drum mix in there hows it work.multiple senderellas inside a rack?
You would have the effect, say a reverb, inside of the Rack.

Add 2 Vol filters for each output of the VSTi, also inside of the Rack.

Connect each output of the VSTi to a pair of Vol filters
(an output can have more than one set of cables coming out of it)
One of the Vol filters goes to the Racks output, this is the dry signal. The other Vol filer goes to the reverb, this is the wet or "send" signal.

Do this for each oof the VSTi outputs you want to "send" to the reverb.

Of course, this is quite a cluttered mess.

Post

PT wrote:
Neil G wrote:so how do you go about doings sends in side of a rack then?if your doing your whole drum mix in there hows it work.multiple senderellas inside a rack?
You would have the effect, say a reverb, inside of the Rack.

Add 2 Vol filters for each output of the VSTi, also inside of the Rack.

Connect each output of the VSTi to a pair of Vol filters
(an output can have more than one set of cables coming out of it)
One of the Vol filters goes to the Racks output, this is the dry signal. The other Vol filer goes to the reverb, this is the wet or "send" signal.

Do this for each oof the VSTi outputs you want to "send" to the reverb.

Of course, this is quite a cluttered mess.
thanks man. a cluttered mess indeed but finally a explanation :)
Neil G (Paper,SOWAT,motion,phobic,left minded,hawt,LA)

www.hawtmusic.com

Post

platinumears wrote: Do any of the "various vsts" have inherent latency?
Yes, but that doesn't seem to make any difference to one part of the equation. Here's a simple test anyone can try, to see what I'm talking about:
The subject I'm discussing here has to do with a small timing inconsistency introduced everytime you close/restart T or change your soundcard latency.

The test: Insert a multi out vsti (I used DR008) in a blank edit. Wrap it in a rack. Drag a single instance of the rack to several tracks. Record a 4 or 8 bar (make sure it doesn't start on bar 1, we all know that though, don't we? :hihi: ) midi clip to play the vsti. Quantize it. Make sure something is coming out of each output (ie:track 1,Kick; track 2, snare, etc.). Leave all volumes at zero to make the rest of the test easier. Render it and add to the project.
Now, add a Tracktion EQ plug to the audio track, set it for no EQ adjustments, just click the "invert" button. When played together, the midi tracks and the audio file should cancel each other completely. In my case, they do.

Here's where it gets weird.

Save the edit. Close T and reopen T. Reopen the edit. Click "play". Do they still cancel? I bet they don't. I've tried this on two different semi pro soundcards, and both responded the same way.
Now, how to get it back? Click on the audio track. Zoom all the way in so snap resolution is one tick. Press ctrl+"arrow key right" to nudge the audio track one tick right. Now nudge it back one tick left. I'm willing to bet the sound cancels again for you. Anybody have an explanation?

Post

bk wrote:Now, add a Tracktion EQ plug to the audio track, set it for no EQ adjustments, just click the "invert" button. When played together, the midi tracks and the audio file should cancel each other completely. In my case, they do.
Noy over here they don't :? I don't have dr008, but every multi-out plug I try it with produces phasing effects when mixed with the rendered version.. :?:

Post

platinumears wrote:
bk wrote:Now, add a Tracktion EQ plug to the audio track, set it for no EQ adjustments, just click the "invert" button. When played together, the midi tracks and the audio file should cancel each other completely. In my case, they do.
Noy over here they don't :? I don't have dr008, but every multi-out plug I try it with produces phasing effects when mixed with the rendered version.. :?:
they dont here either (WITH dr008) but the wierd audio shift thing on save ... close ... restart ... reopen i CAN confirm ...

... and that a one tick nudge / renudge puts things back in their original place again ...

slainte :? rob

Post Reply

Return to “Tracktion”