Sample Rounding Issue!!!!

[innesireinar]

Originally Posted by Rich Breen

Sample rounding will *always* occur if the track is set to *samples* and the samples to tick ratio is not a whole number - IOW, you really need to be working with tick-based tracks or you will more-than-likely (though not necessarily) have sample rounding issues. If you create a clip on a track in "samples" mode that is 1/4 note long, it is unlikely to actually be exactly 1/4 note in ticks (because you're using a sample time base) - the "samples" time base though is very important to any of us working on non-tempo-grid based material (non-grid based music, time code based material, etc).

If you are in "ticks" mode, and your clips are created to be for example exactly 1/4 note then they will act correctly and you shouldn't have a problem. Pro Tools allows users the flexibility to have multiple timebases working in a single session and to move tracks freely between sample and tick timebase - I suspect that the people having problems with this have either created or edited clips on a track in "samples" mode and then changed it to "ticks" mode and expect everything to work just fine - it usually will not. I'd be very curious to see an example of sample rounding error on a tick based track with material that's been created or conformed to the tick grid - not saying it's not possible that there's a bug, but I'd want to see it.

Yes, definitively occurs on tracks in tick as well. However we are focused on midi clips, and these kind of data has nothing to do with tempo/SR calculation

[foxes]

Originally Posted by innesireinar

Yes, definitively occurs on tracks in tick as well. However we are focused on midi clips, and these kind of data has nothing to do with tempo/SR calculation

Absolutely.

The link shows pictures of the midi clip 'sample rounding' issues that PT has and I am suffering with. As I have said all tracks are set to ticks from creation of the project.

https://imgur.com/a/r3qXZC6

[foxes]

Originally Posted by musicman691

One remedy to get hi-res pictures on here is to host them on a site and then put the link in a post here.

As you have suggested here are images of said bug.

https://imgur.com/a/r3qXZC6

[Rich Breen]

Originally Posted by midnightrambler

...
1. New session
2. New MIDI track
3. Create 4 bar clip
4. Now zoom right in and pull the clip in (or out) ever so slightly. The edit section length will still register as *exactly* 4 bars
5. Now go to duplicate the 4 bars and watch the clips eventually drift off the grid.

Obviously to a certain extent this is expected behaviour; the problem is that "edit section length" isn't accurate enough to be able to see if you have *exactly* 4 bars or some tiny fragment more or less. This "rounding error" may be exacerbated with certain combinations of tempos and sample rate of course.

This isn't a bug! This is as you say expected behavior. You're editing the clip in SLIP mode AT THE SAMPLE LEVEL - this has far more resolution than at the tick level so the transport bar isn't going to indicate anything different in bars/beats since it can't show anything smaller than ticks (1 tick looks the same in the transport bar numerical indicators as 1tick+1sample. Same thing happens if you're displaying timecode or mm:ss:msec. This is normal - you'd have to display in samples if you want to see the difference.

Again, if you want to avoid sample rounding you need to be in ticks and editing to the bar/beat grid. If you trim off or create a clip to any greater resolution than a tick you'll get sample rounding.

For this to be a bug, you'd need to show a case where a clip is edited *exactly* to bar/beat grid resolution and still drifting off grid on repeat pastes. Again, not saying it can't be a bug, but I haven't seen it yet.

best,
rich

[foxes]

Originally Posted by Rich Breen

This isn't a bug! This is as you say expected behavior. You're editing the clip in SLIP mode AT THE SAMPLE LEVEL - this has far more resolution than at the tick level so the transport bar isn't going to indicate anything different in bars/beats since it can't show anything smaller than ticks (1 tick looks the same in the transport bar numerical indicators as 1tick+1sample. Same thing happens if you're displaying timecode or mm:ss:msec. This is normal - you'd have to display in samples if you want to see the difference.

Again, if you want to avoid sample rounding you need to be in ticks and editing to the bar/beat grid. If you trim off or create a clip to any greater resolution than a tick you'll get sample rounding.

For this to be a bug, you'd need to show a case where a clip is edited *exactly* to bar/beat grid resolution and still drifting off grid on repeat pastes. Again, not saying it can't be a bug, but I haven't seen it yet.

best,
rich

I am NOT editing in slip mode, it is in grid mode with ticks set from the creation on the project.
All originally recorded midi clips are perfect bar lengths whether that be 2, 4 or 8 bars. When they are duplicated or repeated or alt + manual dragged they will randomly not line up as per my images (link) in my previous post.

Myself & I'm sure others on this thread are very experienced in midi composing/editing in PT & across other DAWs, myself since the early 90's using the Atari with Notator & Cubase right through different varieties of Macs to this very day.

I can tell you this bug DOES happen and it is only my experience that gets me through a production, albeit at times (& at certain tempos) with extreme frustration and time consumed.

[stevegalante]

Originally Posted by foxes

I am NOT editing in slip mode, it is in grid mode with ticks set from the creation on the project.
All originally recorded midi clips are perfect bar lengths whether that be 2, 4 or 8 bars. When they are duplicated or repeated or alt + manual dragged they will randomly not line up as per my images (link) in my previous post.

Myself & I'm sure others on this thread are very experienced in midi composing/editing in PT & across other DAWs, myself since the early 90's using the Atari with Notator & Cubase right through different varieties of Macs to this very day.

I can tell you this bug DOES happen and it is only my experience that gets me through a production, albeit at times (& at certain tempos) with extreme frustration and time consumed.

It's funny but I never used the midi clips, always in notes view, never had this problem (but I've had others don't worry). Much more precise in my opinion, you have a much better idea of what you are actually doing. That being said it would be nice is this was recognized as a bug and solved. Don't forget PT is now a 2Gb+ app, not easy to debug...

[midnightrambler]

Originally Posted by foxes

I can tell you this bug DOES happen and it is only my experience that gets me through a production, albeit at times (& at certain tempos) with extreme frustration and time consumed.

We need a definite, reproducible error to convince the naysayers. Any ideas? Any particular tempos or methods of working that will definitely produce this result?

Like I say I've seen it myself but have never backtracked to find out what went wrong.

[foxes]

Originally Posted by stevegalante

It's funny but I never used the midi clips, always in notes view, never had this problem (but I've had others don't worry). Much more precise in my opinion, you have a much better idea of what you are actually doing. That being said it would be nice is this was recognized as a bug and solved. Don't forget PT is now a 2Gb+ app, not easy to debug...

I appreciate that but for making on-the-fly arrangements & changes to arrangements particularly with large pop, r&b, soul or edm projects, clips are way more efficient & workflow friendly for me.

All other DAWs do not suffer from this, why is PT the only one that cannot get this right?

PT maybe 2Gb+ but that is no excuse to have such a basic but so crucial operational bug still present.

If you look at 'similar threads' below this one you'll see PT has had this issue for years.......yet no other DAW has.

[foxes]

Originally Posted by midnightrambler

We need a definite, reproducible error to convince the naysayers. Any ideas? Any particular tempos or methods of working that will definitely produce this result?

Like I say I've seen it myself but have never backtracked to find out what went wrong.

Naysayers or not, this is a random bug, meaning it only seems to happen at certain tempos (which you are aware).

I do not have the time to do tests at different tempos & such to definitely reproduce this bug. Music what I do for a living & I have clients & deadlines to adhere to.

TRUST ME WHEN I SAY TO YOU THIS IS A BUG.
It's not my job to prove anything to naysayers, Avid by their own admission are aware that PT was this sample rounding bug http://avid.force.com/pkb/articles/e...ow_To/en430955
(and yes it does affect midi clips which I know has nothing to do with SR - the bug seems to affect accurate copying, duplicating or repeating clips).

[stevegalante]

Originally Posted by foxes

I appreciate that but for making on-the-fly arrangements & changes to arrangements particularly with large pop, r&b, soul or edm projects, clips are way more efficient & workflow friendly for me.

All other DAWs do not suffer from this, why is PT the only one that cannot get this right?

PT maybe 2Gb+ but that is no excuse to have such a basic but so crucial operational bug still present.

If you look at 'similar threads' below this one you'll see PT has had this issue for years.......yet no other DAW has.

Agree with you but, in the end, it's been here for years and it will probably keep us company for more years. For those who suffer from this you just have to find a workaround and deal with that. For me, notes view give me a much better control and it's bug free. I'm sure there are a lot of other "workarounds" we use every minute without even realizing, so really no big deal. That being said I hope it will be corrected in the next decades 😁