| |
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....
|
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
I somehow missed the point towards the end.. "you want to reach the sustain level as quickly as possible" and "you want a slow attack" doesn't make sense to say at the same time. Did you mean something like "and after that, you want the next attack to be slow"? (Sorry.. bit tired here..) |
| |
lft
Registered: Jul 2007
Posts: 369 |
Frantic: "... you want to reach the sustain level as quickly as possible" given that attack rate. That is, you want the decay phase to be as fast as possible without triggering the ADSR bug.
But yeah, I realise now that this part of the reasoning is a bit contrived. This is better: "... you want to reach the sustain level in a deterministic time for every note". |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Nice post, and mostly correct. Excellent point on hiding the bug in the sustain phase in instances when you want to change to a faster release; I've been meaning to incorporate that into an envelope editor/player for some time now, but have been distracted by VIC (and life outside the c64!) for the last few years.
I did quite a bit of testing back in 2011, and discovered a few interesting things. Firstly, the attack to decay transition is always safe, as it happens under SID control when the internal counter to the next envelope step has just been reset. A to R and D to R however, can indeed trigger the bug as you describe, as they change timer threshhold as soon as the gate bit is changed.
I also found a rather obtuse potential cause of the bug. When you first set the gate bit to trigger a new note, there's a single cycle where SID is using the rate from 'decay' rather than attack - so for example if you have both attack and release set to zero, but decay set to something slower, there's a one in nine chance of triggering the bug at the very start of the note. This can be avoided by setting decay to the same value as attack until just after you set the gate bit. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11113 |
Quote:life outside the c64!
WTF |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
I know, right?
Stupid Australia still hasn't instituted a Universal Basic Income, so apparently I have to work for other people to get money for food and rent.
Maybe I need a KickStarter or Patreon account to fund my life as a full time demo and emulator coder.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11113 |
let me know if/when it works :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
:) |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Lord and saviour! That can be really useful in GT ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11113 |
back to the original topic.... is that delay really unpredictable? i mean, its just a counter that misses a certain condition, not some weird analog effect that is totally random - shouldnt it infact be *totally* predictable? |
| |
Mixer
Registered: Apr 2008
Posts: 422 |
AFAIK, it is not possible to reset the ENV internal LFSR like one can reset the oscillator for instance. If I remember correctly the uncertainty can be narrowed down to 9(?) cycles with some lenghty manipulation, but doing that is not practical in a player.
residfp source code refers to this:
http://ploguechipsounds.blogspot.it/2010/03/sid-6581r3-adsr-tab..
and this:
http://blog.kevtris.org/?p=13
I suppose this part of the emulation is bit too deterministic in the sidplay-fp since many tunes made with PC-emulators still have ADSR problems when played in a real machine. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
