I think the thing that’s tripping you up is that the loop handler is called when the current loop has finished playing, to ask what to play next, and also whenever you switch cards, to ask whether the loop should continue on the new card. The intended model is that, for example, when you’re on the card that represents a lazy afternoon picnic you can play the “open field ambience” loop, and when the player clicks through to the card where zombies attack, you can switch immediately to the “thumping battle theme” loop rather than waiting ten seconds for the existing loop to end.
I think what’s happening in your example is that Decker is playing, say, sound 11, then the player goes to the next card, the loop handler gets called and advances to sound 12, even though sound 11 hasn’t finished.
The way I would work around this is by saving the expected finish time for the current loop, in a widget alongside the loop counter:
newsound:deck.sounds["sound%i" format m[i]]
deck.cards.Home.widgets.loopend.data:sys.ms+newsound.duration*1000
(sound.duration is in seconds, so we multiply by 1000 to convert to milliseconds)
Then, when the loop handler gets called:
on loop oldsound do
if sys.ms > deck.cards.Home.widgets.loopend.data - 200
# We're at or past the end of the current loop,
# pick the next sound
<existing code as in your example>
else
# We're only part-way through the loop,
# the player must have switched cards,
# keep playing the old sound.
oldsound
end
end
Note that we compare sys.ms (the current time, in milliseconds) to loopend - 200 rather than comparing directly to loopend. To make looping seamless, Decker asks for the new sound a little bit before it’s needed, so it can have everything ready to go when the time arrives. It’s not predictable exactly how much spare time Decker needs, but 200 milliseconds (a fifth of a second) should be a very safe margin while not being too distracting if the loop jumps to the next sound too quickly).