Is PDC impossible to get right?

[kL]

I know I'm getting tiresome about this, but it's another day when I'm having to constantly workaround the faulty, inconsistent plugin delay compensation and rewire timing of Tracktion and I'm wondering, is it impossible to get right, does no one else care, does Mackie not care, or have they forgotten?

(If the last is the case, consider this minor annoyance of a post -- and forgive as -- just another in a series of friendly reminders from someone sick of explaining to others why in his favorite, albeit unconventional, host it is impossible to put a plugin after a vsti without getting the added benefit of a delay... sometimes.)

[bk]

What exactly are the problems you're having with pdc?
It works flawlessly for me, unless a rack is involved, and it's usually ok then as well.

[P.T.]

Racks can cause timing issues. If you are using a Rack try putting a rack on every track. Depending on how you use Racks they can add a delay equal to the latency that you are using.

[kL]

"Can cause" and "usually" are scary words when it comes to timing. In some ways, random is worse than always.
But this does always happen: rewire tracks play back with the latency delay. And quite often putting a compensated plugin after a VSTi will cause it to do the same... But not always. And this indeterminacy plays just as much hell with recording sessions as it does with grooves.
The essence of recording music -- Job One, if you will -- is spacing events in time. We have complex plugins that introduce delays? Fine. They report those delays, which are compensated for. There is no room in this formula for it to work "sometimes." A system that is "subtly" broken is a system that is broken. Period.
Tracktion's code needs to be gone through with the comb whose teeth are fine enough to comb the hair of the proverbial fine-toothed comb. PDC needs to work with racks (or why are there racks?), with every plugin in every situation (audio track, VSTi, whatever and wherever and how many in the chain) all the time, and with rewire.
There shouldn't be so much as a millisecond of delay anywhere that wasn't put there on purpose.
Then we need a color editor.

[djsubject]

heres a tip!

rember PDC in Tracktion works by moving clips (AFAICT)

so any situation where the sorce meterail is not on a track or ruted to a track that needs PDC then there will be no PDC!

workarounds are

1) use voxingo audio delay (free plugin) to delay the other tracks to match the needed PDC

2) put all sorce data (IE, midi or audio) in Tracktion,
& not leave it in your rewire host

3) wait for T3

it's a real pain in the beep i know, & the workarounds needed dont match the tracktion way (simple is the Tracktion way IMO)

but its a small price to pay for all you get (& it will get fixed one day )

Subz

[bk]

PDC needs to work with racks (or why are there racks?), with every plugin in every situation (audio track, VSTi, whatever and wherever and how many in the chain) all the time, and with rewire.

I think the flexibility built into rack filters makes this nearly, or completely impossible.
If restrictions were made on the way things can be routed in racks, you might be able to accomplish this goal, but then someone else would be pissed 'cause their favorite routing was missing.

The only problem I've noticed lately is with SIR in a rack. With SIR disabled I get disjointed time. However, when enabled, everything plays back perfectly. Other than this, pdc works perfectly for me, and is completely consistent.

Rewire....? haven't a clue!

[kL]

dsubject, thanks for the advice. I've got workarounds for everything, but like you, believe they fly in the face of Tracktion's otherwise stellar ease and speed of operation.

bk, I don't know why rack filters should be impossible to compensate, whatever the flexibility/routing/whatever. And don't believe that should be the case. But I'm glad that PDC is completely consistent for you otherwise. I wish it were for me.

For example: when Rewire tracks play back delayed by the amount of the latency, they still render perfectly in time.
But in other situations -- in the case of Microtonic followed by an instance of Voxengo Tapebus -- the track not only plays back delayed, but also renders that way. (The workaround being, obviously, render it then slide it back in time...)

Which is odd. As is waiting for the third release of program to have it be -- with any luck -- bulletproof in such a fundamental way. It would be like refining the cosmetics and comfort of an automobile that still doesn't always head -- exactly; consistently -- in the direction you steer it.

[Beno]

kL,
I can understand your frustration and want to tell you that PDC is definitely on our priorities to improve. But I must clarify that many of these fixes are low level fixes to Tracktion's audio engine which is why they have not been addressed sooner. They require a good deal of work.
The best way for you to help is to describe specific situations that PDC fails. Providing archives with instructions is really helpfull too. The more reproducible scenerios that we have, the easier it is for us to fix. If you can reproduce a failure using only free plug-ins, that is even better.

I'll have a look at the situation you describe above.

Ben

[P.T.]

The Rack problem I came up against was with a multi-out plugin.

I had set up a drum sampler using a rack to output each drum to it's own track so that I could do different EQing and add different effects to each drum.

When I had rendered the result it didn't sound right.
On close examination of the rendered wave and the original midi I saw that the drums that had been sent to individual tracks were out of sync.

So, I redid the drums putting the whole setup INSIDE of the Rack. It got very cluttered with all of the EQs and reverbs etc in there, but it solved the timing problem.

I have been told that the first method of outputting each drum to a seperate track will work if you put an empty rack on every track, which I suppose equalizes the time shift that the rack causes. The time shift in this case turned out to be equal to the latency that you are using.

[djsubject]

The Rack problem I came up against was with a multi-out plugin.

I had set up a drum sampler using a rack to output each drum to it's own track so that I could do different EQing and add different effects to each drum.

When I had rendered the result it didn't sound right.
On close examination of the rendered wave and the original midi I saw that the drums that had been sent to individual tracks were out of sync.

So, I redid the drums putting the whole setup INSIDE of the Rack. It got very cluttered with all of the EQs and reverbs etc in there, but it solved the timing problem.

I have been told that the first method of outputting each drum to a seperate track will work if you put an empty rack on every track, which I suppose equalizes the time shift that the rack causes. The time shift in this case turned out to be equal to the latency that you are using.

to get this set up to work correctly you will need to move the midi to the correct track

so if you have a track outputting the snere then move the sneres to that track...ect ect...

or


find the PDC needing plugin & put one on each output of the rack unprossesed, that way the pdc need for all outs will be equall

hope that is of help

Subz

[kL]

Thanks, Beno. I'm glad you guys are on it and I understand how things can be buried deep into code. The Rewire latency bug is easy to replicate; I believe that Microtonic and Tapebus are available as demos. If anything else obvious comes up I'll let you know.

[Beno]

Thanks KL!

[valley]

Thanks KL!

I can give you a pretty detailed list of working and non working PDC situations if you need.

[kL]

Valley, I wouldn't mind a cc of that one, just to see what you're getting and where it coincides with what I'm seeing...

[Beno]

Well lets maybe get together a sticky post for this,eh?
People can post all there issues. One per post. With a preset list of things we need to have in each post.
Ben