[CSDb] - User Forums - Technical ADSR Bug Question

Welcome to our latest new user maak ! (Registered 2024-04-18)

You are not logged in - nap

CSDb User Forums

Forums > C64 Composing > Technical ADSR Bug Question

2023-03-19 06:02

acrouzet

Registered: May 2020
Posts: 80

Technical ADSR Bug Question

Hi there, I have quite a technical question about the SID envelopes’ inner workings that I’m hoping some of you may be able to answer.

If I understand correctly, the SID’s ADSR bug occurs due to flaws in the counter and the value that the counter’s state is compared with which determines how many cycles to wait until increasing/decreasing the envelope amplitude. If the comparison value changes to a value that’s lower than the counter’s current state, the counter will need to count up to its maximum state, wrap around, and reach the new comparison value before the envelope amplitude changes again.

If this were purely the case, I would expect the amount of delay caused by the ADSR bug to vary quite a bit. For example, if a note with attack 0 was gated on during a very slow release, I’d expect the counter’s state when the comparison value is changed to vary depending on the time of gate on. Thus, I’d expect the durations between gate on and the envelope’s attack being realized to be relatively evenly distributed across many SID tunes at different speeds.However, when looking at the SID’s output, I notice that the ADSR bug delay (at least between release and attack 0) seems to only vary between 4 specific durations:

- No delay. Seems to be most common with releases 0-2. Can sometimes occur with releases 3 and above.
- A delay of ~33ms. Seems to be the most common with releases 3-C.
- A delay of ~14ms. Seems to sometimes occur with releases D-E.
- A delay of ~6 ms. Seems to sometimes occur with release F.

There may be more delay times, but those are all the ones I have noticed. Even then, I would have expected there to be much more variation.

I’ve done research on this topic, mainly via looking through Codebase64 and residfp’s source code comments. However, I still can’t explain why this happens. As a fellow SID nerd, it’d be much appreciated if anyone would shed some light on this topic, which I’ve been curious about for a while, even if there isn't any real use for it.

2023-03-19 10:14

ChristopherJam

Registered: Aug 2004
Posts: 1370

So, you are correct that the time it takes to recapture the rate counter will depend on the current state (32768-N cycles to be specific) - but the starting value is usually quite low.

I assume you've come across the table of rate counter periods in envelope.cc (included below for reference) - you can see that the first ten rates are all under a thousand, which means that the time to recapture any of them would be between 31 and 32ms.

A lot of instruments set release to zero a frame ahead of starting the next note - which then means the first 20ms of the envelope freeze has already been absorbed before the next note is triggured - that gives you a 12ms delay between requested note start and the envelope starting to rise.

Also, if the rate is set to zero two or more frames before the next note, the recapture will be complete before the next note starts, giving a delay of zero.

I think those three paras cover most of your observations?

      8,  //   2ms*1.0MHz/256 =     7.81
     31,  //   8ms*1.0MHz/256 =    31.25
     62,  //  16ms*1.0MHz/256 =    62.50
     94,  //  24ms*1.0MHz/256 =    93.75
    148,  //  38ms*1.0MHz/256 =   148.44
    219,  //  56ms*1.0MHz/256 =   218.75
    266,  //  68ms*1.0MHz/256 =   265.63
    312,  //  80ms*1.0MHz/256 =   312.50
    391,  // 100ms*1.0MHz/256 =   390.63
    976,  // 250ms*1.0MHz/256 =   976.56
   1953,  // 500ms*1.0MHz/256 =  1953.13
   3125,  // 800ms*1.0MHz/256 =  3125.00
   3906,  //   1 s*1.0MHz/256 =  3906.25
  11719,  //   3 s*1.0MHz/256 = 11718.75
  19531,  //   5 s*1.0MHz/256 = 19531.25
  31250   //   8 s*1.0MHz/256 = 31250.00

(side note - the internal implementation is a shift register with feedback, but in practice, you can ignore that detail; the behaviour is identical to an ordinary counter.)

2023-03-19 21:28

acrouzet

Registered: May 2020
Posts: 80

Quote: So, you are correct that the time it takes to recapture the rate counter will depend on the current state (32768-N cycles to be specific) - but the starting value is usually quite low.

I assume you've come across the table of rate counter periods in envelope.cc (included below for reference) - you can see that the first ten rates are all under a thousand, which means that the time to recapture any of them would be between 31 and 32ms.

A lot of instruments set release to zero a frame ahead of starting the next note - which then means the first 20ms of the envelope freeze has already been absorbed before the next note is triggured - that gives you a 12ms delay between requested note start and the envelope starting to rise.

Also, if the rate is set to zero two or more frames before the next note, the recapture will be complete before the next note starts, giving a delay of zero.

I think those three paras cover most of your observations?

8, // 2ms*1.0MHz/256 = 7.81 31, // 8ms*1.0MHz/256 = 31.25 62, // 16ms*1.0MHz/256 = 62.50 94, // 24ms*1.0MHz/256 = 93.75 148, // 38ms*1.0MHz/256 = 148.44 219, // 56ms*1.0MHz/256 = 218.75 266, // 68ms*1.0MHz/256 = 265.63 312, // 80ms*1.0MHz/256 = 312.50 391, // 100ms*1.0MHz/256 = 390.63 976, // 250ms*1.0MHz/256 = 976.56 1953, // 500ms*1.0MHz/256 = 1953.13 3125, // 800ms*1.0MHz/256 = 3125.00 3906, // 1 s*1.0MHz/256 = 3906.25 11719, // 3 s*1.0MHz/256 = 11718.75 19531, // 5 s*1.0MHz/256 = 19531.25 31250 // 8 s*1.0MHz/256 = 31250.00

(side note - the internal implementation is a shift register with feedback, but in practice, you can ignore that detail; the behaviour is identical to an ordinary counter.)

Why is the starting value seemingly always low enough to barely make a difference in delay time between cases? I've experimented with refresh rates other than 50hz, and they all seem to produce similar results.

Also, I've not seen the second case you've described. Are you referring to hard restart?

2023-03-19 22:57

acrouzet

Registered: May 2020
Posts: 80

After some more experimenting with even more refresh rates and redoing the math, it seems that I was wrong in assuming that the ADSR bug delay must vary more than it does.

Refresh

Subscribe to this thread: