Full Version:
OpenMPT v1.17.3.02
Has the bug occured in previous versions? If yes, please specify version(s): (This option is optional, and doesn't need research. But in case you know...)
Description of the bug:
It would appear that if patterns are one row, there is a "next pattern" after the last one. See image below.
(http://www.postimage.org/gx1_wmeS.jpg) (http://www.postimage.org/image.php?v=gx1_wmeS)
How often does it happen?:
How to reproduce (step by step description):
Can you please provide an testcase? I don't feel like creating a module with 4000 patterns. (note to self: there should be an option in the code to generate 4000 pattern songs)
Quotethere should be an option in the code to generate 4000 pattern songs
What exactly does that mean? Are you referring to the mass duplication? If you think that 4,000 patterns is bad (even with the mass duplication), then you should get an idea as to how I feel doing songs that are 4+ times longer than that long-hand (without the mass pattern duplication)! Speaking of that, it would appear that the deselection and multiple pattern copy features still do not exist. Perhaps you are still working on those. As for the test case, why would you need one of those? Is the image not clear enough? It seems like it should be, but I could be wrong.
It's not my fault if you create 65000 patterns filled with emptyness, I can't help you with that.
QuoteWhat exactly does that mean?
That we need test facilities in the code so a developer can automagically create a module with f.e. 4000 patterns and samples, to test if anything goes wrong.
Anyway, I still want that module from you.
I have tried it with a format that only allows shorter orderlists and can confirm it now. However, it appears to happen with any pattern size, so I'll rename the thread.
QuoteIt's not my fault if you create 65000 patterns filled with emptyness, I can't help you with that.
65,000 empty patterns would indeed be quite a bit. I suppose since you appear to dislike empty patterns, what you could do (unless you do not have control over it) is code the program such that wave files display the song note by note (as opposed to a single note like it does now). It probably would be hard to help indeed in the form of making the songs, since I would assume that you use the latest version of Modplug Tracker. In that case, some songs would be impossible to do (such as the 64,974 pattern one, as 4,000 × 16 is only 64,000 versus 65,000's 1,040,000 (65,000 × 16). That is why I do not generally use the newer versions of the program to make my arrangements. It would be rather difficult to fit 283,764 (663 × 428) patterns within the 64,000 pattern scope of the newer versions as 283,764 patterns would require 17,736 patterns, with the first 17,735 having 1,024 rows and pattern 17,736 having 256. In addition to that problem, you may or may not know exactly how the combination process is done. It can become rather complex. And wouldn't you know it, the more complex ones generally contain more patterns! :lol:
I do not recall noticing it with 64 or 1,024 row patterns, but if it does it with those as well, then I guess that is part of the bug. As for the module, which one are you referring to? Do you mean a module that does indeed have 65,000 patterns? Perhaps you mean the one that contains 64,974 patterns. If that is the case, you can download it by clicking this link (http://uploading.com/files/e9af1fee/Ulthex%2BQuatzee.mptm/). Perhaps it only happens with larger pattern sizes in those formats. I used the OpenMPT format. Of course, this post may make Jojo never want to post replies to me again, but if he wants to take it that way, I guess that I cannot stop that.
Please confirm that this has been fixed in OpenMPT 1.18 release candidate (http://forum.openmpt.org/index.php?topic=3701.0). You can set the thread status to S=C yourself then.
(And no, I don't want to hear something about the pattern limit this time, kthx)