| |
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. |
|
| |
Mixer
Registered: Apr 2008
Posts: 422 |
Great observations.
Could be useful to build a sort of a look up table for the various combinations including other ADSR observations what to do or not to do. Most often it is trial and error when making sounds, but perhaps these observations will reduce time spent on the error. |
| |
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: 11108 |
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: 11108 |
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: 11108 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
interesting.... and now i really have to wonder why there isnt a bug report about it, shouldnt be hard to fix afterall. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
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. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
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. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
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. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
@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.. |
| |
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. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
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! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
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 |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
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? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
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*) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Ahaha, I'm an idiot. I was accidentally running my test code in an old copy of vice-2.2 I'd started writing a patch for. I'll investigate more thoroughly in the morning :D |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting ChristopherJamYes, I too would love to find a way to stabilise without letting it escape twice.
I spent some time thinking about this, until I had convinced myself that it was, in fact, impossible.
Then I figured out a way to do it anyway.
I believe this technique could be used to implement a new kind of hard-restart mechanism where you would get predictable ADSR bugs at the note level (i.e. each note with the same instrument, held for the same amount of frames, gets exactly the same envelope). For instance, you could toggle the gate bit any number of times from the wavetable, and the instrument would still sound exactly the same every time. However, this feature would eat up a lot of rastertime (at least 10 more lines) and would require parts of the playroutine to be cycle exact. But it could be useful for compo tunes.
In the immortal words of Knuth, beware of bugs in the code; I have only proved it correct, not tried it.
I'll take it from the beginning.
The first step is to perform an ordinary hard restart, i.e. selecting the shortest period (nine cycles) and waiting for the counter to wrap around. However, we add a twist, which is to perform the hard restart with the gate enabled and ADSR = 00ee. Naturally, we also select waveform 0 to avoid audible artefacts.
This will leave us in the sustain state, with the envelope counter at $ee, the exponential counter period at 1, and the rate counter somewhere in the range 0..8.
Now we do something quite similar to the code snippet provided by ChristopherJam. I took the liberty of optimising it, by using periods 9 and 32 instead, and distributing the phases 45 cycles apart instead of 63.
ldx #$ee
lda #$11
ldy #7
jmp entry
loop
nop
sta $d405 ; 11
nop
nop
sax $d405 ; 00
nop
nop
nop
nop
nop
entry
stx $d405 ; ee
nop
nop
sax $d405 ; 00
nop
nop
dey
bne loop
bit 0
sta $d405 ; 11
Below is a table that shows what happens to the rate counter as we run the code. Starting with a given initial phase, run for N cycles at period P to obtain the phases on the next line.
Counter value (modulo 9 in brackets) N P
------------------------------------------------------------------------+------+ -------
0 (0) 1 (1) 2 (2) 3 (3) 4 (4) 5 (5) 6 (6) 7 (7) 8 (8) | 8 | 19532
8 (8) 9 (0) 10 (1) 11 (2) 12 (3) 13 (4) 14 (5) 15 (6) 16 (7) | 15 | 9
5 (5) 24 (6) 25 (7) 26 (8) 27 (0) 28 (1) 29 (2) 30 (3) 31 (4) | 8 | 32
13 (4) 0 (0) 1 (1) 2 (2) 3 (3) 4 (4) 5 (5) 6 (6) 7 (7) | 14 | 9
27 (0) 5 (5) 6 (6) 7 (7) 8 (8) 0 (0) 1 (1) 2 (2) 3 (3) | 8 | 19532
35 (8) 13 (4) 14 (5) 15 (6) 16 (7) 8 (8) 9 (0) 10 (1) 11 (2) | 15 | 9
50 (5) 28 (1) 29 (2) 30 (3) 31 (4) 5 (5) 24 (6) 25 (7) 26 (8) | 8 | 32
58 (4) 4 (4) 5 (5) 6 (6) 7 (7) 13 (4) 0 (0) 1 (1) 2 (2) | 14 | 9
72 (0) 0 (0) 1 (1) 2 (2) 3 (3) 27 (0) 5 (5) 6 (6) 7 (7) | 8 | 19532
80 (8) 8 (8) 9 (0) 10 (1) 11 (2) 35 (8) 13 (4) 14 (5) 15 (6) | 15 | 9
95 (5) 5 (5) 24 (6) 25 (7) 26 (8) 50 (5) 28 (1) 29 (2) 30 (3) | 8 | 32
103 (4) 13 (4) 0 (0) 1 (1) 2 (2) 58 (4) 4 (4) 5 (5) 6 (6) | 14 | 9
117 (0) 27 (0) 5 (5) 6 (6) 7 (7) 72 (0) 0 (0) 1 (1) 2 (2) | 8 | 19532
125 (8) 35 (8) 13 (4) 14 (5) 15 (6) 80 (8) 8 (8) 9 (0) 10 (1) | 15 | 9
140 (5) 50 (5) 28 (1) 29 (2) 30 (3) 95 (5) 5 (5) 24 (6) 25 (7) | 8 | 32
148 (4) 58 (4) 4 (4) 5 (5) 6 (6) 103 (4) 13 (4) 0 (0) 1 (1) | 14 | 9
162 (0) 72 (0) 0 (0) 1 (1) 2 (2) 117 (0) 27 (0) 5 (5) 6 (6) | 8 | 19532
170 (8) 80 (8) 8 (8) 9 (0) 10 (1) 125 (8) 35 (8) 13 (4) 14 (5) | 15 | 9
185 (5) 95 (5) 5 (5) 24 (6) 25 (7) 140 (5) 50 (5) 28 (1) 29 (2) | 8 | 32
193 (4) 103 (4) 13 (4) 0 (0) 1 (1) 148 (4) 58 (4) 4 (4) 5 (5) | 14 | 9
207 (0) 117 (0) 27 (0) 5 (5) 6 (6) 162 (0) 72 (0) 0 (0) 1 (1) | 8 | 19532
215 (8) 125 (8) 35 (8) 13 (4) 14 (5) 170 (8) 80 (8) 8 (8) 9 (0) | 15 | 9
230 (5) 140 (5) 50 (5) 28 (1) 29 (2) 185 (5) 95 (5) 5 (5) 24 (6) | 8 | 32
238 (4) 148 (4) 58 (4) 4 (4) 5 (5) 193 (4) 103 (4) 13 (4) 0 (0) | 14 | 9
252 (0) 162 (0) 72 (0) 0 (0) 1 (1) 207 (0) 117 (0) 27 (0) 5 (5) | 8 | 19532
260 (8) 170 (8) 80 (8) 8 (8) 9 (0) 215 (8) 125 (8) 35 (8) 13 (4) | 15 | 9
275 (5) 185 (5) 95 (5) 5 (5) 24 (6) 230 (5) 140 (5) 50 (5) 28 (1) | 8 | 32
283 (4) 193 (4) 103 (4) 13 (4) 0 (0) 238 (4) 148 (4) 58 (4) 4 (4) | 14 | 9
297 (0) 207 (0) 117 (0) 27 (0) 5 (5) 252 (0) 162 (0) 72 (0) 0 (0) | 8 | 19532
305 (8) 215 (8) 125 (8) 35 (8) 13 (4) 260 (8) 170 (8) 80 (8) 8 (8) | 15 | 9
320 (5) 230 (5) 140 (5) 50 (5) 28 (1) 275 (5) 185 (5) 95 (5) 5 (5) | 4 | 32
324 (0) 234 (0) 144 (0) 54 (0) 0 (0) 279 (0) 189 (0) 99 (0) 9 (0) | |
At this point, the phases for the nine possible cases have been spread out so that they are equal modulo nine. The maximum value of the counter is 324.
Now for the spectacular finale where I take the error in my original post and turn it around to my advantage. We release the gate, set ADSR to 80ee, turn the gate on again, and wait for at least 392 * 17 cycles.
When we release the gate, nothing much happens (the period is reconfigured to 19532). But when we re-enable it, the state machine enters the attack state, and the envelope counter is incremented exactly 17 times, 392 cycles apart (rate #8). On the 17th time, the counter reaches $ff, and the rate counter is reconfigured for rate #0 (the decay rate), with a period of nine cycles. As was kindly pointed out by ChristopherJam, this transition happens synchronously, and doesn't trigger the bug. We don't know exactly when the transition occurs; it could happen at any of nine different moments. But these moments are equal modulo nine, so after the transition, the value of the rate counter is at a fixed offset relative to the time we turned on the gate, and thus relative to the remainder of the playroutine. This makes the ADSR bug behave deterministically.
We are now left with the the envelope counter at $ee when we want it at $00. A full decay takes 7k cycles. In fact, to implement a hard restart using the technique as described above, we would need to spread the routine over three frames. In a practical implementation, we should instead work with sustain level f, and take care to work around the envelope counter wraparound bugs. The entire procedure would then require 32758 cycles for the initial counter wrap, 2295 cycles to reach $ff, some 300 cycles for the code snippet above and 392 cycles to finally reach the decay stage, for a total of 35745 cycles (1.8 PAL frames). This would then be followed by some code to increment the envelope counter to $00, unfreeze it and release the gate.
To get an actual implementation up and running is left as an exercise for the reader. |
| |
Mixer
Registered: Apr 2008
Posts: 422 |
Quoting lft
I spent some time thinking about this, until I had convinced myself that it was, in fact, impossible.
Then I figured out a way to do it anyway.
That is how to sum up the scene-attitude. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Oh that's bloody brilliant - nice work indeed. Perfect rate counter sync, and in about as much time as a normal hard restart. Going to have to have a go at trying this one out. At the very least, it should mean I can run my regression tests and measurements twice as fast :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
gogogo! :) |
| |
Agemixer
Registered: Dec 2002
Posts: 38 |
All right.. i haven't examined the ADSR bug(s) yet until now.. i should because i'm working on an editor which "almost requires"more exact handling of SID in general. I never did a "proper" hardrestart, but got to know there are plenty or "wrong" ways to do it, unlesss i'm mistaken?
Despite those sound flaws the tunes made even from the early days plays relatively perfectly (most of them) so that it's unlikely to heard bugs.
What exact transitions or SID programming sequences affect what, i have no idea. I only know the hard restart by musicroutines are made setting 2 frames before setting gate=1 to get a faster response for Attack cycle. But does it really have to be so?
I'm not familiar yet with all the current SID jargon, but i try to understand anyway :)
Are there any tools, test suites, code snippets, or whatsoever to demonstrate and minimize the problems? Do they summarize into just one ADSR counter having its own internal life and cannot be directly reset or programmed?
i can see most of you have been examining the ADSR bug for a while now.. The last time i was into that stuff was last millenium :)
Anyway, i just finished a little tool to examine ADSR:
http://skalaria.japo.fi/adsr-oscilloscope.zip
Also a source code available:
http://skalaria.japo.fi/adsr-oscilloscope.asm
Feel free to send patches and features for this. I already spent several hours doing that code. |
| |
Agemixer
Registered: Dec 2002
Posts: 38 |
I'm not sure if that oscilloscope is a good one at all to examine this one, but atleast visualizes the SID. f.e. I read the R cycle is logarithmic but i didn't know it is THAT much. (refering to Bob Yannes there's some LUT tables to certain positions to halve the oscillator for D and R but A is a linear one).
About the program: The left side illustrates the gate is turned on, the right (grey) side when gate is turned off.
And i found some weird ADSR behaviors. One is here:
Start ADSR=$1132
Start gate=$41
Ending ADSR=$1132
Ending gate=$40
and, gate delay=9. (You can count the exact cycles out of this (SEI), see the code for reference to calculate it.)
Press return key several times. For some strange reason the ADSR is started sometimes in the middle of the screen. I thought the delay must be fraction of this, but the osc says there's a lot of cycles wasted before it actually starts, and starts always at same position (just using Vice, i haven't checked with real machines yet).
How is that possible, and why the Attack starts that late, in this situation?! Notice the small AD/R values, so exactly what might be causing this? |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
I may miss something obvious but aren't you simply encountering the ADSR bug, which manifests itself precisely as a delay happening whenever that internal counter misses its target criterion and wraps around internally before eventually hitting the target criterion? At least that's my understanding.
Nice program btw. :) |
| |
Agemixer
Registered: Dec 2002
Posts: 38 |
Thanks :)
Are all the bugs known gate transition influenced? Or register write? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Yup, that would be the ADSR bug manifesting.
To the best of my knowledge:
- it's only triggered by register writes
- it can happen any time a register write causes a transition from a slow speed to a faster one
- this happens either by changing the rate of the envelope phase that's currently running (eg changing attack from 4 to 3 during the attack time)
- or by setting or clearing the gate bit at a time there are 'dangerous' ADSR values set.
In your case, you're transitioning from a release of 2 to an attack of 1.
In general, setting gate when R>A, or clearing it when R<D (or <A if you do it during attack) will always risk locking up the envelope for a frame and a half.
There's also a slight risk setting gate when R=A, but only if D is different to them, and a clever music routine could work around this by temporarily setting D to the same as the other two (there's a single cycle bug that most emulators don't cover yet)
The usual work around is to use a hard-restart, that hides the lockup in a couple of frames of silence before the note starts. As LFT suggested above, in some instances it should be possible to hide the lockup in the sustain phase instead, but that would require more control than many players provide you with. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
By the way.. if someone feels like writing something up about the ADSR bug and ways to deal with it, to put on Codebase64, that would be very nice. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Finally had a play with Agemixer's ADSR tool last night; it's pretty neat!
I've just put a post up at SID envelope rate counter phase alignment with some optimisations to the phase wrangling; it's all getting a little off topic for actual composing, as that level of register bashing is more a thing for implementing players etc.
I will add "write a decent artist's guide to the ADSR bug for codebase" to my todo list mind, much as I feel like I'm teaching grandma to suck eggs here; Agemixer is one of the greats! |
| |
Laurent
Registered: Apr 2004
Posts: 40 |
Quoting lftHowever, we add a twist, which is to perform the hard restart with the gate enabled and ADSR = 00ee. Naturally, we also select waveform 0 to avoid audible artefacts.
I haven't tested this, but I wonder if we would hear something on the 6581 due to the DC offset that gets scaled by the envelope DAC ? |
| |
Mixer
Registered: Apr 2008
Posts: 422 |
If the osc level at the moment of WF=0 selection is not 0, there will be a DC offset component that moves according to the env changes. This has been used to play "ADSR" samples.
But normally ENV changes so slowly that the sound is quite unhearable. Sharp fast changes frequently could be heard. |
| |
Danko
Registered: Nov 2002
Posts: 19 |
The nifty thing with implementing a hard restart function is that you don't have much to do over, say, three frames.
So why not divide up the code and execute it over three frames instead of one, fill up a buffer and then copy buffer to D400-> at the end.
We all know this, so just a slight reminder what a "traditional" hard restart as implemented by JCH can do in order to help decreasing raster time.
The other thing, but more fuzzy as it where...
The envelopes in the SID are derived from four preset curves and all intermediate steps are merely interpolated. Having 0-F for each envelope step is merely an illusion. The big breaking point happens when D goes from 8 to 9, check it out.
You can play with that. One method is to stay below D of 9 and make very snappy nice sounds, the downside is that the song will have less loudness compared to other songs. One example of this is my cover of Erasure's Breath of Life that I made for a Fairlight demo once. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting ChristopherJamWhen 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.
Gaah, this bit me today. Song plays flawlessly in vice, but with ADSR bugs on real hardware.
And I blew up the worst case of my playroutine by 33 cycles just to get a quick fix in place. The fix is to write AD & $f0 before setting the gate bit, and then write the proper AD afterwards. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Quoting lft
Gaah, this bit me today. Song plays flawlessly in vice, but with ADSR bugs on real hardware....
Damn! But hurrah for catching, diagnosing, and finding a fix.
Quote:
The fix is to write AD & $f0 before setting the gate bit, and then write the proper AD afterwards.
That works unless A=R and both are >0. If A and R are both 1 then that solution will bug one time in 32 (or 1 time in 63 for A=R=2, etc). Safest just to set D equal to A (or R). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
what happened to that LFSR patch? :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Perfectionism!
Still haven't managed to get it cycle exact, then got distracted by REU, video emulation, Hi5 mode, NuCrunch, Marmaload.. |
| |
Danko
Registered: Nov 2002
Posts: 19 |
It seems not much progress regarding functionality came from here in reality...
I'm still reverting to JCH's old school knowledge when it comes to reliable hard restart. |
