Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user maak ! (Registered 2024-04-18) You are not logged in - nap
CSDb User Forums


Forums > C64 Composing > Another technical question about SID ADSR
2023-04-16 08:54
acrouzet

Registered: May 2020
Posts: 80
Another technical question about SID ADSR

Why didn't more composers back in the day do what GoatTracker 2 does with SID envelopes when setting the HR/Gate timer to 1 frame? That being using the register write order that results in the "snappy" hard restart when writing the HR ADSR 2 frames ahead, but instead of writing ADSR 2 frames ahead, writing 1 frame ahead.
This results in consistent note starts, while avoiding any gaps between notes (not even an envelope dip to 0).

I would think that many composers/programmers would desire having smooth and consistent transitions between notes, and yet, I haven't seen anybody doing this before GT2 other than the Hilpinen brothers. Does anyone know if there's a reason for this lack of usage, such as conserving CPU time or just liking the sound of "snappy" hard restart more? Perhaps people just didn't experiment much besides slightly modifying Hubbard's original HR technique.
 
... 7 posts hidden. Click here to view all posts....
 
2023-04-17 13:30
F7sus4

Registered: Apr 2013
Posts: 112
Quoting Groepaz
They just didnt know?

Exactly.

Quoting acrouzet
There seems to be a misconception that test bit is necessary for HR, and I wouldn't be surprised if people assumed that the audible silence caused by the test bit was "proof" of a successful HR.


To be honest, I happened to use the 1-frame HR without really knowing how a "proper" restart should be done from technical point of view (or even what test-bit was at that time). The logic behind it was assuming that 00 written to all SID registers including waveform, ADSR etc. would mute the previous sound before starting a new one with different ADSR values (all of that with multi-speed tunes). Obviously, 0000 as ADSR resulted in D↔R clash, so experimenting a bit with values lead me to conclusion that 0F00 ADSR with gate closed felt safe to land sounds properly when reopening the gate bit, and especially if only AD values were used, while SR remained 00. Why it happened to work was simply because of ignorance and trial-and-error shenanigans. Sorry if this doesn't answer the question directly, just wanted to share my perspective from the very first attempts in defMON (the first and only C64 editor I've ever used, which means no built-in preprogrammed HRs, and full manual mode via SID registers).
2023-04-17 14:20
trident

Registered: May 2002
Posts: 74
Another anecdote from an author of a music routine / editor from the mid 1990s: I disliked the soft and mushy sound in music routines such as Future Composer and Voice Tracker, and very much liked the snappy staccato-like sound in (at the time) more modern players.

Specifically, I liked the sound in Thomas Deterts music routine. So I looked into what was going on there and just cargo cult-copied that approach, which was to set ADSR to 0 1, 2, or 3 frames before the next note, and to set the control register to $9 (testbit + gate) at about the same time. This sounded great!

Back then there was little to no documentation of any of these tricks. At least none that I had any access to.

Much later I learned about that there was something called hard restart and all those intricacies of the ADSR mechanism. And it wasn't until Fjälldata 2023 (so some 25+ years later) I learned that the testbit was completely unnecessary.

So in this case, I guess the answer to the original question is a combination of "lack of knowledge" and "liking that snappy sound" :)
2023-04-17 17:42
ChristopherJam

Registered: Aug 2004
Posts: 1370
A few minor points on SID behaviour (I know env gen backwards, instrument history not so much).

Firstly, if a HR has set gate and attack decay to zero, then there is no second envelope bug unless you set a slow decay before gating a fast attack. Basically the envelope bug comes from any increase in rate of change other than an attack to decay transition.

Secondly, it takes up to 32759 cycles to recapture the rate counter - so one 19656 frame isn't necessarily going to be long enough. That said, I do know that a lot of musicians deliberately trigger a note when there's still 13k or so cycles remaining, in order to have a 6000 cycle blip of the first wave/frequency. It does make for quite a different sound to just starting the note immediately.

Acrouzet is correct about the test bit, it has no impact on envelope behaviour - the only thing it affects is the waveform generator.
2023-04-17 18:12
acrouzet

Registered: May 2020
Posts: 80
Quote: A few minor points on SID behaviour (I know env gen backwards, instrument history not so much).

Firstly, if a HR has set gate and attack decay to zero, then there is no second envelope bug unless you set a slow decay before gating a fast attack. Basically the envelope bug comes from any increase in rate of change other than an attack to decay transition.

Secondly, it takes up to 32759 cycles to recapture the rate counter - so one 19656 frame isn't necessarily going to be long enough. That said, I do know that a lot of musicians deliberately trigger a note when there's still 13k or so cycles remaining, in order to have a 6000 cycle blip of the first wave/frequency. It does make for quite a different sound to just starting the note immediately.

Acrouzet is correct about the test bit, it has no impact on envelope behaviour - the only thing it affects is the waveform generator.


What I mean by "second envelope bug" is the delay that occurs before the envelope drops to 0 when setting ADSR to $0F00 (or something similar) after gate off.

And yes, one frame isn't long enough to pass a bug, it takes approximately 1 2/3 frames. But if you start the bug on a frame before gate on, once you gate on, it should only take around 2/3 of a frame for attack to occur instead of the 1 2/3 frames it normally would.
2023-04-18 09:34
ChristopherJam

Registered: Aug 2004
Posts: 1370
Quoting acrouzet
What I mean by "second envelope bug" is the delay that occurs before the envelope drops to 0 when setting ADSR to $0F00 (or something similar) after gate off.


...in which case what is the 'first'? You're still only getting a single 32kcycle delay.

Quote:
And yes, one frame isn't long enough to pass a bug, it takes approximately 1 2/3 frames. But if you start the bug on a frame before gate on, once you gate on, it should only take around 2/3 of a frame for attack to occur instead of the 1 2/3 frames it normally would.


I think we're just paraphrasing each other at this point :)
2023-04-18 16:32
acrouzet

Registered: May 2020
Posts: 80
I think either I misspoke or I misinterpreted what you were saying there. Sorry about that!

Basically what I was talking about is this:
If we're transitioning between two notes, the first ADSR bug that occurs in HR happens at the end of note 1, where there's a delay between writing the HR ADSR value (and possible gate off) and the envelope dropping to 0. The second bug (which only occurs with "snappy" HR) happens at the start of note 2, where there's the delay between writing the next note's ADSR then gate on and the note's attack.
2023-04-19 08:50
ChristopherJam

Registered: Aug 2004
Posts: 1370
That's just the tail end of the first delay - there's no additional one.
2023-04-19 18:59
acrouzet

Registered: May 2020
Posts: 80
Quote: That's just the tail end of the first delay - there's no additional one.

I believe there are two distinct ADSR bugs/delays in "snappy" HR (basically HR with a register write order that writes ADSR before wave), though I may be wrong. This is how I understand it:

Let’s say we’re transitioning between two notes with ADSR $0099. The first note has already been gated off and is in the release phase.

1. The ADSR is set to $0F00. The comparison value is set to 8 while the counter is beyond that, still in the process of counting up to the previous comparison value of 976. Because the counter “missed” the new comparison value of 8, it must now count up to 32767 and wrap around to 0 before it reaches 8 and the envelope advances. The first ADSR bug begins. The envelope stays at a constant volume level during this.

2. The counter counts up to 32767 and wraps around. Once the counter finally reaches the comparison value of 8, it reverts to its “typical” behavior, counting in a loop between 0 and 8, causing the envelope to quickly drop to volume level 0. The first ADSR bug is complete.

3. The parameters of the new note begin to get set. The ADSR is set to $0099 before the new waveform with gate on is set, this means the envelope is still in the release phase. The comparison value is set to 976 and the counter begins to count up to that value. Then, the new waveform with gate on is set, the envelope switches to the attack phase, and the comparison value gets set to 8. However, once this happens, the counter has already passed 8. Because the counter “missed” the new comparison value of 8, it must now count up to 32767 and wrap around to 0 before it reaches 8 and the envelope advances. The second ADSR bug begins. The envelope stays at a constant volume level of 0 during this.

4. The counter counts up to 32767 and wraps around. Once the counter finally reaches the comparison value of 8, it reverts to its “typical” behavior, counting in a loop between 0 and 8, causing the envelope to quickly rise to volume level 255. The second ADSR bug is complete.
2023-04-19 19:32
ChristopherJam

Registered: Aug 2004
Posts: 1370
Ah!

Ok, my apologies, if people are spending two frames on an HR only to “waste” it at the actual start of the next note by setting a high decay before setting gate (and hence getting two entire frames of silence between the two notes - from ~1.6 frames into the HR to ~1.6 frames into the note), then you have indeed described exactly what happens and why. I stand corrected!
2023-04-19 19:49
acrouzet

Registered: May 2020
Posts: 80
Quote: Ah!

Ok, my apologies, if people are spending two frames on an HR only to “waste” it at the actual start of the next note by setting a high decay before setting gate (and hence getting two entire frames of silence between the two notes - from ~1.6 frames into the HR to ~1.6 frames into the note), then you have indeed described exactly what happens and why. I stand corrected!


Thanks for the clarification, was worried I had it all wrong for a sec!
Previous - 1 | 2 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
acrouzet/G★P
Guests online: 66
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 The Ghost  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.9)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Original Suppliers
1 Derbyshire Ram  (9.5)
2 Black Beard  (9.4)
3 hedning  (9.2)
4 Baracuda  (9.1)
5 Irata  (8.5)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.041 sec.