MB SID V2 discussion?

[ganchan]

1. 6581 R1 '82 '83 '84

2. 6581 R2 '83 '84

3. 6581 R3 '85

4. 6581 R4 '86

5. 6581 R4AR '90 corrected by Razmo

6. 6582A '92 updated by Razmo

7. 8580R5 '87 to 92

something like this?

[Wilba]

Sorry to interrupt the drool fest, but reading Razmo's ideas about eliminating the envelope bug had me thinking... and an idea popped into my head.

If it's only the decay and release not being zero that causes the bug, can you setup the envelope on the SID to have zero decay and release, and max sustain, and then let the PIC lower the sustain value to emulate the decay and release phases? I'm already aware that you can't raise the sustain value while the oscillator is gated on, but you can lower it...  i.e. you would set the sustain value to max, wait for the attack phase to finish, then lower sustain down to the "real" sustain value, then when the release phase should start, drop sustain down to zero. This would be much like the ENV2->Vol solution, except controlling sustain after the oscillator's attack phase is finished. From memory, I think my experiments with dropping the sustain value didn't suffer the clicking that dropping the volume register produces... plus this idea would have the added advantage of being per oscillator. (You would still need the "no gate off" option, and need it a little smarter, so it does gate off just before the gate on to trigger a new attack phase).

I'm not able to try some experiments with a wavetable controlling sustain right now, (i.e. I would have preferred to prove the theory before mentioning the idea)... so please excuse me for rambling on if it turns out not to be a feasable idea.

[Razmo]

Hi!

Ganchan: Yes! something like that though my revisions have other datings:

6581 R1/R2 (83,84) I've still to find an 82 SID  :'(

6581 R3 (85,86)

6581 R4 (86)

6581 R4AR (90)

6582A (92)

8580R5 (88,89,89,90,91,91,92)

Can see that I'm not the only C64 canibalizer!  :-X

Wilba: It's absolutely worth a try if the resetting I recently came up with does not work, in fact that may be the second best way I think. The best solution would be that the envelope works like it should, and if the resetting of Decay and Release works, then that should be it. But I like the idear of the decay control... Thorsten could try it out I guess. You are not rambling by the way! any possible solution should be tried out!!!  :D

Regards, Jess.

[TK.]

I've tried the method described by Wilba some time ago, it works, but as already mentioned, only for an emulated decay or release phase, not for an attack phase, because once the sustain is increased, the envelope drops to 0. This leads to the problem, that for a correct envelope behaviour (e.g. gate cleared while decay phase not finished should lead to a longer release phase) the SID EG has to be emulated. This is so much effort, which I don't really want to spend.

It's better to do this with a wavetable or an envelope. And with MBSID V2, you will get independent wavetables, more envelopes and a trigger matrix. You could use wavetables or envelopes for this purpose, and trigger it on Note Offs (works for all voices, or for each voice seperately)

Some news about Jess' proposal for reseting the envelope properly: unfortunately it doesn't work, the delay still exists.

I did some research in the source code of reSID (one of the most accurate SID emulators) and found following interesting hint:

  // Check for ADSR delay bug.
  // If the rate counter comparison value is set below the current value of the
  // rate counter, the counter will continue counting up until it wraps around
  // to zero at 2^15 = 0x8000, and then count rate_period - 1 before the
  // envelope can finally be stepped.
[/code]
So, we have a 15bit counter which is incremented on each SID clock cycle. 
Once the counter has reached the compare value (in the reSID source code, it's called rate_counter_period, it depends on the selected rate), the counter is reset, and the EG is stepped forward.
Now the bug: once the EG changes the state (e.g. from sustain to release), the counter compare value will change, but the rate counter won't be reset. This results into an unpredictable delay (effect #1) until the EG will be stepped again.
And if the compare value is lower than the one before, we have to wait for a counter overrun first, then the counter runs from 0 to the new compare value, thereafter the EG will be stepped (effect #2)
So, in worst case, we get a delay of 32767 cycles, makes ca. 32.8 mS @ 1 MHz, and this delay cannot be controlled by software!
Currently I'm doing some experiments with the reset input of the SID again. I must say, that I haven't understand all effects yet I'm seeing on my scope (I've some assumptions and a possible improvement of the SID reset feature, but better not to write them down before they are proven ;-)
Best Regards, Thorsten.

[TK.]

Ok, after a lot of experiments I can only say: there is no cure for the delay bug. Even a hardware reset doesn't reset the rate counter, and depending on the EG state the amplitude is at the wrong level for ca. 32 mS

Best Regards, Thorsten.

[stryd_one]

Thanks for trying TK!!

You're very good to us :)

[Wilba]

If a reset from the reset pin doesn't reset these counters, would it be possible to do a reset by temporarily cutting the Vcc (5v) supply, but leaving the Vdd (9v/12v) supply on? I know this is a drastic measure that would involve hardware changes, but it seems like if you're considering a "hardware reset" by toggling the reset pin and having to send all the registers every gate on, then you're willing to consider something as crazy as this. (I am at least, but I'd prefer a second opinion before pulling the 5v supply from my precious SIDs!)

Maybe just turning off the Vcc for a millisecond will not cause an audible pop, since the supply to the audio section is uninterrupted. Just a theory based on my limited knowledge of SID internals :-) I know it's not a very elegant solution, and one that would involve wiring a transistor to a spare shift register output perhaps... but maybe some people would think this worth the effort...

[DrBunsen]

Surely these bugs are one of the things that give the SID it's distinctive character?  I mean, the TB-303 had "bugs" too :D:D

[Razmo]

Hi Thorsten!

That explains EVERYTHING! ... I understand the bug fully now, and it's quite hard to get around it. What has been revealed actually means that the delay bug (rate_counter wrap) may be present at every phase transition of the EG, UNLESS the EG rates stay the same (in ms) from one transition to the next (i.e. Decay is the same as the release rate in ms). It's worth noting that the attack rates differ VERY MUCH if you look at the table in the SID datasheets. In fact only two settings is shared by all rate registers, wich is 24ms and 3s! ... this should make the "famous" 0,0,15,0 setting of the ADSR to also be bugged (attack is 2ms, decay/release is 6ms!), but somehow this is NOT the case... I believe the reason for this is that when the EG is in either SUSTAIN or END OF RELEASE mode, the rate_counter is ZERO! and held there untill the GATE bit is toggled either off or on (in fact a text by yannes clearly states that the clocking of the EG is STOPPED while in sustain mode! I bet this is the same with END OF RELEASE), and thus the rate_counter will NOT wrap when the attack phase is again triggered since the rate_counter will begin counting again from ZERO preventing a counter wrap. The fast release rate of 6ms will insure that the EG has reached it's end before you can press another key on the keyboard if a key is released before retriggering a note, and if played legato, the counter will be at ZERO because of the sustain phase... it makes total sence!

I don't know yet if you can do any tricks to work around this, but I'll be thinking about this a lot... I just don't believe there is any way around it.

It IS possible though, to control the LOWERING of the sustain register manually from a PIC EG, controlling the volume this way, and changing the decay rate on this technique will make some sort of "interpolation lag" when the decay rate is raised as it then tracks the sustain level more slowly. Making a release-phase would be a bit of work though... I do not feel that the release phase is as important as the decay phase though, and Id like to see how well i works if you control the sustain level from an EG this way.

Also knowing how the bug works now, makes it easier to program the envelope since some settings make the bug more pronounced.

Regards, Jess.

[Razmo]

As I currently see it, there is NO WAY around this bug, without waiting for the envelopes to reach the end. and to insure this you will have to:

1. Wait for MIDI note on and then:

2. Clear ADSR registers.

3. Wait for 32ms.

4. Trigger the note.

This should work, but will introduce a 32ms. latency when using this method. It is anyway a crucial option for the MBSID, and the latency can be compensated for in the sequencer. It's feel a bit sluggish when you play live, but if you could just switch the 32ms delay on/off fast, then It will not be that bad.

Jess.

[TK.]

Hi Jess,

I'm sure that this sequence would work.

I think the best is to replace the SID reset feature by a function which sets ADSR=0 immediately on a gate set request. This would allow to use the Delay parameter of MBSID to shift the gate trigger

Best Regards, Thorsten.

[Razmo]

Hi Thorsten..

Yes... I don't think that resetting the SID is a good idear when thinking about it. Also, I'm giving up on trying to work around that EG bug... It seems impossibe... I'd go for the simple delay method of 33ms. instead... maybe this can be incorporated into the DELAY parameter that is already present for every oscillator? Will the delay parameter be able to deliver a setting that delay the triggering for just 33ms?

If I understand you correctly, you want to reset the ADSR to 0 at note-on exactly, and then wait the time you set in the DELAY parameter (for each osc individually) and then trigger the sound right?

This way I find to be the best solution when no work around can be done. Also, I've learned so much about the bug now, that I can utilize the ADSR more efficiently because some settings work better than others.

I still though feel that you should implement the ability to route an envelope to the sustain parameter, as this would make a VERY useful tool when it comes to drumsound programming. I know that it will sacrifice the attack and release phase, but we do not need that with drumsounds, we need only a snappy attack and a controllable decay. It's just a matter of setting the ADSR to 0,0,15,0 and routing an EG to the sustain parameter. I know that you would have to make three dedicated EGs for this to work, but I really think it's worth the trouble.

Regards, Jess.

[Razmo]

And in addition to my last post:

The three exstra EGs need not really be EGs... They can be simple ramps having only two parameters: Rate and Curve. If you have trouble squeezing more parameters into teh current V1, you could in fact use the parameters already there for the osc. ADSR. Then you need only three flag bits for it to work:

when a flag is set you simply set the ADSR to 0,0,15,0 when a note is triggered. You can then use the ADSR parameters in this fashion:

ATK = ? (not needed really)

DCY = Ramp Decay Rate

SUS = Ramp Sustain Level

REL = Ramp Decay Curve

I know that it will require a bit of effort on your behalf to make three ramp EGs, but I really think it would be handy if you did this feature. Drumsounds would be awesome using this, and also bass sounds and lead sounds will be much better with this feature. Those sounds often do not require an attack or release phase.

Regards, Jess.

[TK.]

Wilba: in the meantime I know, that even the drastic measure to cut off the 5V supply for a short moment doesn't really help. The biggest problem is, that a write to the ADSR registers cannot be synchronized with the envelope rate counter.

Jess: I did a lot of checks with the Delay parameter in conjunction with a controlled ADSR reset

The last algorithm I tried was:

  o on Note On clear the gate and clear ADSR, start the delay counter

  o after the delay has passed (e.g. 33 mS or more), refresh ADS, R remains 0, set gate

  o before the gate is cleared, refresh R as well

In general this allows to reset the EG, but the delay bug still can happen. Not so frequently anymore, but sometimes. And I've also an explanation for this: if the EG is still in decay phase (sustain level not reached), and we switch into the release phase by clearing the gate bit, the new compare value for the rate counter can be lower than the compare value used during decay phase -> a counter overrun will happen -> 33 mS additional delay

In the meantime I think it's easier to find good working ADSR settings than using a ADSR reset workaround which doesn't solve the problem under all conditions, and has some additional unwanted side effects.

To the additional EGs: as mentioned above, this will be considered for the MBSID V2 engine. For MBSID V1 the integration is not possible due to RAM limitations (3 EGs require at least 9 bytes, SID engine registers must be located within 0x100-0x1ff, and this address space is full, a major-rewrite of the V1 engine would cost me more effort than programming the V2 subsystems)

However, with MBSID V1 you can already modulate the sustain parameter with the wavetable sequencer - it allows you to generate any waveform with up to 32 steps :)

Sustain is CC#57/58/59 (all voices seperately) or CC#56 (all voices together)

Best Regards, Thorsten.

[Razmo]

Hi Thorsten...

That bloody EG!  >:( ...It just keep on giving headaches just because of a counter that does not get reset... man!  ::)

I don't understand why you would need 9 extra bytes for the 3 ramp EGs if you just reuse the ADSR registers when the ramp feature has been switched on? The SIDs 3 ADSR envelopes need to be set to 0,0,-,0 for this feature to work, you don't need to be able to set the ADSR registers from the users side anymore when the ramp feature is on!?... Is it because you need extra bytes for counters or something? surely they can reside in another space in memory than 100-1ff? ... well, I don't know the nature of your engine, just wondering  :)

Regards, Jess.

[TK.]

I've already considered the re-use of the ADSR registers, 3 bytes are required for a 16bit envelope rate counter and a mode variable which holds the ENV state.

There are also other things which prevent me from implementing this into MBSID V1, one thing is, that the ADSR settings are directly written into the 4bit SID register shadow space, there is no register which holds the 7bit value received via CC/SysEx. So, not only resolution is a problem, but also the refresh of SID registers

Please believe me: it's more effort than implementing a new engine from scratch, therefore I don't want to spend so much time on the MBSID V1 engine anymore.

Currently the wavetable sequencer can be used, so it's not impossible to modulate the sustain level, it's just not so comfortable. You can use the wavetable rate as a "decay rate"

And before I'm starting with MBSID V2, I want to create the SpeakJet synth and MBSEQ V3... just to explain, why I don't start immediately ;-)

Best Regards, Thorsten.

[stryd_one]

MBSEQ V3?  ;D

You're just going to drop that bomb and tell me nothing, leaving me in suspense, aren't you? ;) heheheh

[Jaicen]

MBSEQ V3 is exciting? What about the SpeakJet synth?? How exciting is that! GIVE ME MORE DETAILS!!!!!! ;D

[TK.]

http://www.midibox.org/midibox_sj/speakjet_test.mp3

Best Regards, Thorsten.

[stryd_one]

TK you're priceless mate ;)

[Wisefire]

dude thats fscking awesome.. where can i buy one :P J/K ill build it like all the others..

[Wilba]

Jess: I did a lot of checks with the Delay parameter in conjunction with a controlled ADSR reset

The last algorithm I tried was:

  o on Note On clear the gate and clear ADSR, start the delay counter

  o after the delay has passed (e.g. 33 mS or more), refresh ADS, R remains 0, set gate

  o before the gate is cleared, refresh R as well

In general this allows to reset the EG, but the delay bug still can happen. Not so frequently anymore, but sometimes. And I've also an explanation for this: if the EG is still in decay phase (sustain level not reached), and we switch into the release phase by clearing the gate bit, the new compare value for the rate counter can be lower than the compare value used during decay phase -> a counter overrun will happen -> 33 mS additional delay

I've observed that raising the sustain will cause a decay at a rate relative to the decay value. Can this be exploited somehow? Probably not, I but thought I'd mention it anyway.

If the delay is just totally unavoidable, is it possible to reduce it as much as possible by speeding up the clock to the SID during this period?

[ganchan]

http://www.midibox.org/midibox_sj/speakjet_test.mp3

Best Regards, Thorsten.

i don't speak so much on this forum but.. WTF! A DIY vocoder by MIDIBOX.. amazing :)

I'm just at this point with my SID  :-X (Arranging Parts on Vectorboard)

TK and Razmo, i've read all this thread with wikipedia open in firefox tab next to te forum to understand all what you are speaking about. Isnt' a good solution make some preset switch for env, trought the value that not are affected by the env bug? If i've understend in some case it work well, in other not.. or i'm wrong?

[stryd_one]

That's no vocoder!

A vocoder sounds similar, but is an effect where, for example, a human vocal is mixed* with a synthesised tone.

That MP3 is synthesised speech - no human voice involved :)

*Edit: I don't mean mixed as in VCA mixed, but you can google it and find out how it's done ;)

[TK.]

Hi Wilba,

I've observed that raising the sustain will cause a decay at a rate relative to the decay value. Can this be exploited somehow? Probably not, I but thought I'd mention it anyway.

I've already tried this method (e.g. after gate off: D/S=0, S=15, wait 33 mS), it doesn't help, there is still some randomness. Only adding an additional delay of 33 mS between D/S=0 and S=15 helps, but 66 mS latency is not acceptable IMHO

If the delay is just totally unavoidable, is it possible to reduce it as much as possible by speeding up the clock to the SID during this period?

Funny, I also considered this - but this would lead to compatibility problems (not every SID can be clocked at higher rates), and an uncontrolable delay would still exist.

Best Regards, Thorsten.