| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Fading out music
OK, so my demo has reached the end and I want to fade out the music.
I had some very foggy memories of just ramping down $d418 from $0f to $00 like this:
jsr $1003 // music play
lda fadeoutval // $0f --> $00
sta $d418
But did not sound good when I tried it, lots of strange sparkling sounds.
So I said, screw the fadeout, I just want to stop playing the music. Then I just stopped calling the music play routine in my IRQ and did a lda #$00/sta $d418 (set volume to zero) to stop any playing sounds. But that did not work either, the last played note kind of went on playing for a while sounding very strange...
|
|
| |
Conrad
Registered: Nov 2006
Posts: 849 |
Quote:I just stopped calling the music play routine in my IRQ and did a lda #$00/sta $d418 (set volume to zero) to stop any playing sounds. But that did not work either, the last played note kind of went on playing for a while sounding very strange...
When are you actually executing lda#$00, sta$d418 ? If you're doing it BEFORE the last call of $1003 then that affect would occur, otherwise there is something wrong with your sid chip.
As the the clicking noises, the music player itself somewhere has code which updates $d418 automatically. In most players it has code as such:
ORA #$0F
STA $D418
Since the player needs to OR the volume with any filters set. The best way would be to modify the value set in the player instead. So for example, if that code was such at a location:...
.... player data ...etc....
$1187 ORA #$0F
$1189 STA $D418
.... more player data...
... then you put: LDA #$<volume>, STA $1188 instead.
Mind all players are coded differently, so best thing is to look at the player code first. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
To stop the music with a sharp cut simply set #$00 in $d418 and never call $1003 anymore. Calling $1003 will undoubtedly set $d418 to something else again.
To fade out properly you have to hack the music routine. Disassemble around $1003 and locate the $d418-write and apply custom fade code there. A simple patch could f.e. be to change the $d418 write to a $c000 write, then directly after the call to $1003 you read the $c000 value, apply fade-limits and write the value to $d418 yourself. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
It's better to clear the gate bits after the music instead of setting $D418 to 0. If you start another music, a set gate bit might cause the first notes played on each channel to stay silent. |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
john: you should have told that to tts, he always fucked it up... :P |
| |
Dizzy Devil
Registered: Feb 2003
Posts: 11 |
There's another method which I found in Dr. Zoom's D4 adventure engine: he disables I/O before calling the player routine, and copies the register values from RAM to the SID afterwards, using another value for d418 when fading.
I guess he did that because
a) this way you don't have to hack the player
b) normally, if the player routine changes the volume while you're fading, you get an ugly jump in the volume.
Of course, there's a drawback - if a register is changed several times by the player routine, only the last value remains in ram and is written to the SID. Some musics may not play correctly using this fading method; but it's worked well with the musics I've used in the adventure system so far. |
| |
Conrad
Registered: Nov 2006
Posts: 849 |
Heh. That seems a weird way to do it, yet I suppose it would be easier to select what volume you want. I guess also it would keep a record of each sid register's state after the last time the music was played - could be useful for some display chart. |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
Finding the place where the music driver writes to d418, and having it write it to some other place in memory, will let you modify the thing real easy.
lda bufferedD418 ; Nicked from the music driver
and #$f0 ; Keep the filter settings intact.
ora myVolume
sta $d418
The gate-bit approach (for stopping the tune) is so-so. If you want that to work perfectly you'd also have to change the release nibble of the ADSR in all three voices, or you might have some voices hang longer than others.
Buffering the whole range of SID registers by masking out the I/O bank, is a bad idea. Mainly because this can change the write order of the SID registers, which are important for some drivers to sound as intended. Circumventing this problem is possible, ofcourse, by mimicing the write order of the driver (down to the last cycle). |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
What about stopping tune by writing zero to all channels' frequencies and not calling the player anymore?
|
| |
Danzig
Registered: Jun 2002
Posts: 440 |
What about stopping tune by jmp$fce2? :D |
| |
Dizzy Devil
Registered: Feb 2003
Posts: 11 |
Quoting Laxity Buffering the whole range of SID registers by masking out the I/O bank, is a bad idea. Mainly because this can change the write order of the SID registers, which are important for some drivers to sound as intended.
That's right, but how common are drivers which write sid registers multiple times, or rely on a certain order? So far, we didn't have problems with the tunes used in the adventure engine.
The other methods described here require that you examine the tune, and either hack the driver or adapt your code to the driver, which isn't practical for a tool which lets you load any $1000/1003 tune.
Of course, I could just count $d418 down to 0 in a loop, but that would sound odd if the current volume at the start of fading is lower than 15, or if the music driver changes the volume during the fade.
Do you think using the ram-buffering method causes any effects which are audible for a longer time after fading a music in? (When you save the game in the adventure engine, the music is faded out, and faded in again after the save)
|
... 6 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
