Full Version:
OpenMPT v1.17.02.52
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...)
not tested, but i guess yes.
Description of the bug:
Download testcase: http://modarchive.org/data/downloads.php?moduleid=66529#zalza-oscar_m_hippa.xm
Listen to this track in a good XM player like XMPlay or MilkyTracker. Pay special attention to the Arpeggio at ~14 seconds (at the end of pattern 2 and other patterns as well) - it sounds very different in OpenMPT!
Well, first I noticed no difference, the arpeggio was there, even with the old MPP.
But then I compared the part at the end, and it seems that one of the three notes in the cluster is different.
So, confirmed.
But to say it's very faulty, is a bit too dramatic imo.
Well, the chord sounds pretty different in all other good XM players, so this is definitly a critical playback bug imo.
Quote<Saga_Musix>well, can you please explain me one thing
<Saga_Musix>http://modarchive.org/data/downloads.php?moduleid=66529#zalza-oscar_m_hippa.xm play this in milky
<Saga_Musix>why do those octave arpeggios (0c0) not play octaves?
<pailes>Saga_Musix, because they exceed the allowed note range
<Saga_Musix>ah, ok
<Saga_Musix>sounds worth fixing in mpt then
<pailes>it is actually not obvious because in theory there is no reason for this "clipping"
<Saga_Musix>so another ft2 quirk, huh
<pailes>I guess so
<Saga_Musix>so what is the note range that's exceeded here?
<pailes>the relative note + actual arpeggio note is not allowed to go beyond 8 octaves
<pailes>that is, 96 notes
<pailes>relative note of instrument 6 is 16, the note being played is D#6, if you add another 0xC you go beyond the limit and the result will still be 96
also appens in http://artscene.textfiles.com/mirrors/GRAPE-DEMO-ARCHIVE/modules/cd/dakota/binary%20world..zip
Fix is on its way. :D