I have seen many players that seemed to voluntarily triggered a second delay bug before attack restart.
Rate Normal Extra Total 0 2 ms 30 ms 32 ms 1 8 ms 30 ms 38 ms 2 16 ms 16 ms 3 24 ms 24 ms 4 38 ms 38 ms ...
If I understood your suggestion correctly, that would involve starting the entire procedure three frames ahead of time when a hard-restart instrument with attack rate 0 or 1 is due.
If we use your suggestion from Avoiding the ADSR bug in the decay phase. to hide the bug in the sustain phase, then one can use the second last frame of the previous note to initiate a 6ms release, then in the final frame one can use your suggestion above to kick off a delayed attack :D
Requiring a semi-precise window of timing practically means you'll have to run the player in the border, otherwise the variable time of execution on other channels may lead the time-critical execution of e.g. the last channel to happen during a badline.
Does this all assume that sustain value should be dropped completely down to $00 before restart? Or by (level-1)..0?
What if i wanted to leave at previous sustain level (read: reverb) until just the next tone Attack cycle starts? ..Without any delay, how would you deal with that?
why not simulate the release with lowering Sustain level instead.
But how would you do a HR then, let's say when the remaining amplitude would be anything between $00..$ff? (And i don't mean the $d406 sustain setting)
Force a bug at start of second last frame of previous note, clear gate, and set S=R=0. This way the sustain continues until halfway through the last frame (as the envelope is frozen), then the level drops to zero in at most 6ms, leaving less than 10ms silence before the start of the next note.
Quoting cadaverRequiring a semi-precise window of timing practically means you'll have to run the player in the border, otherwise the variable time of execution on other channels may lead the time-critical execution of e.g. the last channel to happen during a badline. Correct! For what it's worth, I believe that sprite DMA is safe. Nine cycles of phase uncertainty plus 0..19 stolen cycles, that's a jitter of 9 + 20 - 1 = 28 cycles, and we need to be within a 31-cycle range. So ghost sprites in the border shouldn't be a problem as long as the playroutine is tightly coded.
Editor should know what the rate limit is at that point, from the duration of the note. If the rate limit index is less than $f,then increase to $f for at least nine cycles, then drop rate limit index to $0
Quoting lftQuoting cadaverRequiring a semi-precise window of timing practically means you'll have to run the player in the border, otherwise the variable time of execution on other channels may lead the time-critical execution of e.g. the last channel to happen during a badline. Correct! For what it's worth, I believe that sprite DMA is safe. Nine cycles of phase uncertainty plus 0..19 stolen cycles, that's a jitter of 9 + 20 - 1 = 28 cycles, and we need to be within a 31-cycle range. So ghost sprites in the border shouldn't be a problem as long as the playroutine is tightly coded. Some further thoughts: The worst that could happen is eight sprites, badline, eight sprites. That's going to push the counter beyond 63, but it's still well below 149. For the musician, this means that hard-restart instruments with attack rate 2 or 3 are unsafe (i.e. the note start could randomly be delayed by 30 ms) if the playroutine executes in the normal display area. Any other attack rate is going to behave properly. Rates 0 and 1 will always have the extra delay, and rates 4 and above will never have it. So this technique would still be usable in e.g. CIA-tempo tunes if you just avoid those two attack rates.
