| |
ChristopherJam
Registered: Aug 2004
Posts: 1424 |
ADSR delay bug
I've been looking through the source code for the envelope generator in reSid, as it seems the best repository of experimental SID knowledge. Now I think I understand why my instruments were broken when I was only gating for a single frame. (well, broken on real c64 - seemed to work under Power64's emulation where I'd been composing, more fool me..)
Just checking that I understand the consequences correctly:
Is it really the case that whenever you have a release value greater (slower) than your attack that the start of your next note can be randomly delayed by up to 1.5 frames!?
How do other composers deal with this? Does everyone just always gate for a minimum of two frames, and cross fingers that the delay doesn't break the timing too badly, or do people just keep their attack value at least equal to their release value?
(I'm ignoring the effect of long decay values for the moment - my head is hurting enough already!) |
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1424 |
Of course, now I see the earlier post (Sid ADSR problem / hardrestart) that covers some of this ground - and I can see why holding a voice muted with a decay of zero for 40ms before you need it would work. (well, actually anything over 32768 cycles will do - but that's why one frame is not enough).
FWIW, if reSid's model of the bug is correct, then it implies that if you have an instrument where A=D=R and always use the same settings for that voice, you will never have the ADSR problem.
In other words, any XXYX should also be fine as long as you are consistent for that voice for the entire tune (or at least, do a 32ms restart before changing to a lower value of X =). |
| |
Frantic
Registered: Mar 2003
Posts: 1661 |
Another way to deal with it, I think, is to write the values to the sid first thing you do in the player and use a stable interrupt to call it, to make sure the same thing will happen each time you play the tune, and then you would have to tweak it to make sure it sounds good.
May be a good alternative, or complement, or not... I mean, the "randomness" is not always bad. Sometimes it stays within an acceptable range. At least it doesn't really cost much to set up such a stable interrupt for this use and there's no real drawback as far as I see it, at least if you player uses buffered values for writing already (otherwise the situation is different of course). |
| |
cadaver
Registered: Feb 2002
Posts: 1163 |
Most players today actually deliberately induce a delay bug for each note, by gating two frames and using ADSR values & SID register write order that guarantee the bug. But to answer your original question, in my games I've actually always used 1-frame gating for raw feeling, works nicely although a bit randomly.
Then there are various bastard methods to use, like hiding the delay bug inconsistency by using a silent gated on first frame together with 1-frame gateoff or even no gating at all :) Works nice in John Player for example. |
| |
Frantic
Registered: Mar 2003
Posts: 1661 |
@Cadaver: What would you consider a register write order that would not induce any potential for an ADSR bug whatsoever? (in the case where the gate bit have been off for 2 frames at least.) |
| |
cadaver
Registered: Feb 2002
Posts: 1163 |
Please refer to my article in the recently released HVSC collection, it summarizes most if not all the methods with their relative advantages/disadvantages.
But to never induce delaybug (actually this may not be the sound you want, it's like oldschool Hubbard), write new instrument values in order: AD, Wave, SR. SR must have been $00 for the 2 gateoff frames before.
Wave, AD, SR is also OK most of the time but the first variation is theoretically most correct. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1424 |
Well, if you write wave before AD, you will have a number of cycles using the old attack value before you write the new one. If the new attack value is lower, the internal counter may already have surpassed the new limit, so the envelope will get stuck again.
AD,gate,SR makes sense, as that way you are only changing the envelope rate once.
I would be surprised if the limitation on SR for the preceding two frames is anything other than 'R must be less than or equal to the next A' - enforcing zero seems overkill to me. And with a 2x player, you could just force it to the lower value for 1.5 frames rather than 2 :) |
| |
cadaver
Registered: Feb 2002
Posts: 1163 |
Actually, release 0 is required because you want the rate counter circling the smallest possible cycle, otherwise attack 0 may bug, and attack 0 is nice & useful, right? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1424 |
Sure, if you don't know what the next A will be. My point was if you know that the next note will have an attack of (say) 3, then decay can be any of 0,1,2 or 3, which gives you a little more flexibility in how sharply you kill the current note. |
