[CSDb] - User Forums - Avoiding the ADSR bug in the decay phase.

You are not logged in - nap

CSDb User Forums

Forums > C64 Composing > Avoiding the ADSR bug in the decay phase.

2015-04-21 11:49

lft

Registered: Jul 2007
Posts: 369

Avoiding the ADSR bug in the decay phase.

Random insight of the day:

The ADSR bug is well known: When we switch from a slow to a fast envelope rate, the envelope generator sometimes gets stuck for about 33 ms (1.67 PAL frames). This tends to happen when we have a slow release, and then try to trigger a note with a fast attack. The attack gets delayed unpredictably.

Some playroutines provide a hard restart feature to work around this problem.

But here's the insight: The same thing can and does happen when we switch from a slow attack to a fast decay, or from a slow decay to a fast release. So, if we use an ADSR setting of, say, 10 aa, we get a fast attack, and then we switch to an even faster decay. This will actually trigger the bug! The volume level could remain at the maximum for up to 33 ms. Furthermore, if we try to release the note too soon (within 1-2 frames), the release could be delayed unpredictably.

To avoid this, we have to use a decay rate that is greater than or equal to the attack rate.

On the other hand, sometimes this phenomenon is useful. If we want a slow attack and a fast release, and we know that we want to hold the note for more than two frames beyond the attack period, then this is exactly what we want. For instance, if we use f0 f2, we get a slow attack, followed by the ADSR bug (random delay of up to 33 ms). Then, as soon as we release the gate, we get an immediate response, because we already have the bug behind us.

To summarise:

If you want to reach the sustain level in the same amount of time for every note, or if you want to reach it as quickly as possible, ensure that D >= A.

If you want the release to start immediately when you turn off the gate bit, ensure that R >= D.

Advanced technique:

Suppose you want to reach the sustain level as quickly as possible, but you also want the release to start immediately. And you want a slow attack and a fast release.

A > R, R >= D, D >= A, does not compute.

But you can use e.g. 77 84 when you start the note, and then, after the note has reached the sustain phase, switch to an instrument with a 70 84 envelope. Then wait two more frames to get past the bug. Then, the release will be predictable and immediate.

... 31 posts hidden. Click here to view all posts....

2015-04-21 23:24

chatGPZ

Registered: Dec 2001
Posts: 11386

interesting.... and now i really have to wonder why there isnt a bug report about it, shouldnt be hard to fix afterall.

2015-04-22 04:08

ChristopherJam

Registered: Aug 2004
Posts: 1409

While it's true that one cannot simply reset the internal LFSR with a few instructions, it is possible to get it into a known state - it just takes about three frames.

First capture it to the nine cycle window by setting ADSR to $0000, clearing Gate, and waiting 40ms (32768 cycles for overlow, plus 756*9 cycles for decay from maximum), then do this:

	ldx#$01
	.repeat 10
	inx
	stx v3SR
	dex
	stx v3SR
	jsr wait51 ;delays 51 cycles, including the 12 cycles for jsr/rts
	.endrep

It will then still be in one of nine different states, however all the possible counter values at this point are equal modulo 9 (yes yes, I know the "counter" is implemented as an LFSR, but that's not important right now)

Recapture by waiting another 32768 cycles, then you're good to go. After that, as long as you call your player at the exact same cycle every frame, your track will sound the same every time... Of course, the bug will still occur, but it at least it will occur consistently. So yes, in practice this technique is probably only really useful for setting up experiments for finding and fixing bugs in SID emulation, and then writing better tools and documentation for musicians.

2015-04-22 05:26

Oswald

Registered: Apr 2002
Posts: 5094

so it should be possible to write a deterministic tracker and player, that is: tracker could force ADSR settings of instruments to avoid the bug without hardrestart, while replaying.

2015-04-22 06:22

ChristopherJam

Registered: Aug 2004
Posts: 1409

Theoretically, yes. It would just require some very careful timing of register writes if you wanted complete freedom of envelope settings, and writing the code to track envelope state on the c64 itself would be.. challenging..

Personally I was leaning towards trying to write an envelope editor that ran on a more capable host platform, that disallows any settings that risk the bug occurring at any audible points, and uses deep knowledge of the underlying timers to allow a reasonable degree of flexibility.

2015-04-22 06:27

ChristopherJam

Registered: Aug 2004
Posts: 1409

@Groepaz - I was going to submit a bug report about the single cycle at Release pace, but got side tracked trying to write a cycle exact drop in for ReSID's envelope generator.

That in turned got pretty bogged down with trying to write a ruleset that determined when the envelope transitions actually occurred, as it appears to happen either on the cycle the internal counter resets or one cycle later, depending on envelope phase, the exponential decay generator, and exactly when you trigger gate. Even keeping AD and R all to 0, it proved to be a stupidly hard problem..

2015-04-22 10:01

lft

Registered: Jul 2007
Posts: 369

Quoting ChristopherJam

ldx#$01 .repeat 10 inx stx v3SR dex stx v3SR jsr wait51 ;delays 51 cycles, including the 12 cycles for jsr/rts .endrep

I think the idea is to reposition each of the nine possible phase offsets, so that they are spaced equally apart at some period which happens to be a valid envelope rate period. This seems like a clever approach.

You are selecting period 63 at T+0, then period 32 at T+6, then 63 again at T+63 etc. Suppose the initial phase is 0. At T+63, it is 31. You switch to period 63 and wait six more cycles. During these cycles, the phase increments to 37. But then it takes 57 more cycles before you switch back to period 32. Now the phase has incremented to 94, and the ADSR bug is triggered.

So presumably the idea is to trigger the ADSR bug at one of nine known times, 63 cycles apart? In that case, aren't we missing the most crucial step, which is to leave the rate configured at a period of 63 cycles, to nicely recapture the phase after the overflow?

I keep thinking that perhaps there's some way to do this without going through the whole overflow procedure twice. But I haven't found a solution yet.

2015-04-22 10:57

ChristopherJam

Registered: Aug 2004
Posts: 1409

Oops, you're quite right, also need to set release to zero before waiting for it to recapture.

Yes, I too would love to find a way to stabilise without letting it escape twice. Voice three you could probably monitor in similar ways to building stable rasters, but as for the first two voices - ideas welcome!

2015-04-22 11:09

chatGPZ

Registered: Dec 2001
Posts: 11386

Quote:

@Groepaz - I was going to submit a bug report about the single cycle at Release pace, but got side tracked trying to write a cycle exact drop in for ReSID's envelope generator.

please do - a test program that shows the problem (and allows to verify it has been fixed) would also be very nice

2015-04-23 09:03

ChristopherJam

Registered: Aug 2004
Posts: 1409

Oh wow, I've not kept up. I've just spent a couple of hours writing some test code to submit, but my current VICE install is already passing.

Some time in the last 4 years it's started emulating this 'feature' correctly :D

@Groepaz, is it still worth submitting as a regression test?

2015-04-23 13:04

chatGPZ

Registered: Dec 2001
Posts: 11386

definately.... the more test programs the better :)

also, i am surprised - there is certainly no LFSR in the current envelope generator (or perhaps i am blind? *shrug*)

Previous - 1 | 2 | 3 | 4 | 5 - Next

Refresh

Subscribe to this thread: