OS-dependent issues with converting chorus events

[RoadrunnerWMC]

This MIDI produces the following output when converted to mus with the Windows build of seq64 2.3.2:

; Nintendo 64 Music Macro Language (Audioseq) (.mus) sequence: test
; Converted by SEQ64 V2.3.2 [https://github.com/sauraen/seq64]

; Sequence Header

_start:
    mutebhv 32
    mutescale 50
    initchan 0x0002
start:
    startchan 1, start_chn1
    svol 88
    delay 48
    jump start
    disablechan 0x0002
    end
; Section total ticks: 48

; Channel Headers

; tsec0

start_chn1:
    shortoff
    startlayer 0, start_chn1_ly0
    chorus 0, 0
    delay 48
    end
; Section total ticks: 48

; Note Layers

start_chn1_ly0:
    ltp 0
    notedvg 39, 48, 80, 5
    end
; Section total ticks: 48

(Arguments used: --in=test1.mid --out=test1.s --game=zelda --dialect=community-music)

However, the output when converted with the Linux build has the following difference:

@@ -23,7 +23,6 @@
 start_chn1:
     shortoff
     startlayer 0, start_chn1_ly0
-    chorus 0, 0
     delay 48
     end

 ; Section total ticks: 48

Additionally, this similar MIDI causes the Windows build of seq64 to crash, but only when run in Wine — the Linux build processes it fine. I'm not sure if you care about a Wine-specific crash, but I decided to mention it in case it might be at least be a clue when debugging.

---

The reason this was noticed, incidentally, is because the extra chorus events generated by the Windows version seem to break OoT somehow? Some of the music in our mod ends up completely broken when the composer using Windows regenerates the sequences, but it's fine when I build them on Linux — and as far as I can tell, the chorus events are the only difference between them. I can open a separate issue about chorus events breaking OoT if you'd like, especially if the fix for this one results in both Windows and Linux generating chorus events (thereby creating corrupted sequences for the game on both platforms).

[sauraen]

Are you sure the exact same ABI file is being used in both cases? There is no special handling for chorus in seq64's code, it's just one of many CC events which are converted to/from mus commands.

[RoadrunnerWMC]

Yes, it's the builds from the v2.3.2 release zip in both cases, with the same abi folder and command-line arguments. I did say that the issue was originally found due to different people using different OSes, but I confirmed the difference myself afterward.

[RoadrunnerWMC]

Aha — you're actually right, it is using different ABI files in the two cases. I can make them both produce the same output by using '--game=4 - Zelda' (includes chorus events) or --game=4b (no chorus events). So I think the real bug is that the logic for choosing the ABI file seems to vary by OS when the --game argument could match multiple of them.

[sauraen]

I suspect what's going on is that SEQ64 is just querying the list of files in the ABI folder from the OS, and choosing the first one which matches the string. The order of files in a folder is "unspecified", realistically it's the order the files are listed in the inode on disk. So it may not actually be an OS dependent thing at all, simply that you have two different folders with the same contents but the files happen to be in different orders in each one.

There's not really a need to actively use multiple ABI files for the same game--you can just delete the other copies. The distribution of different versions is related to the work which was planned to unify SEQ64 with the decomp sequence tool, which nobody has worked on in a couple years. I'm mainly working on other projects these days so I'm not particularly motivated to add a feature which sorts ABIs by name or something like that.

If you find out why chorus events are leading to corruption, please let me know.