how's your timing for looped seq's?

why not try to program something like:
XxxxXxxxXxxxXxxx
every x or X is a hit of for example a hat in a 1/16 one bar, record it to wav and analyse in the computer to see if there is any kind of delay.

yeah, i was thinking along those lines

next time it happens i'll save memory then render it like that (16th note pattern)


of course this will prob. be just like my car problems, always disappear when you try to show the mechanic...

i noticed this looping delay problem on a sequence i was working on recently, so i started removing events until the problem went away.

i found that the delay was only present when i had an EFFECT event in the sequence. seems there is a small delay when the EFFECT event is sent, even if the effect in question is already loaded.

would be good if someone else could confirm this.

why dont' you post the program and the sequence so everyone could try?

however sometimes dope do that reverb effect eheh lol

r_v wrote:i noticed this looping delay problem on a sequence i was working on recently, so i started removing events until the problem went away.

i found that the delay was only present when i had an EFFECT event in the sequence. seems there is a small delay when the EFFECT event is sent, even if the effect in question is already loaded.

would be good if someone else could confirm this.

wow, are you serious??? that's crazy.

i wonder if we had the "Effect" list removed completely, or maybe just made into 1 eq or something, if we'd have more room for better things.

personally, i never use effects. sometimes a gentle chorus but once in a blue moon really...

it would be interesting to view a cpu priority load test chart that showed timing deviations when anything other than .wav playback events were programmed - start at sixteenths, increase note density, introduce midi notes, controller data, effects, automation etc

my guess is that there WILL be some fluctuation, and that this is related to the mpc500's polyphony-dependent-on-processing 'feature'

so can one of y'all that knows what time of day it is can break out the oscilloscope and Adobe Acrobat and have this PDF on my desk by 9am tmmrw? TIA

hahah earwolf..."thaaaaaaaaaaaanks" (office space)

and that this is related to the mpc500's polyphony-dependent-on-processing 'feature'

now THIS is interesting. it would imply that a cleaner, more well trimmed code would result in better performance/timing, etc etc. check it out - in a translation of an informal email the jj said to me that he was thinking about looking into the way which pads are recognized, so to say.

as of now, the sequencer records only midi numbers. when it records a pad and when you hit play, it converts the pad number to a midi number and then plays it.

it's possible that this will be changed in the future, and that it will recognize the pad directly. ie, you'll be assigning a sample directly to a midi number w/ pad attributes...

this could be the start of housecleaning and the improvement on the already really nice akai sequencer.

as many things as could be ADDED to the os, there are probably twice as many that could be properly refined to equal or greater advantage.

Antonym wrote:hahah earwolf..."thaaaaaaaaaaaanks" (office space)

and that this is related to the mpc500's polyphony-dependent-on-processing 'feature'

now THIS is interesting. it would imply that a cleaner, more well trimmed code would result in better performance/timing, etc etc. check it out - in a translation of an informal email the jj said to me that he was thinking about looking into the way which pads are recognized, so to say.

as of now, the sequencer records only midi numbers. when it records a pad and when you hit play, it converts the pad number to a midi number and then plays it.

it's possible that this will be changed in the future, and that it will recognize the pad directly. ie, you'll be assigning a sample directly to a midi number w/ pad attributes...

this could be the start of housecleaning and the improvement on the already really nice akai sequencer.

as many things as could be ADDED to the os, there are probably twice as many that could be properly refined to equal or greater advantage.

yep good point - who is to say that Akai (or even Roger Linn) are/were the best people to decide how these units should function? We've come a long way since 1986...

what would be great is if JJ was able to fully grasp that for many MPC users, the priority of notes landing 'on the one' is of greater importance than ANYTHING else, and is what the mpc has been famous for for so long. Given that the 1k processor is doing a LOT more than the 60/3k cpu it would be very interesting, as you say, to see if there was a way to reapproach this in 2006 from the very basics of the instruction set - giving the mpc the ability to always 'look ahead' and be able to 100% guarantee an event will hit where it should.

It may be that there could be 2 modes for usage - one that prioritises timing over effects/controller data and one 'normal/old-style' - akin to what you get with the Windows > Apps/Background Services choice.

This would be ideal for those that favour the convenience of the modern MPC's but want to make sure that timing is top of the list every time, as once you've experienced slop (AYOOO) you lose a bit of confidence in your unit (AYOOOO)

i dont' hear this delay you said

please provide a prg and a sequence to understand, if not why i hade to trust you if here all sound good...
no?

i am certain it can be done