Problem with more than 256 samples

rncekel · May 15, 2013, 16:16:20

When I have several "iti" instruments that make a total of more than 256 samples, OpenMPT seems to mess up the instruments, assigning random (and even inexistent) samples to some notes, with curious numbers like 1024, 3328, 8448 or 59392 (I don't know the meaning of that, but I have noticed that they are all multiples os 256).
I'm using OpenMPT 1.22.02.00.
Thanks

Saga Musix · May 15, 2013, 16:22:58

Can you be a bit more specific, e.g. which format are you using, and does the effect show up instantly or only after saving/reloading the file?

rncekel · May 16, 2013, 07:46:03

It happens with ".mptm" modules, at saving. When I load the instruments it's alright, but after saving and opening again things are quite mess up. Even if I try to edit until everything is OK, save and open again, the same thing happens.
I haven't tried with other formats, like ".it".

Saga Musix · May 16, 2013, 10:20:19

Still no luck, I have created an IT / MPTM file with more than 300 samples and their associations remains as they are. Does it only happen with certain ITIs? Can you maybe post one of them to have a look at?

rncekel · May 16, 2013, 11:03:36

It is not easy to post, because 256 samples make always a huge module, but I have find a way: unzip the garbage.iti instrument attached, create a mptm file and open 6 different instances of this instrument; that would made a total of 385 samples. Then, save the module, and reopen again. I have done it, and the first 3 instances are right, but in the other appear samples that mustn't be there. For examples, note B4 of the first instance is assigned to no sample (as it should), but in the 4th and following, is assigned to sample 61952. Also, note G4, that should be 40+n*64 is correctly 104 in the 2nd, 168 in the 3rd, but 61928 in the 4th, and 296 (correct again) in the 5th.

Saga Musix · May 16, 2013, 11:35:12

Thanks, now I could finally reproduce it. Quite a silly bug that should be easy to fix.

Saga Musix · May 18, 2013, 13:48:52

Fixed in OpenMPT 1.22.03.00.

Really Weird Person · May 19, 2013, 05:13:05

That sounds similar to a strange order bug (which probably is not fixed) where inserting a pattern number that is a multiple of 65,536 higher than any pattern number present in the song (such as 73,727 (8,191 + 65,536)) produces the order number (minus 1 in my case) of the pattern number to which 65,536 was added. Another bug that likely is not fixed: When naming a pattern, the same name is seen on every instance of <i>pattern number</i> + multiple of 4,096 (where <i>pattern number</i> is the number of the pattern that is named). Do note that a numerical sequence (1, 2, 3, ...) is used in both cases (to differentiate them from "unordered" sequences (5, 24, 1, ...)). The first bug is not fixed as of version 1.21.01.26. I do not have the code to test the second bug with. Perhaps someone will test it to see if the bug is still present and it will be fixed.

Saga Musix · May 19, 2013, 11:21:51

Oh, just shut the fuck up, you.

QuoteAnother bug that likely is not fixed

It's not a bug, it's a limitation in the code, I have told you dozens of times before that it's not meant to handle that large quantities of patterns / orders / whatever.

rncekel · May 20, 2013, 07:46:46

Thank you very much. It seems to work out fine. Now, I can go on working with the orchestra!