Forum to discuss all matters relating to the MPC1000 and MPC2500 operating systems created by 'JJ' (all versions).
By sleepersriddle Wed Oct 11, 2006 9:56 pm
I'm trying to pin down a possible bug...

have you ever been working on a sequence with LOOP=on, say 2 bars... and it feels like there's a bit of a timing lag everytime it gets to the end of the loop?

By eviscerate Wed Oct 11, 2006 10:38 pm
Insert a tempo change around 1.4.72 just to speed it back

:D

By waldog Wed Oct 11, 2006 11:44 pm
eviscerate wrote:Insert a tempo change around 1.4.72 just to speed it back

:D
How?

By sleepersriddle Thu Oct 12, 2006 12:46 am
ha. not my preferred solution...


anybody else?
User avatar

By Lampdog Thu Oct 12, 2006 1:32 am
Sounds like a problem with YOUr start and end points of the loop rather than a "bug".

Modify/Cut/Start your loops dead on point (01.01.001 with perfect trimming of the front downbeat) and adjust the tempo, or tune of the sample until you get what you want.

Then you can adjust the end decay (via step edit or decay in params) to cut off/stop the sample from bleeding into the loop back to the beginning.

Praaaaaccticccceee.

Of course unless there's a "real" bug preventing you from doing this.

By sleepersriddle Thu Oct 12, 2006 1:55 am
Lampdog wrote:Sounds like a problem with YOUr start and end points of the loop rather than a "bug".

Modify/Cut/Start your loops dead on point (01.01.001 with perfect trimming of the front downbeat) and adjust the tempo, or tune of the sample until you get what you want.

Then you can adjust the end decay (via step edit or decay in params) to cut off/stop the sample from bleeding into the loop back to the beginning.

Praaaaaccticccceee.

Of course unless there's a "real" bug preventing you from doing this.


No, no,,,, i'm not talking about one looped sample.

I'm talking about a regular drum loop made from sequenced single hits. The timing seems a bit off at the end of 2 bars.

you know, the typical way people use an mpc, making a beat that loops!
User avatar

By Lampdog Thu Oct 12, 2006 2:05 am
OOHHH, ok got it. Maybe try and record with different timing settings and play EXACTLY along with the metronome, you know, bob your head while programming your drums so that you keep human type sync with machines timing. That takes practice also.

Are you programming with TIMING=OFF? If so, it's not as easy as most will have you to believe. If someone has problems keeping time then timing off will piss them off more than help them. If you are one of those people then turn the timing ON and try differen settings until you get something you are semi happy with and practice on THAT exact setting until you get a better hang of it.
User avatar

By Antonym Thu Oct 12, 2006 2:18 am
cant say i have had this problem.

By r_v Thu Oct 12, 2006 3:32 am
i have had this problem ever since the first OS versions of the 1000.

it only occurs with some sequences. actually, it would be more accurate to say that it is worse with some sequences.

i initially thought it might be related to the amount of notes in the sequence, like the sequencer isn't 'looking ahead' to the start of the loop properly so it experiences a small delay while it responds to all the notes/data at 1.0.00 when it loops. the more data there is in the sequence, the longer the delay.

however, based on experience, i'm not sure that's the explanation, since i've had it happen on very minimal sequences as well.

it's variable, but it is there. maybe it's workflow dependant and that's why it isn't a problem for some users. but it *is* an issue. glad someone else is seeing it (well, not glad, but, you know...) :)

By sleepersriddle Thu Oct 12, 2006 3:46 am
r_v wrote:i have had this problem ever since the first OS versions of the 1000.

it only occurs with some sequences. actually, it would be more accurate to say that it is worse with some sequences.

i initially thought it might be related to the amount of notes in the sequence, like the sequencer isn't 'looking ahead' to the start of the loop properly so it experiences a small delay while it responds to all the notes/data at 1.0.00 when it loops. the more data there is in the sequence, the longer the delay.

however, based on experience, i'm not sure that's the explanation, since i've had it happen on very minimal sequences as well.

it's variable, but it is there. maybe it's workflow dependant and that's why it isn't a problem for some users. but it *is* an issue. glad someone else is seeing it (well, not glad, but, you know...) :)


great... nice to know at least two of us are crazy. :) (or we're not...)

as you say, it seems to occur for some seq's and not others, now i just need to figure out what the conditions are.

btw, it can happen even with all of my hits quantized 'to the grid',,, so lamp's idea was a good one but not applicable in this case.
User avatar

By Antonym Thu Oct 12, 2006 3:48 am
if you can create something you can reproduce, tell me how so i can try it.

By medway Thu Oct 12, 2006 4:43 pm
With all the timing problems I've had never got this one. Really a sequencer shouldnt even think its "looping" back. It should just be a linear endless pattern.
User avatar

By gunmetal Thu Oct 12, 2006 4:57 pm
??? Never had this problem. i just laydown the drumloop. and listen until i lock it into tempo. if there is any slight delay or what ever i just go back into the sample in the trim mode and tighten up my start and end points. f--- doin the math dog :lol:

By ucacjbs Thu Oct 12, 2006 5:17 pm
It might be worth checking your sequences in step edit mode, and look for any of those mysterious notes that appear at bizarre times (like 0:0:00, or some time outside the loop length). This used to happen sometimes in 2.1 when using the 'move' operation in step-edit, and I think it would cause strange timing behaviour on occasion. Maybe there's some other new feature that's causing a similar bug now.

Just a guess ...