Workaround for the SID's envelope bug

[Windfisch]

The SID chips suffer from the ADSR bug which can cause up to 37 milliseconds of note-on-latency, which can render the instrument rhythmically useless with certain ADSR configurations

How the SID bug is caused is described in reSID's source code (clock() function):

• SID keeps a counter cnt which it increments on every clock and compares it against the A/D/R rate divider. If equal (not "greater-or-equal), it resets cnt and advances the envelope by one step.
• If the currently active A/D/R divider is changed, cnt is not updated. If the active divider is changed to something less than cnt, cnt will be incremented until it hits the upper end (0x8000) and overflows. This takes up to 37ms.
• The envelope does not move during that time. Note-ons get delayed.

Describe the solution you'd like We control the SID's clock using an AVR pin. If we count AVR cycles, we could know (or at the very least, closely approximate) the current counter value. With this knowledge, we can avoid setting "unsafe" values for the rate divider. Instead, we could set the rate to the smallest value that does not trigger the bug, wait for it to be reset to zero again, and set the rate to our desired value then.

Describe alternatives you've considered

• We can ignore the problem. The instrument remains usable with certain "safe" ADSR values (essentially A >= D >= R), or for slowly attacking drones (where a 37ms delay isn't that noticeable anyway).
• We can implement hard-restart. This would introduce a constant ~40-60ms delay on all notes, but reduce jitter to 0. Together with latency compensation from the MIDI master, this would make the TherapSID usable as instrument attached to a sequencer.
• We can set release to 0 after a voice has released. This only fixes the problem for voices which have been fully become silent again.

[Sequence7]

I can only comment as someone who uses a real c64 but if you can avoid the bug and doing hard restarts by micro adjustments to the timing on the atmega that sounds like a genius solution. The midibox mb6582 has a toggle and claims 30ms delay.

On most the native sid trackers it is just inbuilt. On defmon you have to manually send hard restarts on notes that are having issues. I have an armsid and a real 6581 in therapsid and it is nice not having to worry about the bug at all on the armsid. On the 6581 if I take care to when I send my note offs. I can safely sequence the therapsid very fast but not everyone is going to have the patience or hardware sequencer capable of that.

Let's hope your timing idea works. Worst case scenario a toggle in the webapp and a cc for each voice to send a hard restart?

[Windfisch]

The issue with trackers is that they can look into the future. Because they know what notes will be coming in the next 30ish ms, they can -- 30ms in advance -- prepare the hard restart so the voice is ready for the note when it comes.

Midibox and we cannot do this here. Probably because of this, midibox introduces a 30ms delay for all notes. Which is much easier to handle if your sequencer has latency compensation than the (seemingly) random delay without hard restart.

Manually hard-restarting using a CC would not work for me, because I want to use the TherapSID together with the MegaFM's sequencer. But having a toggle in the webapp for "raw" mode and "always hard restart: introduces 30ish ms delay" is definitely doable! :)

[thomasj]

The idea with counting clock cycles sounds interesting! A constant delay would also not work when playing the unit live from a MIDI keyboard (which happens to be my go-to use case). Having a setting in the web app can be a bit dangerous as it is easy to forget it has been done when not using the unit for a longer period. So would prefer if it was possible to have a permanent (but good) solution.