Recorded MIDI notes are TOO EARLY on the grid

Mudchild · 10-30-2013, 03:52 PM

I solved this goddamn problem once before, ages ago, but I've just tried recording MIDI for the first time since a system reinstall, and the problem is back. All my MIDI notes sound fine when I play them in, but are VERY significantly before the beat when I play them back.

Can someone remind me what this is all about??

Thanks

Mud

EvilDragon · 10-30-2013, 04:17 PM

BEFORE the beat? Well that's strange. Using input quantize would record them ON the beat...

Mudchild · 10-30-2013, 04:19 PM

nah this is not a quantizing issue - it's to do with latency compensation I think. And they are really early, about a whole 1/16th note...

I think I ploughed through this issue about 5 years ago, but I can't remember how it got resolved...

Mudchild · 10-30-2013, 04:21 PM

a 1/32 note rather... nearly anyway

EvilDragon · 10-30-2013, 04:35 PM

What happens if you disable anticipative processing and/or media buffering for that track?

Mudchild · 10-30-2013, 04:39 PM

Do you mean the 'Preserve PDC delayed monitoring' option?

I have it off by default. This didn't matter before the reinstall, but now it does.

If I turn it on, it solves the early note problem, but introduces another problem whereby recording starts slightly late, i.e. the beginning of the new MIDI item is not on the grid line but slightly after it, leading to the first notes played at that point being truncated and late....

does that make sense?

Mudchild · 10-30-2013, 04:40 PM

ah you edited your post so it now looks like I'm answering a question you didn't ask!

hold on...

Mudchild · 10-30-2013, 04:47 PM

nope, what you suggested doesn't solve it...

EvilDragon · 10-30-2013, 04:52 PM

Bugger.

Well, perhaps what makes the most sense here is to have preserve PDC monitoring enabled, then get used to it when recording. You can always slip edit things back...

Also, I'm about to go to sleep, so my brain isn't at it's fullest. Perhaps somebody else gets an idea that will solve the issue for you. Cheers!

Mudchild · 10-30-2013, 04:56 PM

Thanks man. Yeah I would like to avoid having to edit everything though - there's a reason for it somewhere!

Ollie · 10-31-2013, 01:30 AM

Quote:

Originally Posted by Mudchild

I solved this goddamn problem once before, ages ago

How?

Did it involve a loopback test and manually adjusting a device input/output offset in Preferences by chance?

DarkStar · 10-31-2013, 02:07 AM

^^^
Isn't that for audio only?

Just a basic question: Mudchild, when you say "early" where do they appear in the MIDI clip? On the beat, or before it?

Mudchild · 10-31-2013, 05:58 AM

Hi folks

Previously, I did do a loopback test and then enter offset values in the Prefs - and yes that did help, but it meant I had to make sure I always used the same buffer sizes when recording, and also it was still a bit annoying as I thought it just shouldn't be happening in the first place...

Then, from memory, it just stopped being a problem one day - I thought an update fixed it. didn't have to use offset any more.

Now it's back.

When I say 'early', notes are appearing a bit less than a 1/32nd note before where they should be.

I guess I'm going to have to go back to using the offsets. could be worse I suppose. Just weird though.

Tod · 10-31-2013, 08:58 AM

Are you sure you're not just playing on top of the beat?

Heh heh, my playing is all over the place, ahead, behind, and even sometimes right on.

I usually quantize 50% to 60% just to keep a little looseness.

Mudchild · 10-31-2013, 09:45 AM

Quote:

Originally Posted by Tod

Are you sure you're not just playing on top of the beat?

Heh heh, my playing is all over the place, ahead, behind, and even sometimes right on.

I usually quantize 50% to 60% just to keep a little looseness.

Yeah it's not me - I'm no great player or timing perfectionist at all - but the recorded timing is clearly earlier than what I hear when I play (unless I use the 'preserve PDC' setting, which gives faithful timing but introduces other problems as mentioned above.

The other thing I should mention is that the amount of earliness changes depending on my buffer sizes...

Tod · 10-31-2013, 11:02 AM

Quote:

Originally Posted by Mudchild

The other thing I should mention is that the amount of earliness changes depending on my buffer sizes...

Huum, what buffer setting are you using?

256 is about as high as I can go and maintain my sanity.

d. gauss · 10-31-2013, 01:08 PM

you're not alone. i've had that problem and it drives me crazy as some of the guys i record are very very timing/groove sensitive. they don't ever sequence/edit,-- i.e. everything is played "as is" in real time, usually with the whole band, no click/tempo track, and midi is only used to trigger a "better" sound (piano sample or a B3) if the real thing isn't available or practical due to space/time issues. i'm usually at a buffer setting of 128 btw on a 6 core machine.
my workaround has been to record an audio track directly from whatever the controller keyboard is in addition to the midi. i then render the midi/vsti track as audio and slide it back in time until it is sample accurately aligned with the initial audio track from the keyboard. sucks, but it saves me from gettin' yelled at...
if your keyboard is just a dummy controller (no audio of it's own), obviously this won't work.

Tod · 10-31-2013, 01:27 PM

Quote:

Originally Posted by d. gauss

my workaround has been to record an audio track directly from whatever the controller keyboard is in addition to the midi. i then render the midi/vsti track as audio and slide it back in time until it is sample accurately aligned with the initial audio track from the keyboard.

When you're recording these are there more than one instrument at a time? If so, are you able to move them all the same or are there differences?

Also, are they close to the same amount of being off as you do this from time to time?

d. gauss · 10-31-2013, 01:54 PM

Quote:

Originally Posted by Tod

When you're recording these are there more than one instrument at a time? If so, are you able to move them all the same or are there differences?

sure, real drums, real bass, real guitars, real vocals, etc. all our audio tracks and NONE of them ever get moved...it's live off the floor, and the players want it documented as such. see my earlier post for why there is even any midi used at all.

Tod · 10-31-2013, 02:17 PM

Quote:

Originally Posted by d. gauss

sure, real drums, real bass, real guitars, real vocals, etc. all our audio tracks and NONE of them ever get moved...it's live off the floor, and the players want it documented as such. see my earlier post for why there is even any midi used at all.

I'm sorry d. gauss, I wasn't very clear, I meant more than one midi instrument. Yes, I caught the part about the if, when, and why you do use midi.

I'm just curious about the times when you do use midi. You said you record both audio and midi and then line up the midi. My question is, are there more than one midi instrument at a time, which also means, are there more than one midi track at a time?

If so, when you go to line them up are they all the same as far as being off is concerned?

Heh heh, is that any clearer?

milo99 · 10-31-2013, 02:20 PM

I had the same issue, drove me mad.

It was because I was subconsciously playing earlier to compensate for latency. What I was hearing was exactly on the beat, but what I was actually playing was slightly before the beat, hence the MIDI that was recorded was slightly before the beat.

I resolved it by going into preferences - audio - recording, enabling 'use audio driver reported latency' and setting 'output manual offset' to -25ms (you might have to experiment with different values).

Hope that helps!

Milo

Mudchild · 11-01-2013, 02:17 AM

OK just done some more testing. See what you make of this.

This time I opened up a blank project with just a piano VSTi. I did a test (described below) and found that the timing descrepancy is LESS present than in the song I've been working on, but still present nevertheless. This suggests to me it's related to plugin delay compensation and that kind of thing, as there are a lot more plugins present in the song project.

Here's the test I tried. Insert click source on a track. Start live output bounce. Hit record, listen to click for 2 bars, then play single staccato piano notes from MIDI keyboard for 4 bars, as tight as I can to the click. Hit stop. Immediately play back what I've just recorded. Stop. Stop live output bounce. Go and get the bounce recording and drag it into a new reaper track. Cut bounce recording in half, put one half on another track, and manually line up the 2 halves (which are the bounce of the recording phase, and the bounce of the playback phase), using the sections where there is only click playing, to visually line them up accurately. Now play the 2 halves back together. Sure enough, the click sounds like a single sound made louder as the 2 click recordings simply add together, but the piano notes are slightly flammed, like a very short slapback delay. As I said, the delay is a lot less than in the full song project I was working on, where it was seriously compromising timing.

Now, next part of test. Activate 'preserve PDC compensation' for the piano VSTi test. run test again. This time the delay on the piano sound is practically non-existent, apart from a slight phasey sound because the lining up is not sample-accurate. But timing is certainly NOT compromised in any real way.

But I don't like using the PDC compensation option as it compromises loop recording, which I do a lot of.

Thoughts?

brainwreck · 11-01-2013, 03:03 AM

Quote:

Originally Posted by Mudchild

Thoughts?

Yes. Latency and timing issues suck.

DarkStar · 11-01-2013, 04:21 AM

Quote:

Originally Posted by Mudchild

Now, next part of test. Activate 'preserve PDC compensation' for the piano VSTi test. run test again. This time the delay on the piano sound is practically non-existent, apart from a slight phasey sound because the lining up is not sample-accurate. But timing is certainly NOT compromised in any real way.

I would think that this is because the PDC is done at the block / buffer level (e.g. 64, 128 or 256 samples) rather than at the actual delay published by the plug-in(s)