| |
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...
|
|
... 6 posts hidden. Click here to view all posts....
|
| |
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)
|
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Guys, no need to argue too much, at least I don't think there is a generic solution anyway. And if, it's prolly not practical :) Dizzy, I made a music-player with debugging features which is also switching IO off. Try "Cyberdragon / Reed" for a tune that fails badly with this method - and be happy that it works for most tunes ;) Shadow, I suggest to examine the playercode, find the volume-variable and work with this one. |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
Quoting Dizzy DevilDo 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)
No.. When you switch back to normal playback (not using the SID I/O buffer), the inconsistency will be gone instantaneously.
Quote: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.
I agree. For a tool it's not practical at all. Also the buffering method would probably prove more robust for a tool than analysing and replacing d418 writes, if you disregard the tradeoffs mentioned.
I must admit that I didn't consider that one would only buffer the SID I/O while fading - that ofcouse means that the inconsistency would last for a quite short time indeed. /me slaps me. :) |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
Quote: What about stopping tune by writing zero to all channels' frequencies and not calling the player anymore?
Well... someone isn't thinking today.. and it's not you.
(Hey.. don't point that finger at me, mister!) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
*yawn*
peeps, it takes no time to find the d418 write in a player, just H 1000 2000 18 d4. then analyze the code modify it, or just write down on a paper the location of the volume variable, then use it from code. if you dont want bugs and volume artefacts due to your fading then do this way. secondly you might ask the author of the music, many players have own fade routines.
really nothing spectacular or hard here, anyone can do it with about 1-2 week of assembly learning. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:
anyone can do it with about 1-2 week of assembly learning.
tell it to tts! =D |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
Quote: *yawn*
peeps, it takes no time to find the d418 write in a player, just H 1000 2000 18 d4. then analyze the code modify it, or just write down on a paper the location of the volume variable, then use it from code. if you dont want bugs and volume artefacts due to your fading then do this way. secondly you might ask the author of the music, many players have own fade routines.
really nothing spectacular or hard here, anyone can do it with about 1-2 week of assembly learning.
Great form dude.! |
| Previous - 1 | 2 - Next |
