[BUG] Count In with T.C. off will quantize first bar anyway

I came across this just recently. Drum track, Timing Correct OFF, under Click menu: Count in: Rec Only: rate 1/4.

play anything a bit swung after the count in, the first bar will be quantized. If you set the loop to star on another bar, it will still quantize whatever bar starts after the count in, but not the subsequent bars.

I'm looking for confirmation on this one, I don't think I'm missing anything. JJ OS 2XL 2.23 1 November 2012.

Here are 2 audio examples. You hear the count in metronome, then you hear me playing the kick drum, with quantize off, then the bar loops and you hear the pattern play back quantized.

Seems quick to test, would appreciate it.

http://soundcloud.com/elmacaco/116-mpc-count-in-quantize-bug

http://soundcloud.com/elmacaco/232-mpc-count-in-quantize-bug

that's the normal behavior, it happens in every mpc OS AFAIK.

That drum hit you tried to record was before the sequencer even started running.

It doesn't actually play back the sequence during the count-in, so it has no way to tell where in the sequence the early hit was played. So it has to place it as early as possible when it starts, which is the beginning of the first bar of recording.

Subsequent bars, it can do early swung hits like that because the sequencer is already running.


I had this issue a while ago when my sense of rhythm was pretty off, I'd pretty consistently hit pads early. Made for crappy sounding recordings w/o quantizing, because the entire thing was to a constant tempo, but just offset a bit early, so there would only be a noticeable break at the loop point when the first hits didn't land early like all the others.
You just can't record stuff before the count-in is finished.



So it's not a bug, but it is a valid feature request. There's actually another very recent thread requesting this sort of circular-wraparound behavior.

Hey Sciguy,

Thanks for the reply. I thought the error was what you are saying at first, but I tested this by hitting pads during the count in and seeing if they would be added at the first tick. They aren't recorded.

Perhaps there is a buffer between the last (fourth) click of the count in and the first beat of the sequence where any hit in this limbo will be moved to the first tick. I'll have to test it at slower tempos to be sure, but this sounds like the situation you describe and explains why the hits during count in but before the last (fourth) click were not recorded.

I saw the wrap around request, and I can understand and support that request, but I think it should be a toggled function, although I can't see ever shutting it off personally. I've only noticed that when moving events, and it is annoying to have fill in the gaps.

Applying wrap around to this problem, I'm not sure I would want early hits appearing at the last bar, but it would be interesting.
I guess I will have to work on my timing ; ), or just disable count in, since my drum timing is how I like it, and I don't want to struggle against an invisible quarter note limbo that moves any notes to the first beat.

I can always make the first bar a 'count in' bar and have the sequence loop 2-9, this should eliminate the quantize effect of count in, and if I have any early hits I want I can shift them from the first bar.

Solution: turn count in off!

Thanks again Sciguy!

yeah, the feature would definitely have to be disable-able.

One problem I just though of, what should it do when going from one sequence to another? Those early hits, you'd want them, but I would guess it would be not easy to program it to look ahead to the end of the upcoming sequence while playing. Probably would end up just being annoying a lot of the time for some people.



Also, you could just go to the last bar and rec+play from there, it'll loop around and early hits are still fine.

Ooooo! I like that last bar / play start idea! Thanks for shifting my perspective!

I think if it doesn't work when changing sequences then you will have to shift timing so it does, or program the early hits again.

If you had the wrap around, then you could move events blind for all tracks in a sequence and not end up with nasty surprises. I think a fair amount of the move events require some gap filling because of the lack of loop wrap.

It doesn't come up much, so it's not that bad, but I would welcome it.