MPC file order issue fixed in os2 1.00

here is my issue with the way the mpc1000 names chopped samples. it is very frustrating in this way:

1: load a sample
2: chop the sample into 32 slices
3: export to sliced samples.
4: enter SAMPLE LIST. NOTE: samples are displayed in NUMERICAL ORDER as follows:

sample1
sample2
sample3
...
sample9
sample10
sample11
...
sample18
sample19
sample20
sample21

5: save your samples to a folder.
6: empty your RAM by loading blank project or reboot.
7: LOAD the samples you just saved.
8: enter sample list: NOTE: samples are no longer displayed in numerical order. now, they appear like this:

sample1
sample10
sample11
sample12
...
sample19
sample2
sample20
sample21
...
sample29
sample3
sample31
sample32
...

NOTE: once saved, the samples are no longer listed in order of how they were chopped. they are saved/displayed in alphanumeric order, NOT simple numeric order. in alphanumeric order, 3 comes AFTER 26, not because 3>26 but because the 3 is in the "10s" unit.

this is a serious issue when you're program building from previously sliced samples. since they are not in order you cannot effectively browse them.

i attempted to solve the issue on my end by inserting a "0" in the 10s place (sample1 becomes sample01, etc). this didn't work, the MPC simply ignored the 0 and dropped it back among the others (11, 12, 13 etc)

yeah you're right. Another case when it's annoying : let's say you want to pitchshift or time strech your chops, you'll have to beware of this order coz when you "keep" it the mpc continues to save in the logical order.

for instance chop 1 will be 17 when keeped but 10 might be 18 if you make a mistake

What if you named them Sample A, Sample B......Sample AA, Sample BB, etc...

that's good thinking. unfortunately as you can guess that's a LOT of renaming.
i am constantly slicing samples and getting a full 64 (or 63, actually, due to the "too small" message) slices...

i hope that the solution lies in A, the MPC's (hopefully future) recognition of "0" in the 10s place (ie sample01) and a change in SLICE which inserts this zero. this way there is no time worrying about renaming etc...

another thing I noticed is that if you load up samples with long names (ie, curtis mayfield - track name1, curtis mayfield - track name2) the MPC will only detect the first few characters of the sample name and if all the characters are the same for a number of samples (like the example I used above) for some reason it will assume each sample is the same and trigger the same sample audio for each one (even though they are all different).

not sure if anyone's experienced this or not...

It's frustrating because I like to name sample's when exporting for cataloging purposes and I'd rather not have to change the names each time I want to load them in the MPC.

My workaround has been to name them as such:

curtis mayfield1 - track name
curtis mayfield2 - track name


Not a huge deal, but something to maybe fix in future models.

If I sampled Curtis Mayfield's "We're a Winner", I would name it CM WeWin just so I know what im working with in the MPC

Nym wrote:that's good thinking. unfortunately as you can guess that's a LOT of renaming.
i am constantly slicing samples and getting a full 64 (or 63, actually, due to the "too small" message) slices...

i hope that the solution lies in A, the MPC's (hopefully future) recognition of "0" in the 10s place (ie sample01) and a change in SLICE which inserts this zero. this way there is no time worrying about renaming etc...

just done it for 32 chops. very annoying, is this the kind of thnk we can request JJ to change?

i will mention it and provide a demonstration, maybe a video.
it's a quiet "bug" and hopefully an easy fix, but it sure would be nice

at this point, to me, it's like a huuuge pothole that i hit on the road to work every day. at this point i brace myself in advance and wince but don't curse about it.

aren't the samples in the sample window just in the order of which they were created or loaded? it doesn't re-order them at all, even if you rename a file, which is why the samples seem to be ordered correctly when you auto-chop, but then they're "out of order" when you load them, because it's loading them alphabetically. i bet if you add the 0's, then save the files and reload, they will be in the order you expect.

i think it would be a waste of code to attempt to order samples like sample01, sample2, sample03, sample4, etc. it's intrinsic in programming to order them alphabetically like sample01, sample03, sample2, sample4.

JJ just needs to make sure that when automatically naming things he uses two digits at the end. i.e. sample01, sample02, sample03

that way if you auto-chop or if you load the samples they should stay in the proper order. it would also help if the samples in the sample window were in alphabetical order rather than the order they were created/loaded.

it's actually always bothered me that the default sequence is "sequence01", but when i copy it "sequence2" is created instead of "sequence02".

aren't the samples in the sample window just in the order of which they were created

yes, until they are saved. then they are placed in alphanumeric order. when they are reloaded, they're reloaded in that order.

i bet if you add the 0's, then save the files and reload, they will be in the order you expect.

last line in my first post: i attempted to solve the issue on my end by inserting a "0" in the 10s place (sample1 becomes sample01, etc). this didn't work, the MPC simply ignored the 0 and dropped it back among the others (11, 12, 13 etc)

it's intrinsic in programming to order them alphabetically like sample01, sample03, sample2, sample4.

try it: this is not (yet) the case. the 0 in the sample01, sample02, etc is ignored and loaded as if it was sample1, sample2, etc.

JJ just needs to make sure that when automatically naming things he uses two digits at the end. i.e. sample01, sample02, sample03

that's the first half: put in the zero. then, the mpc has to acknowledge that the zero is there.

i just tried it.

when i save the project and then load it, the sample list is in the same order it was originally, regardless of whether i renamed the files or not. i believe this is because the project file contains a list of the samples which matches the order the mpc had at the time of the save and the mpc goes through that list and loads each sample in that order.

if i save all samples to a folder and then load the folder, it loads the sounds alphabetically (sample01, sample03, sample2, sample4, etc.). this is because the load window orders the files alphabetically and it goes through them one by one in that order.

if i save a program and then load it, it loads the samples in the order they're placed in the program: A01-layer1, A01-layer2, A01-layer3, A01-layer4, A02-layer1, etc. this is because that's the order the samples are saved within the program file and it's loading the program file and then going through the program file loading the sounds one by one.

this is the case with JJos 5.42 for the 2500, it's probably the same with os2. i don't think it's that the zero's are being ignored, it's just that it's displaying the samples in the order that they were loaded or created. the order that they're loaded happens to be dependent upon how you saved them, and also how you're loading them.

but like i said, if he just makes it default to 2 digit numbers when auto-naming and also displays the sample list in alphabetical order, your problems should be solved.

I found a niftty little program could "rename", where you can quickly batch rename long titles in a file, many options in this program to try out.

wavemartian wrote:I found a niftty little program could "rename", where you can quickly batch rename long titles in a file, many options in this program to try out.

ckrename.... freeware

mike thanks for the help, do you think you could explain a couple things a little more? last night i was trying to figure your post out but i'd been drinkin

Mike Feedback wrote:when i save the project and then load it, the sample list is in the same order it was originally, regardless of whether i renamed the files or not. i believe this is because the project file contains a list of the samples which matches the order the mpc had at the time of the save and the mpc goes through that list and loads each sample in that order.

so here, you've loaded the actual PRJ file, not the project FOLDER, correct? and that loads the samples in order of whichever was created, no matter what chaotic, non alphabetical order they were created in? that's interesting, i didn't know that. i invariably just load a folder or single samples. i'll have to remember that.

if i save a program and then load it, it loads the samples in the order they're placed in the program: A01-layer1, A01-layer2, A01-layer3, A01-layer4, A02-layer1, etc. this is because that's the order the samples are saved within the program file and it's loading the program file and then going through the program file loading the sounds one by one.

again, didn't know that...

i don't think it's that the zero's are being ignored, it's just that it's displaying the samples in the order that they were loaded or created. the order that they're loaded happens to be dependent upon how you saved them, and also how you're loading them.

but this still leaves out loading a project folder, how you get this:

sample18
sample19
sample2
sample20
sample21

2 was clearly created before 18 and 19...how frustrating is that?

but like i said, if he just makes it default to 2 digit numbers when auto-naming and also displays the sample list in alphabetical order, your problems should be solved.

yeah, i follow this. i will mention it. what a difficult bug to report--would you call this a bug or just a GUI gnat? i may have to make a video to explain it. i understand what you said now, thanks again for your help here

Nym wrote:i invariably just load a folder or single samples

i've had issues with loading the folder as, i believe, others have. i go into the folder and load the project file, it seems to work every time.