1000 timing sloppyness proven

i don't think any midi sequencer that has one cpu can be truly accurate. i don't know much about programming, but if you look at step edit, there's a list of events, correct? surely if the cpu has to go through those to make the sounds or whatever, then even if there's two events happening at exactly the same time, they cannot be played at the same time, because the cpu first has to read one, then the next. this delay maybe be so small as to be indistiguishable when playing lots of different samples, but if you play the same sample on top of itself, the effect is more pronounced.

just a theory. humiliate at will.

sleepersriddle wrote:2. sending midi.

MIDI is serial, which means that two notes not can be triggered at the exact same time.

that means the internal sounds of the mpc are triggered thru midi from the sequencer. Most software sequencers are "sample accurate" because no midi is involved in the sequencer>sampler communication.

ryssen wrote:

sleepersriddle wrote:2. sending midi.

MIDI is serial, which means that two notes not can be triggered at the exact same time.

Please read my _whole_ post next time before posting comments.

Mr modnaR wrote:i don't think any midi sequencer that has one cpu can be truly accurate. i don't know much about programming, but if you look at step edit, there's a list of events, correct? surely if the cpu has to go through those to make the sounds or whatever, then even if there's two events happening at exactly the same time, they cannot be played at the same time, because the cpu first has to read one, then the next. this delay maybe be so small as to be indistiguishable when playing lots of different samples, but if you play the same sample on top of itself, the effect is more pronounced.

just a theory. humiliate at will.

If it's sending over a single midi cable, it's true what the others are saying, ie no two notes will be sent at the _exact_ same time. with timestamping protocols, you could solve this by introducing a buffer which delays the messages a bit to 'collect up' all the ones that are supposed to sound at the same time.

however, internally, 2 sounds could indeed be triggered exactly at the same time, because the cpu is processing at a much higher speed than the sampling frequency. so ideally there is time for it to calculate a bunch of different sequencer messages, envelope values, and so on, and mix them together, all before it is time to send out the next byte of output.

sleepersriddle wrote:

Mr modnaR wrote:i don't think any midi sequencer that has one cpu can be truly accurate. i don't know much about programming, but if you look at step edit, there's a list of events, correct? surely if the cpu has to go through those to make the sounds or whatever, then even if there's two events happening at exactly the same time, they cannot be played at the same time, because the cpu first has to read one, then the next. this delay maybe be so small as to be indistiguishable when playing lots of different samples, but if you play the same sample on top of itself, the effect is more pronounced.

just a theory. humiliate at will.

If it's sending over a single midi cable, it's true what the others are saying, ie no two notes will be sent at the _exact_ same time. with timestamping protocols, you could solve this by introducing a buffer which delays the messages a bit to 'collect up' all the ones that are supposed to sound at the same time.

however, internally, 2 sounds could indeed be triggered exactly at the same time, because the cpu is processing at a much higher speed than the sampling frequency. so ideally there is time for it to calculate a bunch of different sequencer messages, envelope values, and so on, and mix them together, all before it is time to send out the next byte of output.

humiliation accepted.

BCB2K5 wrote:Thanx for the info Medway, I thought I was the only one who was aware of this.

So you say your S5000 works ok. You think If I send all my songs into a 2k, or 4k they will be ok too?

And is there a way to take midi data the 100 and put it into a 2k or 4k?

Not sure if I totaly understand you here. Do you mean take a song from the 1k and put into an mpc 4k or 2k?

I havent used those too much so not sure about the timing on them.

Mr I3rown wrote:

medway wrote:

Mr I3rown wrote:this sounds seriously weird.

1. r your drums are trimmed?
2. what swing setting are u using?
3. and what timing setting r u using?
4. how many tracks on one sequence at a time r u using?

If you read my other posts you'd realize these questions have no point or I have already answered them

nah to be honest i did not read the posts, i came in to late to read all them pages, but hey what do i care my timing is nice on my MPC, so i dont care.!!

Understood I just didn't feel like rehashing.

Mr modnaR wrote:i don't think any midi sequencer that has one cpu can be truly accurate. i don't know much about programming, but if you look at step edit, there's a list of events, correct? surely if the cpu has to go through those to make the sounds or whatever, then even if there's two events happening at exactly the same time, they cannot be played at the same time, because the cpu first has to read one, then the next. this delay maybe be so small as to be indistiguishable when playing lots of different samples, but if you play the same sample on top of itself, the effect is more pronounced.

just a theory. humiliate at will.

im sure they can optimize the timing by queing up samples or having some kind of multitasking routine to handle the internal sounds. midi going out a cable of course is limited by its serial nature, one note after another (with
about 1ms of time between them). but the 1000 has to have a better way. it should be able to cache notes all on the same time division so they play exactly in time, similar to the linear time base or timestamping function that the midex8 and amt8 midi interfaces from steinberg and emagic produced.

and think of it this way when I send that same sequence data out a midi cable to an external sampler the timing is improved. so its something to do with the 1000's inability to play many internal samples that seems to be the problem, not the sequencer itself.

edit: sorry didnt see sleeprsriddle's post so some of this is redundant now.

cheers for the reply anyhow. i understand now, forgot about the possibility of cacheing.

sleepersriddle wrote:

ryssen wrote:

sleepersriddle wrote:2. sending midi.

MIDI is serial, which means that two notes not can be triggered at the exact same time.

Please read my _whole_ post next time before posting comments.

Well, it seemed that it was more a matter of semantics than accuracy (that you meant MIDI had nothing to do with samples but it could have a similar accuracy).

Ah. well i guess it was just a misunderstanding then.

i just started off saying sample accurate regarding the internal triggering; when it comes to midi i just meant to imply 'as accurate as possible given the nature of midi'.

There's so many posts in this thread, I forget what kind of MIDI interface you're using between your MPC and the Sseries sampler.

Some one else mentioned timestamping on a MIDI interface which would make sense why the external module seems to be tighter. The internal sequencer in the MPC is only 96PPQN, dunno or care what it is on the 2500, point is, nowhere near sample accurate which would definitely account for lots of phasing.

My two cents: timestamping and 96PPQN are the two issues at play. I have no resolution other than knowing they're there and avoiding putting the same sample on two different tracks.

FWIW, I've had the same kind of thing happen with every sequencer I've ever used. I'm not sure how it's unique to the MPC...

Off topic, but still in the thread, the MPC1000 is a much better sequencer for external gear than an Emu Command Station, I've got and love both, but the MPC plays much better with others.

Why are you guys so set on being superior and rude? Seems like the forum is the perfect place to resolve/ bring to light issues like what Medway is having.

there's certainly a lot of horse sh*t being spoken in this thread.... so here's my fiddy cents:

os 1.x didn't have nearly as much of a timing problem as os 2, which means all this talk about processors is crap. i'm pretty sure that when you upgrade to os 2, the processor remains unchanged (...or maybe it morphs into a 386??)

if you want to hear real bad timing.... slave your mpc to something else. i tried to track a stereo mix into cubase (with cubase as master), and the 'swing' turned into more of a drunken stumble... sounded like complete crap. ended up using the mpc's internal clock, which kept time ok. and no, cubase wont midi sync to an external source, so you have to just record it and line it up later.

i think someone mentioned the addition of time stretching and slicing features as a potential cause... well neither of these are active when you are playing back, so i don't see how they are relevant. all they could possibly do is take up a little extra ram (of which i usually have plenty to spare).

on os 1.x i reached the polyphony limit well before timing became an issue, so rhythmic complexity shouldn't affect this either.

thats all from me, just wanted to vent about this issue!! bring on a bug fix akai!!

jfunk wrote:there's certainly a lot of horse sh*t being spoken in this thread.... so here's my fiddy cents:

os 1.x didn't have nearly as much of a timing problem as os 2, which means all this talk about processors is ****. i'm pretty sure that when you upgrade to os 2, the processor remains unchanged (...or maybe it morphs into a 386??)

if you want to hear real bad timing.... slave your mpc to something else. i tried to track a stereo mix into cubase (with cubase as master), and the 'swing' turned into more of a drunken stumble... sounded like complete ****. ended up using the mpc's internal clock, which kept time ok. and no, cubase wont midi sync to an external source, so you have to just record it and line it up later.

i think someone mentioned the addition of time stretching and slicing features as a potential cause... well neither of these are active when you are playing back, so i don't see how they are relevant. all they could possibly do is take up a little extra ram (of which i usually have plenty to spare).

on os 1.x i reached the polyphony limit well before timing became an issue, so rhythmic complexity shouldn't affect this either.

thats all from me, just wanted to vent about this issue!! bring on a bug fix akai!!

i agree about slaving to cubase, but i would blame the pc's operating system and midi interface. if i slave my mpc to something tight (like my machinedrum) the timing sounds fine. (though i haven't thoroughly tested that.)