end of story: in what situations do I want "preserve PDC delay in recorded items"

[Jae.Thomas]

Or, more accurately, this function, found by right clicking the record arm button:



my questions, please answer one or all simply if you can (was that sentence even english?) I have read a few threads on this, and it is unclear to me still.

1. what exactly is the purpose of this setting?

1. With Audio?
2. With Midi?
3. With Live Mixing?

- if it's the same situation, 1 answer would be fine

2. In what situation would I need this?

3. In what situation could it make things worse?

Thanks, and sorry.

[Jae.Thomas]

should probably be in reaper Q and A, sorry.

[karbomusic]

Taking a really wild guess here but weren't there situations where a musician would automatically compensate for the tiny delay they hear from the monitors (monitoring through reaper) and you want that to be recorded because they compensated already? I think its similar to that in some remote way but I'm probably way, way off. I usually monitor off the sound card (aka mics not vsts) and don't think I actually ever hit that situation.

[Jae.Thomas]

I typically monitor through VSTs, and have vsts on during playback. I do try to eliminate certain delay-laden plugins, but sometimes I might leave a couple on if I dont find it affects my playing.

[James HE]

you may sometimes need it when using re-insert and bouncing a stem, otherwise the compensation may happen twice.

...don't quote me on that though.. lol. I actually can't remember the solution to that problem last time I needed it.

Also, I sometimes use ReaVerb 100% wet as a confidence verb while tracking when I don't have my hardware up. The latency acts as a pre delay. In the instance I sometimes record to an extra track the wet signal, if I want it as I hear it, I check preserve PDC delay.

[Billoon]

I'm pretty sure its designed exclusively for VSTIs.

What it does is offset the recorded midi on the timeline so when it plays back it, the timing is as you heard it when you recorded it.

I always use it except when using input quantise.

[EricM]

The answer is simple:

- always use this function when the PERFORMER monitors
himself (processed or not) through Reaper (midi or audio)

e

[Billoon]

I don't use it for audio cause it doesn't preserve all of the latency.

I do a loop back test and enter that amount (plus any latency introduced by plugins) in the input manual offset box, which is a rather tedious workflow.

I've reported it years ago and recently made a FR to improve this.

[Jae.Thomas]

the answer seems really unclear to me still...

thanks everyone for your help, I guess I still don't get it.

[Justin]

If you monitor through a plug-in that has latency (say, ReaFIR with a large FFT Size), which causes the output to be delayed, and you want to have the recorded item sound like you heard it (i.e. you're playing guitar and playing the notes early in order to make it sound right). With this option on, it will play back the same way you heard it as you played it, with the option off it will be earlier (as the PDC of ReaFIR will take effect).

Alternatively, you could just tell REAPER to ignore ReaFIR's PDC...

[Jae.Thomas]

ok, that brings together everyone's comments now...

so, if you have no plugins with latency, or they are deactivated (if you aren't feeling any latency), you don't need it. But it won't hurt to leave it on, right?

And are there any problems with this function at the moment?

Would you say this function is "record what you hear?"

instead of "record what actually happened" ??

and if so, are there any problems with this function currently?

[bitrate]

Reading this topic reminds me to ask an additional question to Jason's (his takes priority of course)

In Logic, there was a pref setting for PDC across everything. Set it and forget it. Moving to REAPER, I hadn't thought of that until now. Other than "preserve PDC.." or "Audio driver reported latency", do I need to do anything else so that I'm set as before? I kind of took some things for granted in the other DAW that I may have forgotten about now.

[Billoon]

Originally Posted by Jason Brian Merrill

And are there any problems with this function at the moment?

For MIDI, no. For audio, absolutely.

It's demonstrable and repeatable. Its been reported years ago and should be fixed.

Theres a zip file attached with projects and a read me that explains it.


Justin, please check this out and fix it.

[Dstruct]

Originally Posted by Jason Brian Merrill

But it won't hurt to leave it on, right?

That's how I understand it.

Originally Posted by Jason Brian Merrill

Would you say this function is "record what you hear?"

Yes.

Originally Posted by Jason Brian Merrill

instead of "record what actually happened" ??

Yeah. You don't capture your real timing with it anymore (hitting a key on a keyboard).

[Billoon]

Originally Posted by Jason Brian Merrill

so, if you have no plugins with latency, or they are deactivated (if you aren't feeling any latency), you don't need it.

You still need it if you want to record what you hear because otherwise it will compensate for the ASIO buffer and your recording will be early.


I've been banging on about this for a few years now, but unfortunately it doesn't look like its going to be improved at all.

See these links...

http://forum.cockos.com/project.php?issueid=842

http://forum.cockos.com/showthread.php?p=343187

[EricM]

@Billoon as you've demonstrated, the Record: Output (MIDI)
method indeed does work best (item position and timing wise
when monitoring through Reaper), I agree that Record: Input
with Preserve PDC should yield the same result.

e

[Jae.Thomas]

Originally Posted by Billoon

You still need it if you want to record what you hear because otherwise it will compensate for the ASIO buffer and your recording will be early.


I've been banging on about this for a few years now, but unfortunately it doesn't look like its going to be improved at all.

See these links...

http://forum.cockos.com/project.php?issueid=842

http://forum.cockos.com/showthread.php?p=343187

whoa it looks like we need help there! 3 years old bug....

[brainwreck]

Being that timing of a recorder is foundational, I would think that there wouldn't be any ambiguity over this. Reaper could really use a more user friendly way of setting up latency compensation and pdc, and for checking that everything is exactly as it should be, whether it is audio or midi timing. This thread is proof of that. Wondering if your timing is getting hosed by the recorder is terrible. And the issue that Billoon brought up, yea, that seems to fall in this foundational area. This kind of stuff shouldn't be left for users to play guessing games, or for having to use workarounds. Minute timing issues can really screw up the feel of music, but at the same time, detecting what is wrong can be impossible without the technical know how to test that things are as they should be.

[Billoon]

Originally Posted by Jason Brian Merrill

Or, more accurately, this function, found by right clicking the record arm button:



my questions, please answer one or all simply if you can (was that sentence even english?) I have read a few threads on this, and it is unclear to me still.

1. what exactly is the purpose of this setting?

1. With Audio?
2. With Midi?
3. With Live Mixing?

- if it's the same situation, 1 answer would be fine

2. In what situation would I need this?

3. In what situation could it make things worse?

Thanks, and sorry.

1.

Preserve PDC delayed monitoring in recorded items can be used when recording and monitoring through Reaper.

Its purpose is to ensure that what is heard when monitoring through Reaper during recording is what is actually recorded.

It works by shifting the recorded item on the timeline to the right by the necessary amount to achieve this.

If you are monitoring externally, it is not needed or applied.


With Audio-

Currently, IMO as described earlier in the thread, it is not accurate when used for recording audio. Vote here for this to be fixed please...http://forum.cockos.com/project.php?issueid=842


With MIDI -

It works as described above.


With Live Mixing -

Not applicable.



2.

You would need this when you are both recording and monitoring through Reaper and would like the recording to reproduce what you heard whilst recording.

You wont need it if not monitoring through Reaper or if using "Input Quantize".



3.

It will break "Input Quantize". If you have both settings enabled, your recording will not end up quantized to the grid as it will be shifted off the grid by the "Preserve PDC...." setting.

Another issue is that because it shifts the item on the timeline instead of the recording within the item, if you started recording on a grid line your recrded item wont end up there. If you want to use it in a loop, you'll have to fix this yourself.

Does that cover it?

[bmanic]

I use it always. I can't even begin to imagine why somebody would have it turned off when monitoring through Reaper, for instance playing a VSTi. It's absolutely vital for any kind of live playing of VSTi plugins to keep the groove going as you heard it, even at low latencies (I have asio buffers set to 64 samples but the DA converter adds quite a bit more on this crappy Orpheus interface).

Cheers!
bManic

[Nip]

Originally Posted by bmanic

I use it always. I can't even begin to imagine why somebody would have it turned off when monitoring through Reaper, for instance playing a VSTi. It's absolutely vital for any kind of live playing of VSTi plugins to keep the groove going as you heard it, even at low latencies (I have asio buffers set to 64 samples but the DA converter adds quite a bit more on this crappy Orpheus interface).

Cheers!
bManic

Do you mean running arpeggiators on host tempo and stuff?

Than midi sync line up differently/correctly when on?

For audio you are just complicating things - and have to do alignment while mixing manually if it's on when recording, or?

And as I read Justin's explanation 'preserve..' does nothing while recording - it's where it positions item when done recording that is affected.

Or is it that PDC is turned off while monitoring as well for that armed track - if 'preserve' is on?

When preserve off - recorded clips are adjusted early by the used PDC, so when played back next time - with or without PDC - it lines up perfectly with other clips in system. Everything you listened to(beat, metronome) is PDC amount late - and thereby positioning clip that amount early to get perfect alignment.

When preserve on - clip is positioned exactly on the timespot every sample/midi tick came into system - as you played it.

When delay through system becomes somewhere 20ms and more, you seriously get problem play and monitor through Reaper at all. More than 10ms you can notice delay, but it does not inflict on playing that much - for me anyway. Better than 10ms you are definately ok.

So if roundtrip delay is so severe that you adjust your own playing due to your own monitoring what you play, by playing a bit early, then preserve might be on option then?

As long as you hit a key - and audible response is immediate - there is not need for this 'preserve' thingy as I see it.

Or I got it wrong once again.

[brainwreck]

Revisiting this. Audio....pick your timing. I have to say that I'm more confused about how timing is handled in Reaper than ever before. I guess that I never looked at it close enough. Take a look at this pic to see what I mean.
https://www.box.com/s/r0ix4ibs02l33p09sepv

MIDI looks good, except...where is the compensation figure coming from? For example, in the pic below, the difference between recorded MIDI and recorded audio output is 7 milliseconds. Where is that number coming from?
https://www.box.com/s/gsyk6q20pecpzld5kd3y

[karbomusic]

Originally Posted by brainwreck

Revisiting this. Audio....pick your timing. I have to say that I'm more confused about how timing is handled in Reaper than ever before. I guess that I never looked at it close enough. Take a look at this pic to see what I mean.
https://www.box.com/s/r0ix4ibs02l33p09sepv

MIDI looks good, except...where is the compensation figure coming from? For example, in the pic below, the difference between recorded MIDI and recorded audio output is 7 milliseconds. Where is that number coming from?
https://www.box.com/s/gsyk6q20pecpzld5kd3y

LOL, I know that look tracks wise. I don't know the answers but my last calibration a few days ago showed everything I was doing was lined up correctly. As in my midi tracks + my audio tracks + my rendered stems etc, all lined up. I do the loopback etc, make the offsets in the record settings and go with it revisting as needed.

[brainwreck]

Originally Posted by karbomusic

LOL, I know that look tracks wise. I don't know the answers but my last calibration a few days ago showed everything I was doing was lined up correctly. As in my midi tracks + my audio tracks + my rendered stems etc, all lined up. I do the loopback etc, make the offsets in the record settings and go with it revisting as needed.

Speaking of loopback testing, I was tweaking my template a bit during this, trying various wave shapes and frequencies, when I noticed (and found out more about) how square waves are treated by digital converter filters, especially lower frequency waves. That's an eye opener into the nature of digital audio. See: square_wav.png

[karbomusic]

Originally Posted by brainwreck

Speaking of loopback testing, I was tweaking my template a bit during this, trying various wave shapes and frequencies, when I noticed (and found out more about) how square waves are treated by digital converter filters, especially lower frequency waves. That's an eye opener into the nature of digital audio. See: Attachment 17494

Yes sir, I noticed the same when I started using my "onesquaresample.wav"

[Tod]

Originally Posted by brainwreck

Speaking of loopback testing, I was tweaking my template a bit during this, trying various wave shapes and frequencies, when I noticed (and found out more about) how square waves are treated by digital converter filters, especially lower frequency waves. That's an eye opener into the nature of digital audio. See: Attachment 17494

Hey brainwreck, so what you're saying is that by going out and coming back in, that's what the square wave turns into?

Any way to know how much the result is caused by the going vrs the coming.

[timlloyd]

Looks like the result of a HPF, probably for removing DC; afaik, could be either a/d or d/a or both ... to know which probably requires an analogue measurement. But, if not both, probably the a/d.

Regardless of that, there's also an anti-imaging LPF on the way out, and an anti-aliasing LPF on the way back in. 'Idealised' square waves cannot exist as audio signals, so no matter what, the result is going to 'look' different to the original visual ...

[brainwreck]

Originally Posted by Tod

Hey brainwreck, so what you're saying is that by going out and coming back in, that's what the square wave turns into?

Any way to know how much the result is caused by the going vrs the coming.

Yes, that is what's going on. A function generator and an oscilloscope could be used to look at where the wave is being reshaped. I have neither.

[brainwreck]

Originally Posted by timlloyd

Looks like the result of a HPF, probably for removing DC; afaik, could be either a/d or d/a or both ... to know which probably requires an analogue measurement. But, if not both, probably the a/d.

Regardless of that, there's also an anti-imaging LPF on the way out, and an anti-aliasing LPF on the way back in. 'Idealised' square waves cannot exist as audio signals, so no matter what, the result is going to 'look' different to the original visual ...

Looking at higher frequencies and higher sample rates, the loopback recording looks much more square'ish. I'm curious to know why lower frequency waves, no matter the sample rate, get so wildly reshaped.

[Billoon]

Originally Posted by brainwreck

Revisiting this. Audio....pick your timing. I have to say that I'm more confused about how timing is handled in Reaper than ever before. I guess that I never looked at it close enough. Take a look at this pic to see what I mean.
https://www.box.com/s/r0ix4ibs02l33p09sepv

MIDI looks good, except...where is the compensation figure coming from? For example, in the pic below, the difference between recorded MIDI and recorded audio output is 7 milliseconds. Where is that number coming from?
https://www.box.com/s/gsyk6q20pecpzld5kd3y

Yeah, midi is fine. Audio however...

A - The input gets latency compensated

B - The delay due to monitoring gets (inadequately!!! - see below) preserved in the item.

C - The delay due to monitoring (again inadequately) and plugin delay gets preserved in the item.

D - As the audio is early, i would bet my house you've accidentally got the 'record output (latency compensated)' option on. If you had used the 'RO (nlc)' option, you would have an item that correctly has the delay due to monitoring and plugin delay preserved, but it will also have the FX printed in the item.

E - Should be the same as C, its not far off so there may be some small variation caused by the plugin used (LFO?).

F - Input FX don't get latency compensated, so the audio is late by the plugin delay amount.


As i have stated and demonstrated repeatedly for years now, "Preserve PDC..." is not correct for audio. It never used to be for midi either but that got fixed a while back.

When people say Reaper is 'audio-centric' or that midi doesn't get the attention audio does, i cringe a little because to me, accurately record timing should be a fundamental requirement for a daw and in this case, it is for midi but not for audio.

I have given a repro for this earlier in the thread (http://forum.cockos.com/showpost.php...6&postcount=13) and there has been a confirmed issue in the tracker for this for nearly 4 years now (http://forum.cockos.com/project.php?issueid=842).

I just don't understand why they won't fix it???

[brainwreck]

Originally Posted by Billoon

Yeah, midi is fine. Audio however...

A - The input gets latency compensated

B - The delay due to monitoring gets (inadequately!!! - see below) preserved in the item.

C - The delay due to monitoring (again inadequately) and plugin delay gets preserved in the item.

D - As the audio is early, i would bet my house you've accidentally got the 'record output (latency compensated)' option on. If you had used the 'RO (nlc)' option, you would have an item that correctly has the delay due to monitoring and plugin delay preserved, but it will also have the FX printed in the item.

E - Should be the same as C, its not far off so there may be some small variation caused by the plugin used (LFO?).

F - Input FX don't get latency compensated, so the audio is late by the plugin delay amount.


As i have stated and demonstrated repeatedly for years now, "Preserve PDC..." is not correct for audio. It never used to be for midi either but that got fixed a while back.

When people say Reaper is 'audio-centric' or that midi doesn't get the attention audio does, i cringe a little because to me, accurately record timing should be a fundamental requirement for a daw and in this case, it is for midi but not for audio.

I have given a repro for this earlier in the thread (http://forum.cockos.com/showpost.php...6&postcount=13) and there has been a confirmed issue in the tracker for this for nearly 4 years now (http://forum.cockos.com/project.php?issueid=842).

I just don't understand why they won't fix it???

A and B. Why is the timing of B different than that of A, since monitoring through Reaper is common to both, and B actually has no plugins in the path? I turned on pdc for B to see if there would be any change in timing, which there was, but I don't see what Reaper is compensating for, here, as there are no plugins running on that track. Do you mean that pdc is accounting for added latencies from plugins on other tracks?

D. Doublechecking that test project. Compensation is off - 'Record: output (mono)' was used, here.

E. The plugin on all tracks that have fx is Amplitube - just a single amp and cab sim, nothing else.

Also, for MIDI, what do you about how Reaper compensates for latency? In the MIDI screenshot that I posted, there is a difference of 7 milliseconds between MIDI notes. Where is that compensation figure coming from?

[Billoon]

A and B are different because on track B you chose to preserve the monitoring delay and on track A you didn't.

This is the delay between when you strike the strings and when the sound comes out your speakers.

Track A gets this delay/latency compensated so the item will play back when you hit the strings.

Track B will play back what you heard coming out your speakers ie. delayed (well it would if they fixed it ).


D. - OK, in that case, you must of had other plugins running. "Preserve PDC..." will preserve the total latency at the time which means it will record what you hear. The total latency is the sum of your ASIO buffer plus any additional latency caused by plugins that require it. You can work out what this will be by adding up all the PDC figures in the performance meter to the results of a loopback test.

Record Output will just have the latency of the plugins on that track plus the ASIO buffer, so in this case it will be earlier than the track with "preserve pdc" on.

E - I guess the latency can vary a little with sims/impulses.

MIDI - Its just preserving the delay between hitting the key and sound coming out the speaker, thats all. Again, it means it records what you hear(which is delayed by the ASIO buffer) instead of what you play whilst recording.

[bmanic]

BUMP!!

Preserve PDC for recorded items is a very important setting for most people and it is NOT handled well at all still.

People who are very sensitive to timing and are monitoring through Reaper will need to keep this option on because it forces the audio to be aligned exactly as they heard it through the monitoring. If the latency gets compensated after recording (default behavior with this option unticked) it means the audio does not correspond to what you actually played. The timing is off by the asio + AD/DA latency amount (it's late).

So, what's wrong with it? Well, the media item when recording a midi clip gets completely weird and screwed up. Just look at what happens to it (see attachement).

This is extremely annoying! I've recorded drummers who use Roland V-Drums that are amazing at delivering good feel and timing and it is IMPOSSIBLE to get the groove just right without having the Preserve PDC option enabled, even at seriously low latency (about 5ms including DA conversion) the timings get all messed up in relation to other tracks and with midi recording it's a HUGE chore to "fix" this broken behavior.

With audio recording it is a lot simpler but it can still be a big issue when you start splicing tracks and aren't zoomed in properly. It can result in media items snapping to each other in a weird way.

Please, this needs to be fixed. I can not understand why it's even happening with midi. Why not have an option where the media item start of midi items is always snapped to a beat or something. This would avoid these silly situations.

Cheers!
bManic

[beingmf]

Originally Posted by EricM

The answer is simple:

- always use this function when the PERFORMER monitors
himself (processed or not) through Reaper (midi or audio)

e

This! I use it all the time – night and day difference. i wonder how you've ever been able to capture a "tight" recording without PDC compensation.

[DuraMorte]

This thread confuses me.
I have never used any of these settings. I primarily record guitars, bass, and vocals, and have never had issues with timing. Recording through Guitar Rig at 128 samples yields tracks that line up as close as I'll ever need them to. If there is any discrepancy, I haven't noticed it.

[Nip]

Originally Posted by DuraMorte

This thread confuses me.
I have never used any of these settings. I primarily record guitars, bass, and vocals, and have never had issues with timing. Recording through Guitar Rig at 128 samples yields tracks that line up as close as I'll ever need them to. If there is any discrepancy, I haven't noticed it.

Same for me - it's automatic for most uses.

But some prefer to fiddle manually with all the nudging of recordings - or on the system they have they get closer to proper timing by skipping PDC alltogether.

If you cannot get low enough latency to monitor through Reaper could be one reason.

[witti]

For me Reaper records fine when i enable "use audio driver reported latency".
Never had any timing issues !

As far as i understand you use "preserve pdc delayed monitoring..." only
when you add effects which introduce latency.

Didn't read the whole thread so correct me when i'm wrong.

[Jae.Thomas]

I still don't get it...

I recorded with preserve PDC on today, because I was playing a VSTi, and it seemed to work but then was out of sync with the metronome and seemingly, the grid!!!!

[Nip]

Originally Posted by Jason Brian Merrill

I still don't get it...

I recorded with preserve PDC on today, because I was playing a VSTi, and it seemed to work but then was out of sync with the metronome and seemingly, the grid!!!!

If looking at peformance monitor - what was largest pdc used on any loaded track?

Would that coincide with the difference in position of you midi?

If listening to something that have largest PDC 256 samples, normally the recording would adjust that position 256 samples early from when arrived. Then it all will line up(as we all are very good musicians, of course).

If turning "preserve..." thingy on, you turn off this ability to adjust.

"preserve..." does not turn off all pdc, as I understand it. Just on track-by-track basis.

[Billoon]

For those that are confused or don't really understand what this feature does, it's very simple...

With it on, REAPER correctly records exactly what you hear when you are recording. ie. What you play.

With it off, REAPER moves your recordings a small amount early, how much depends on your buffer size and any plugin latency.


If you're monitoring through REAPER, you will record what you hear, if you're not monitoring through REAPER, it wont affect anything.

It's a no-brainer, why would anyone not want REAPER to record what you play? Conversely, why would anyone want REAPER to shift their recordings earlier in time than where they played them, no matter how little or 'un-noticeable' it is?

As EricM stated above, just leave it on and forget about it. The only time you want it off is when using midi input quantize to get things on the grid.

Originally Posted by Jason Brian Merrill

I still don't get it...

I recorded with preserve PDC on today, because I was playing a VSTi, and it seemed to work but then was out of sync with the metronome and seemingly, the grid!!!!

That is strange. If you want to check that nothing is broken, do it again but record a loopback of your master out and if the recording doesn't line up, there could be a bug somewhere.