midi tracks and latency

[SNAPPER]

I just started messin' around with midi tracks and soft synths with 2 computers and I'm still working out some latency problems.

is there a way to select a whole midi track and drag the performance back a few milseconds to fix a perceived latency like you can do with an audio track?

[pk_hat]

Just treat it as you would an audio file. Highlihght the midi notes you want to move with the grabber tool and nudge it back using your +/- on the numeric keypad. Select 'samples' or 'milliseconds', experiment to see which is more accurate.

pk

[QuikDraw]

I'm not at my PTLE rig at the moment, so I don't know that exact name or location of what you're looking for. But it's something like this:

Go to the PTLE 'Windows' menu and choose the option for something like 'Show MIDI track offset'.

It's something like that. It will let you set an offset for each individual MIDI track.

There's also a 'Global MIDI Offset' option in the Setups > Preferences > MIDI menu.

Here's how the two different types of MIDI offsets are supposed to work...

You use the 'Global MIDI Offset' to take care of audio latency caused by PTLE's 'Hardware Buffer' setting when you route the audio of your MIDI hardware into PTLE. If you have your Hardware Buffer set for 128 samples you would set your Global MIDI Offset to -128. That takes care of the 128 sample delay that the audio suffers when it enters PTLE. If your Hardware Buffer is set to 1024 you would set the Global Offset to -1024. That tells PTLE to play all your MIDI tracks early (if you use a negative value) by the amount of samples set in the Global MIDI Offset.

Now, if some of your MIDI devices suffer additional latency, such as the built-in latency common to all softsynths, you use the individual MIDI Track Offsets to correct for each track's additional latency.

For example, I have my Hardware Buffer in PTLE set to 256 samples. I have my Global MIDI offset set to -256 to take care of monitoring latency. I have Reason running in the background. The lowest latency setting I am able to use in Reason is 47ms. So on my Reason tracks in PTLE I set the MIDI Track Offset to -47ms. So all my MIDI tracks are playing back early by the -256 sample 'Global MIDI Offset'. And since Reason doesn't output any sound until 47ms after it receives the MIDI signal, the Reason tracks in PTLE are playing back an additional 47ms earlier than the other MIDI tracks. They are all in perfect sync.

I hope this helps.

Mike

[Roy Howell]

Mike(Quikdraw),
This is gonna be like Luke questioning Yoda's advice here (because you are definitely one of my best teachers and friends, there is no doubt).
But, unless the Midi Offset feature has changed in XP, and is set, as you say simply by the buffer setting used (-128, for example), that's not how it has worked for me.
I will absolutely admit to being wrong if XP is different that the prior OS's.(and I hope it IS that easy now).

But, here's why I say this. I do a lot of Midi and Audio tracks together. I record both with 'Low Latency Monitoring' on. But when it's time to bounce to disc, 'Low Latency Monitoring', of course, has to be off to bounce Midi and Audio tracks together.
OK, so as you mentioned, the Global Midi Offset is found under Setup/Preferences/Midi. Once there though, depending on how much Audio has been recorded, I have found that the range that synchs Midi with Audio usually ranges between -800 and -2600. If I were ever to use something as small as -128, there would still be a large latency gap.

So Mike, I know you won't take offense to my pointing this out, because you're a true friend. But, has the Global Midi Offset been simplified in XP, and I just don't know it? If so, I will be glad to admit I'm wrong(and delete this). I'm not here to point out when somebody's mistaken, but it may save someone some trouble, that's all. [img]images/icons/smile.gif[/img]

Thanks, Roy

[QuikDraw]

Roy,

No offense taken. The best I can offer to explain your experience is, "Your Mileage May Vary". My statement above is correct in theory. Everything I've tried on my system (Win98SE, WinME, and WinXP) have all held true to this theory. I don't use all that many MIDI tracks, so things may start deviate from theoretical norms at some threshold of system load that I have not ever reached.

In theory, if you follow the suggestions in my previous post things should sync up perfectly. In reality things may not be that simple!

[img]images/icons/wink.gif[/img]

Mike

[JPS]

Originally posted by Roy Howell:
Mike(Quikdraw) I have found that the range that synchs Midi with Audio usually ranges between -800 and -2600. If I were ever to use something as small as -128, there would still be a large latency gap.

<font size="2" face="Verdana, Arial">Roy, I think you and Quick Draw are talking about similar amounts of midi latency. Since 1 ms is equal to about 44 samples, Quick Draw's 47 ms of latency in Reason turns out to be 1628 samples. Then he has to add the 256 samples latency from the buffer and he has 1884 samples of latency, which falls pretty much in the middle of your 800-2600 rule. So, if Quick Draw was to use your Global method of setting latency, he would have to use 1884 as his setting, except that it would affect all of his midi tracks.

[Roy Howell]

JPS,
All I said was that if your buffer size in PTLE is set to 128, your actual setting in PTLE Global Midi Offset will not be -128. It will be much less, usually between -800 and -2600 (likely) in the Global Midi Offset box, under Setups/Pref/Midi.

If a PT user were to go into that Midi box and set it to -128, he would wonder why there is a big latency gap between his Midi and his Audio tracks.
I'm just trying to make it simpler for those who aren't familiar with Global Midi Offset. The size is gonna vary, and not simply be proportional with Hardware Buffer size settings.

~rh

[Roy Howell]

What can I say, but you're a good man, Mike. Thanks for all the incredible help you've given me and so many others... [img]images/icons/smile.gif[/img]

[QuikDraw]

There seems to be a misunderstanding of different types of latency, where they occur, and how to properly compensate for them (when possible).

The Hardware Buffer setting in PTLE causes any audio that enters through physical audio inputs on the Digi 001 to be delayed by the number of samples set in the Hardware Buffer before reaching the physical audio outputs of the Digi 001. This is not variable. A 128 sample buffer causes a 128 sample delay. A 1024 sample buffer causes a 1024 sample delay. It is not dependent on the number of audio tracks or MIDI tracks in either playback or record mode. The only exception to this is using 'Low Latency Monitoring' mode, which gives almost no audio monitoring latency and is not affected by the Hardware Buffer setting.

Since MIDI tracks are sequenced, meaning they are not being performed live, but already happened, PTLE gives us a way to play all MIDI sequenced tracks early by the amount of samples needed to correct for audio monitoring latency caused by the Hardware Buffer. That is what the 'Global MIDI Offset' is for. That is all that the 'Global MIDI Offset' is for. It is not for correcting anything other than audio monitoring latency. The Global Offset is not for correcting any other type of latency. If you have a Hardware Buffer of 128 samples, the correct value for 'Global MIDI Offset' is -128. Period!

But MIDI data is subject to other types of latency than just audio monitoring latency that is caused by hardware buffering in PTLE. Each MIDI device has a latency of its own. That's what 'MIDI Track Offset' is for.

All audio coming into the Digi 001 will be delayed by exactly the number of samples set by the Hardware Buffer setting. If each MIDI module produced a sound exactly when it received its note on message via MIDI then all we would need to do is set the Global Offset and all would be fine. But that's not the case. Each MIDI module takes time to receive the note on signal, figure out what to do with it, and output an audio signal. This latency has nothing to do with the Hardware Buffer in PTLE. The Global Offset in PTLE should not be used to attempt to correct for this type of latency. This type of latency is why PTLE gives us 'MIDI Track Offset'. You correct for MIDI module latency with 'MIDI Track Offset'.

PTLE pre-plays all MIDI tracks by the amount set in a negative value in the Global Offset. That takes care of monitoring latency. You need to determine how much latency each MIDI module has on its own and set a 'MIDI Track Offset' for each track in PTLE that uses that module to correct for that module's own built-in latency. PTLE then pre-plays each MIDI track by the negative value you have set in each track's 'MIDI Track Offset' in addition to the Global Offset. This is what brings each MIDI module into proper sync.

If used correctly the 'Global MIDI Offset' corrects the monitoring latency only, and the 'MIDI Track Offset' corrects for any MIDI module latency not caused by PTLE's audio monitoring latency.

There is a problem though... PTLE is programmed such that the built-in 'Click' is not affected by the Global Offset. So the only way to have the MIDI generated 'Click' play in proper sync is to use 'Low Latency Monitoring', or to monitor the 'Click' outside of PTLE. If you're listening to the 'Click' through the Digi you will always hear your click late by the amount of samples in the hardware buffer unless you are 'Low Latency Monitoring'. And there is no 'MIDI Track Offset' for the 'Click', so PTLE gives us no option to correct for either MIDI module latency or monitoring latency for the built-in 'Click' function.

So if you have a session where you played to the built-in click in PTLE and weren't using 'low latency monitoring', all your playing will be "late" by the amount of the hardware buffer + any MIDI module latency in the sound module you have generating the click. If you change your Hardware Buffer setting at some point in your recording process then you'll change the delay of the 'click'. Then you start recording additional tracks using different MIDI modules and maybe different Hardware Buffers and none of your tracks will have been referenced to the same time. That is why it will seem that the Global Offset changes. It's not really that the offset changes at all, but you played to a different reference time. Nothing's really properly synced!

Please, I don't want anyone to take what I'm saying personally! For one thing, Digidesign programmed the 'Click' function wrong. There's nothing any of us can do about that except to only use the click with 'low latency monitoring' turned on, or monitor the click externally. (Actually, I never use the 'Click'. I program a click track on a MIDI track which can be compensated properly with both types of MIDI offset.) Also, there's no good explanation in Digi's documentation as to how the different MIDI offsets are supposed to be used, so if you didn't understand it previoulsy, it's not your fault!

Then there's the problem of random MIDI latency. A different subject altogether dealing with how the host computer's OS deals with MIDI signals and how each program deals with them. And there's no MIDI offset anywhere that can compensate for that!

Mike

[Okion]

Thanks all for that lesson in midi latency.

I have a few questions though.

1) What are you using to synch Reason and PTLE in XP?

2) Are you going out from an audio card and into PTLE via the 001 to get the audio from Reason?

3) I have been writting/recording/tweeking midi tracs till they are satisfactory, then recording them to Audio, so that at the end of the project on a particular song, all my tracs are audio. I often add effects at this point. It seemed from Roy's post that there is another way to do that. How does that work?