Timing still affected when switching between sequences (v2.0

I found some timing issues in June 2010 and started this thread -> http://www.mpc-forums.com/viewtopic.php?f=25&t=131271.


With the latest JJOS2XLv2.00 I saw:

"
1. [MAIN][NEXT SEQ][SONG]

When a sequence changes, a momentary delay arises. (Bug which existed from Ver1.38)
"

So I was hoping that timing would be ok now.
I just did a test and sloppy timing when changing between sequences ensues unfortunately

I uploaded my test project here:
http://www.filedropper.com/sloppytest

It's a 28MB zip. Inside it has an mpc project folder which you can transfer directly onto your mpc.
At the top level of the zip is a wav file that I recorded of the test. View the README file.


This is just for anyone that is interested to hear what sloppy timing results I get when changing between sequences. Don't expect any bangin tune or anything, lol... It's just a simple 4/4 120bpm thing to test timing. I think slower bpms just don't show up the sloppy timing as much. Either that or it's my mpc which is broken.

p.s. I have an mpc2500.

Hello,

I've just downloaded your zip folder and listened to it.

I started to listen to the example.wav. I had the impression at ear that one seq was playing faster than another.

I've loaded the folder, checked all the parameters and soloed the track 1 (kicks) on both and I could clearly hear the difference between the two.

That led me to do a recording.

http://www.megaupload.com/?d=CFVH462Q

I put the Duration value of all kicks at 3
there's an alternance between seq1 and seq 2 with only the kicks. One rendering with track velocity at 50, another with the track velocity at 100 and the other with the default setting at 200 (resampling at -6db and then normalized for quick comparison purpose)

At the millisecond level in the DAW microscope they are tight to me.

I didn't push the test very far but for me there may be some inconsistencies linked to the velocity or the program parameters (in the case of that kick ADSR on filter + SIMULT)

Anyway I have do my own test for the other thread.

I loaded a project from about 7 months ago, stripped back loads of stuff and got Seq 01, then I just copied Seq 01 to Seq 02 and did nothing else but start the test and save the project into a new folder... so they are exact copies of one another. I did this tonight.

le rat wrote:
I started to listen to the example.wav. I had the impression at ear that one seq was playing faster than another.

What you are hearing are the kicks speed up as soon as the sequence switches. If you then leave that same sequence playing you will notice that the speed stabilizes to the correct speed of 120 bpm after that sequence has looped back on itself. This is the exact flaw which I am trying to expose, namely 'when the sequence switches to a different sequence, there is an inconsistency in the timing of triggered samples'.

I will download your upload now.

Funny, I just noticed that tracks 1,2,3,6 and 7 are all set to outputs 12 in their respective mixer sections. oO dunno why that's happened. Anyway, I just set them all back to ST and the results are exactly the same. Please do this too.

Seq02 is a direct copy of Seq01. I haven't changed or altered anything for it to be different.

I just soloed the kick track of seq01 and seq02 and they are exactly the same when looked at under amplitude and frequency analysis.

Rather than listen to the kick track, it's the hats and snares which are glaring examples of the sloppy timing when you switch the sequences.

jimmie wrote:I loaded a project from about 7 months ago,

try creating a brand new program in os 2. 1 sample. 1 track. just make it all 16th notes of a hi-hat tick. use a small one-hit sample, not some long loop. copy that sequence and switch back and forth between the two. if you want to push the cpu a bit more, use 32nd notes, fill all 3 layers up with the same hi-hat, crank their TUNE up to +32, push the tempo way up. any deviations in switching sequences should be very apparent.

i tried your test program and didn't notice what you were talking about (on a 1000 instead of a 2500). i noticed you had drum one-shots that were kind of long and would continue to play out for a bit after the sequence was stopped. try switching those programs from POLY to MONO and see if that fixes the problem.

I just soloed the kick track of seq01 and seq02 and they are exactly the same when looked at under amplitude and frequency analysis.

In the three rendering I did they don't have the same amplitude when I check the result in a DAW.

If I trust the DAW the timing is good
If I trust my ear that sounds like inconsistency in the timing.

That's why I think there is another problem linked to something else.

If you're not opposed to I'll send it to Murai so that he can pass it to JJ.

Here are the screenshot of my rendering in my computer :







If I listen to it while looking at the waveform in a software, it's easy to guess when there's a change in the sound.

le rat wrote:Here are the screenshot of my rendering in my computer :







If I listen to it while looking at the waveform in a software, it's easy to guess when there's a change in the sound.

The sequences are IDENTICAL, lol. I have double, triple, quadruple checked and don't understand what you are saying at all.

You do know that the mpc isn't sample accurate don't you?

What is so hard to understand here people???

1. Listen to 'sloppytestExample.wav'.

The first part of 'sloppytestExample.wav' is just Sq:01 playing and looping.
The second part of 'sloppytestExample.wav' (after the first pause) is just Sq:02 playing and looping.
The third part of 'sloppytestExample.wav' (after the second pause) is the sound of Sq:01 -> Sq:02 -> Sq:01 -> Sq:02 -> Sq:01 -> Sq:02 -> Sq:01 -> Sq:02 -> Sq:01 -> Sq:02 -> Sq:01 -> Sq:02 (playing and looping).

2. Listen again.
3. If you still can't hear what is black and white straight up timing issues when switching between sequences, then I don't think you belong in this thread.

I spent a lot of time trying to help for that problem.
Don't be agressive.

Peace

Sorry le rat, truly.. It's just when someone tries to tell me 2+2=3 I get a little frustrated. No hard feelings.

Anyway:
I wrote to JJ last night telling him of the bug and with reference to my project file.

He wrote back to me:

"
I'm sorry.
The following bug forgot correction.
Only MPC1000 was corrected.
It is corrected by the following version.

1. [MAIN][NEXT SEQ][SONG]

When a sequence changes, a momentary delay arises. (Bug which existed from Ver1.38)


Since Ver2.01 was uploaded, please download.
The bug of the report was corrected.
Please check.
Thank you.

"

I'm going to download v2.01 to test now.


I did make it clear that I was using an MPC2500. So, maybe le rat and Sooty_G are using an mpc1000?

Again, soz le rat... I know you were trying to help.

I'm using an MPC1000 but anyway I'll send you a PM right now.

Bug fixed by version 2.01 on mpc2500.

Please close thread.

great newz !

things get quickly those times with JJ

supamonsta wrote:great newz !

things get quickly those times with JJ

It is indeed fantastic news. I reported the bug to JJ in June 2010 though, and he said it was a timing deficiency inherent in the mpc. This put me off using my mpc for anything other than midi sequencing duties, but now he's acknowledged and fixed the problem I'm glad to go back to spending many hours on the beautiful beast

JJ does indeed RokK!

He also implemented one of my requests - to be able to output both MTC AND midi clock from different ports at the same time (means I can sequence Cubase AND my TR808, TR606, etc, etc from the mpc)! Version 2 has been a beautiful thing indeed, and thanks JJ if you are reading this!!!!!! People will be scrounging around for an mpc with JJOS2XLv2.01+ for many, many years to come. It's simply MASSIVE.