I recently updated to the latest build, and now MSU-1 files don't seem to be loading correctly on the first try. I'm aware that the filename matching was updated to use the GB ROM file as the base name in https://github.com/devinacker/bsnes-plus/commit/ad4111a170f0fce0f4a35ac6a1aaeeb6f0fc5b34 but even doing that, when I load the files for the first time, it fails to load, and I get no audio. Poking around in the memory viewer at SNES bus address $2000 also indicates the MSU-1 module isn't loaded at all. However, selecting File>Reload succeeds in fixing the issue. So, something in the initial file load is failing to find things, causing the MSU-1 module to not load at all.
Also, as a request, would it be possible to attempt to fall back to the original matching against the SGB BIOS filename if it fails to find one matching the GB ROM name? The new behavior is absolutely 100% a better choice for end users (once it works correctly), however when testing new hacks, it is often much more convenient to have one set of MSU-1 files that can be used for several different GB ROMs, either for A-B testing of code changes, or comparing different GB ROM revisions, etc. This was possible when the file matching was done against the SGB BIOS ROM, but not anymore.
To clarify, the only time it should attempt to fall back is when searching for the .msu file. If it doesn't find gbromname.msu, then it should search for sgbbiosromname.msu. If it finds one or the other, then the .msu file becomes the single base name to be used for all .pcm files. It should not attempt this fallback lookup for individual .pcm files.
I recently updated to the latest build, and now MSU-1 files don't seem to be loading correctly on the first try. I'm aware that the filename matching was updated to use the GB ROM file as the base name in https://github.com/devinacker/bsnes-plus/commit/ad4111a170f0fce0f4a35ac6a1aaeeb6f0fc5b34 but even doing that, when I load the files for the first time, it fails to load, and I get no audio. Poking around in the memory viewer at SNES bus address $2000 also indicates the MSU-1 module isn't loaded at all. However, selecting File>Reload succeeds in fixing the issue. So, something in the initial file load is failing to find things, causing the MSU-1 module to not load at all.
Also, as a request, would it be possible to attempt to fall back to the original matching against the SGB BIOS filename if it fails to find one matching the GB ROM name? The new behavior is absolutely 100% a better choice for end users (once it works correctly), however when testing new hacks, it is often much more convenient to have one set of MSU-1 files that can be used for several different GB ROMs, either for A-B testing of code changes, or comparing different GB ROM revisions, etc. This was possible when the file matching was done against the SGB BIOS ROM, but not anymore.
To clarify, the only time it should attempt to fall back is when searching for the .msu file. If it doesn't find gbromname.msu, then it should search for sgbbiosromname.msu. If it finds one or the other, then the .msu file becomes the single base name to be used for all .pcm files. It should not attempt this fallback lookup for individual .pcm files.