At #cycle 1, a sixteenth note has the length of 1 idle. So the following is exactly idle-d:
Code: Select all
#cycle 1
'nothing playing right now
#play tcd
'each note takes 1/2 of an idle
/i
#play se
/i
#play if
/i/i
#play qg
/i/i/i/i
#play ha
/i/i/i/i/i/i/i/i
#play wb
/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i
'music stops exactly here
Minor technical-correctness detail: this assumes that ZZT is running at the default speed (see setting "Game Speed" on the title screen menu; default is where the arrow points at the ":" in "F....:....S"). But default speed is pretty much assumed (the user would have to go out of his way to change it), so don't worry about what I just said here.
bitbot wrote:I have a sneaking suspicion that results may vary on different machine speeds... Is this correct?
It's possible, but I don't think it would be significant. The only way I can see machine speed figuring into it is if your ZZT-OOP completely bogs down ZZT (which would make idles longer -- in which case you have more serious problems, like the player only being able to take a step every 2 seconds).
bitbot wrote:What I've done is created a music object that sets/clears flags for each #PLAY so when you enter the next room, a duplicate object continues playing where it left off... It works pretty well.
Holy cow, that's pretty impressive! I'm looking forward to seeing this in action. But if it starts to become too much work, don't be afraid to rework it -- that's above-and-beyond effort right there.
Do you literally have flags for every #play statement, or are you clustering #play statements together? If you put one #play immediately after another, with no commands in-between, I'm pretty sure that there's no way for the player to leave the board after the first one but before the second one.