Offline bounce : Out of Sync\

[midnightrambler]

Ok, so I'm presuming this is a bug?

- New session
- New audio track
- New instrument track
- Add MIDI stuff (I used "Boom" and a 4/4 kick as example)..... http://i58.tinypic.com/2qlahw6.jpg
- Use Aux send to bounce offline.... http://tinypic.com/view.php?pic=2enn...8#.VaTzymA-Bpg

Everything fine so far, bang in sync...... http://tinypic.com/view.php?pic=nfgqh&s=8#.VaTz8GA-Bpg

Now try setting the delay compensation on the audio track to a negative value (I used -1329 samples)... http://tinypic.com/view.php?pic=2055...8#.VaT0EmA-Bpg

and try the same bounce again....... http://tinypic.com/view.php?pic=2h5m...8#.VaT0LmA-Bpg


The MIDI is out by the exact amount on the negative value. Presumably this shouldn't be happening right? Or is it bad practice to use negative play compensation values in this way - and if so, what's the point of having the option to be able to do it?

Thanks

[john1192]

hmm .. negative values thats interesting .. may i ask why you would enter neg values ??

[Carl Kolchak]

Originally Posted by midnightrambler

Ok, so I'm presuming this is a bug?

- New session
- New audio track
- New instrument track
- Add MIDI stuff (I used "Boom" and a 4/4 kick as example)..... http://i58.tinypic.com/2qlahw6.jpg
- Use Aux send to bounce offline.... http://tinypic.com/view.php?pic=2enn...8#.VaTzymA-Bpg

Everything fine so far, bang in sync...... http://tinypic.com/view.php?pic=nfgqh&s=8#.VaTz8GA-Bpg

Now try setting the delay compensation on the audio track to a negative value (I used -1329 samples)... http://tinypic.com/view.php?pic=2055...8#.VaT0EmA-Bpg

and try the same bounce again....... http://tinypic.com/view.php?pic=2h5m...8#.VaT0LmA-Bpg


The MIDI is out by the exact amount on the negative value. Presumably this shouldn't be happening right? Or is it bad practice to use negative play compensation values in this way - and if so, what's the point of having the option to be able to do it?

Thanks

Maybe I'm failing to get my head around what it is you're trying to test, and what result you're expecting to see.

Presumably the second test you ran, is exactly the same as the first i.e. you are bouncing the MIDI to an audio file?

Or are you bouncing the first audio file, to another audio file?

If it's the former, I wouldn't expect delay compensation to place media earlier in the timeline, before the media has been recorded to the timeline (even if it were to do it immediately after the recording pass was finished).

Instead, I would offset the MIDI earlier (either globally, or locally).


If it's the later, there are two ways of looking at it :

1. It could be a bug.

2. As the offset is identical to the one you set manually, it appears that Pro Tools has put a "Handle" on the bounced file, probably because you have a negative delay compensation set, and it expects you to keep that turned on, which would result in the audio playing back in the correct place (identical to the first test to the listener) - or has been forced to shunt the file along the timeline, due to the insert point being at the start of the session.



Were you expecting the second test to have an identical result to the first?

Or were you expecting the second test to have the front of the initial kick drum chopped off, with the following kick drums occurring early in the timeline, by the compensation offset you had applied?


Presumably your import option is set to "Selection", rather than "Session Start"?




Have you tried the same experiment, but starting at Bar 2, rather than Bar 1?

Have you tried changing the compensation to a positive value, and trying the test again?

Have you tried a null test between the MIDI track, and the 2nd test (with the delay compensation still enabled)?

Were the results as expected?

[midnightrambler]

Originally Posted by john1192

hmm .. negative values thats interesting .. may i ask why you would enter neg values ??

I had "late" room mics on a drum kit that I pushed ahead and it worked a treat....I did use Waves InPhase to do this originally but thought the negative compensation was quite neat to use instead....until I came to print the MIDI anyway :)

[midnightrambler]

Originally Posted by Carl Kolchak

Maybe I'm failing to get my head around what it is you're trying to test, and what result you're expecting to see.

I'm expecting to see MIDI printed at its correct place, regardless of what is occurring elsewhere, especially delay compensation values.

Originally Posted by Carl Kolchak

Presumably the second test you ran, is exactly the same as the first i.e. you are bouncing the MIDI to an audio file?

yes

Originally Posted by Carl Kolchak

Or are you bouncing the first audio file, to another audio file?

No, I'm testing MIDI bouncing with delay compensation values.

Originally Posted by Carl Kolchak

If it's the former, I wouldn't expect delay compensation to place media earlier in the timeline, before the media has been recorded to the timeline (even if it were to do it immediately after the recording pass was finished).

No, but you shouldn't expect it AFTER, i.e. late, that's my point.

Originally Posted by Carl Kolchak

Instead, I would offset the MIDI earlier (either globally, or locally).

Why? I want bar 1 to be bar 1 to be bar 1, no exceptions. I don't want to have to offset all my MIDI parts because of a negative compensation value. That will just get really messy.

Originally Posted by Carl Kolchak

Were you expecting the second test to have an identical result to the first?

Yes.

Originally Posted by Carl Kolchak

Or were you expecting the second test to have the front of the initial kick drum chopped off, with the following kick drums occurring early in the timeline, by the compensation offset you had applied?

No, I want bar 1 to be bar 1, and everything to line up accordingly.

Originally Posted by Carl Kolchak

Presumably your import option is set to "Selection", rather than "Session Start"?

Absolutely. Though irrelevant to the test.

Originally Posted by Carl Kolchak

Have you tried the same experiment, but starting at Bar 2, rather than Bar 1?

Yes. Same result.

Originally Posted by Carl Kolchak

Have you tried changing the compensation to a positive value, and trying the test again?

Yes. Positive values are fine. So by that reckoning, negative values should also be compensated for.

Originally Posted by Carl Kolchak

Have you tried a null test between the MIDI track, and the 2nd test (with the delay compensation still enabled)?

I'm not sure you need to do a null test when you can visibly see the results. But yes, they sound as expected, i.e. the first one cancels, the second one doesn't.


Thanks for your help.

[Carl Kolchak]

Originally Posted by midnightrambler

I'm expecting to see MIDI printed at its correct place, regardless of what is occurring elsewhere, especially delay compensation values.

As your first test shows, it is.

I don't think it's really designed to compensate for something that hasn't happened yet, which is why I would either set the delay compensation after the material is on the track / nudge it back in to place by the delay amount, or offset the MIDI prior to the bounce...

UNLESS...

Perhaps I am still misunderstanding what you are trying to do :

It looks like you are trying to print MIDI to an audio track that has an amount of delay compensation pre-applied to it (which seems like a weird way to work).

Now I'm starting to think that you are simply saying the presence of any delay compensation, on any track in the session, causes MIDI to get printed out of sync - is that correct?

Originally Posted by midnightrambler

No, but you shouldn't expect it AFTER, i.e. late, that's my point.

Under normal circumstances, no. But if, due to the negative delay comp value, it is adding padding, on the assumption that you would keep the same delay compensation active, it makes sense.

Originally Posted by midnightrambler

Why? I want bar 1 to be bar 1 to be bar 1, no exceptions. I don't want to have to offset all my MIDI parts because of a negative compensation value. That will just get really messy.

It still would be bar 1, if you think in terms of Real-Time Properties (That said, the very first thing I do in a music session is to renumber bar 1 as bar 3, so that there are a couple of bars lead-in).

Originally Posted by midnightrambler

Absolutely. Though irrelevant to the test.

It's relevant if this double / negative delay comp thing adds padding by the delay comp amount, because if the newly imported bounce is sent to the session start, it couldn't possibly be in sync, without chopping off the beginning of the material.

Originally Posted by midnightrambler

Yes. Positive values are fine. So by that reckoning, negative values should also be compensated for.

So a positive value of 1329 results in the bounced material ending up in the exact same place as it is in your 2nd test?

Originally Posted by midnightrambler

I'm not sure you need to do a null test when you can visibly see the results. But yes, they sound as expected, i.e. the first one cancels, the second one doesn't.

Reason being, that yes, you can see it is out of sync, but if you still have delay compensation set to -1329, it ought to be back in synch as you hear it played back (not as you see it).



And as the title of this thread suggests, are you seeing a different result with Real Time Bounce?

[john1192]

you could also use the old Time Adjuster PLugin .. i think it is still available in PT .. using Delay Comp is interesting but if you had to turn it off while working yur mix might go to hell ...

[midnightrambler]

Originally Posted by Carl Kolchak

It looks like you are trying to print MIDI to an audio track that has an amount of delay compensation pre-applied to it (which seems like a weird way to work).

No, the audio track is just a dummy track to demonstrate the MIDI is not printing correctly when the value is negative. When the new audio is imported it is automatically assigned to a new track, which defaults to a delay compensation value of 0.

Originally Posted by Carl Kolchak

Now I'm starting to think that you are simply saying the presence of any delay compensation, on any track in the session, causes MIDI to get printed out of sync - is that correct?

If the delay compensation is a negative value, then yes.

Originally Posted by Carl Kolchak

So a positive value of 1329 results in the bounced material ending up in the exact same place as it is in your 2nd test?

Positive values results in MIDI being correct and in sync, i.e. a MIDI note at 2|1 is also at 2|1 on the bounced audio file, regardless of the positive value offset of the (dummy) audio track.

Originally Posted by Carl Kolchak

And as the title of this thread suggests, are you seeing a different result with Real Time Bounce?

Both realtime bouncing and printing onto a new track (i.e. route bus 101 to a new track instead of offline bouncing) operate correctly and as expected regardless of negative offset, i.e. MIDI note at exactly bar 2|1 results in audio at 2|1.


To clarify : this problem only occurs when a negative value is entered in the delay compensation box manually on any audio track and when bouncing offline. When a positive value is entered manually everything appears to work and be in sync as expected offline; when a negative value is entered manually everything works as expected provided you print in real time, it will not work offline.

[midnightrambler]

Originally Posted by john1192

you could also use the old Time Adjuster PLugin .. i think it is still available in PT .. using Delay Comp is interesting but if you had to turn it off while working yur mix might go to hell ...

Yes I'm starting to realise this was a can of worms I didn't need really. Ultimately I could have just moved the audio manually! So much for me being a clever dîck eh

But when options like these exist, you'd hope they worked as expected....otherwise they shouldn't give you the option to enter negative values...

[midnightrambler]

In fact, I'm just going to go through the sessions and move the room mics manually, like I should have done in the first place, and never try and override the delay compensation system again. You live and learn....