Yes, this was a deliberate design decision because there isn't really a way for the engine to know right now if a song looped back to the first pattern, first row becuase it "legitimately" reach the end of the song or if there's a loop going back. Rather than having all the songs that are not even supposed to loop have a bogus loop (which I expect to be the majority of songs), I decided that it's easier for the people that need their full song to loop change the exported VGM file instead.

Thinking about it again, we could probably query the SONG_BREAKTOROW flag after the export has finished to figre out if the song ended naturally. I'll look into that.

I've also noticed incorrect sounding playback after exported files loop, like notes not being released or instruments' timbre/volume/pitch changing; is that expected? They're loops exported by OpenMPT, not manually edited ones.

That may be a side effect of OpenMPT only writing a diff of registers (otherwise the exported files would be much bigger). I guess this could be worked around by emitting the complete current register state at the loop start.

r16003 writes the loop data now even if a song loops back to its first position if the break-to-row flag was set.

I will look what I can do about the register state at the loop point, but it might not be quite as simple.

r16004 contains an experimental change that dumps the complete register state on loop. I really don't know if that's better than the previous situation because you just replace one sort of artifact with another, like with the attached song.

In case it's helpful, here's a MPTM file with exported vgms demonstrating some loop anomalies. First subsong shows "Note Off" note commands on the first row seemingly not being processed; second subsong shows timbre corruption of a percussive instrument.

Yes, those would be fixed by r16004, because all channels will be reset to exactly the same state they were in at the first iteration of the loop. This is a compromise - as mentioned, it will cause some artifacts in the module I attached that weren't there previously, but there is no perfect way to handle this because VGM loops don't work like MOD loops where you can have an instrument keep playing across the loop boundary and then start modulating it (e.g. fade it out) after the loop start, unless this fade-out was already there on the first iteration of the loop.

Okay, it doesn't quite fix the first subsong because there simply is no pre-existing register state on channels 2-4... This is more compelex to solve.

I think I have a workaround for the first subsong. One not-so-nice thing about it is that it now increases the size of any looped VGM by 702 bytes for a full register dump.

r16006 now writes the current state of all registers at loop start - to be precise, only those registers that are ever used in the song at all. So if the song only uses one channel, the register dump for the remaining 17 channels is omitted.

r16005 now made non-looped songs loop as well, this was corrected in r16007.

Meant to respond yesterday, sorry. Using r16007 (auto-update is very convenient)...

vgm-loop-sample (initial issue attachment) subsong 1 seems to loop properly, as do 2 and 3 and other song exports I tried, so I think this particular issue is resolved.

vgm-loop-sample2's subsongs also loop okay but sound abnormal at loop start, which is probably expected. Other songs I exported either sound fine or sound unusual for only a very brief time at loop start; I imagine the latter could be worked around with simple pattern modifications.

Thanks for looking into this.

Yes, that's the "you can't have your cake and eat it too" scenario: OpenMPT can either let the user take care of resetting all registers on loop start so that notes lingering from the loop end can keep playing (which is how it was before), or it can make sure that all registers are always in the same state at loop start as they are on the first run of the loop (the new behaviour). This is simply a limitation of how loops work in VGM. Either of the two scenarios can work but not both at the same time. The only remaining alternative would be to only reset the registers of each channel once there is a new note being hit on that channel, but that would make the code considerably more complex for very little gain (and you could still break it in various ways, such as executing a pitch slide at the start of the loop with different notes right before the loop start and right before the loop end - the pitch slide would always use the same pitch as the note before the loop start). I'd rather teach users to make sure that there's no instrument change across the loop point (or at least the instrument change has to be consistent before the loop start and before the loop end).