| |
Higgie
Registered: Apr 2002
Posts: 127 |
How to deal with multispeed tunes?
hello you coders!
i'm currently doing my first (except for some bullshit from back in the late 80s/early 90s) steps in coding and while checking out some tunes from HVSC as background music i stumbled across some 'multispeed' tunes. some questions came up my mind...
1. am i right saying that multispeed means calling the playroutine multiple times per frame?
2. is it just calling the routine at any time, just calling it often enough in every frame?
3. or does replaying multispeed tunes require a special timing?
4. would loose $d012 polling be sufficient? (no stable interrupt)
i have to admit that i haven't tried out yet and wanted to get the theoretical background before i started off into the (possibly) wrong direction.
thanx in advance! |
|
... 31 posts hidden. Click here to view all posts....
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
I'd say: rewrite the player. It's a bug that should be corrected. |
| |
Hein
Registered: Apr 2004
Posts: 954 |
Does this also mean that the reSID emulation (used in GT-editor) is not correct? Or, on what line does it start playing?
I've encountered this problem as well, playing a tune in VICE compared to the GT editor is sometimes different (depending on the sound settings), even be it a one speed tune. |
| |
Conrad
Registered: Nov 2006
Posts: 849 |
According to the current version of GT player code, each voice is updated in the following order (if buffer SID-writes is ON):
1.) Attack/Decay
2.) Sustain/Release
3.) Pulse Lo
4.) Pulse Hi
5.) Frequency Lo
6.) Frequency Hi
7.) WAVEFORM + Gate ... Gate/Test bits are set LAST
The other thing is, you can't really tell when the waveform/gate register is set because of how much raster-time the player uses, because Goat-Tracker seems to re-compile the player code to match what's necessary for the music (e.g. requests portamento, vibrato, funk tempo, etc) so the code size and CPU time is flexible to how detailed your tune is.
Maybe on the safe see you could modify the player to write SID data to temporary memory and then use the content of that memory to write to SID registers at another raster-time position, bearing in mind that it doesn't go over a bad line. I had this problem with 2SID tune, and that's how I got around it. Again, this is only towards 1x tunes mainly. |
| |
Jammer
Registered: Nov 2002
Posts: 1336 |
playing in vice/gt doesn't guarantee all. i always test final in hoxs64 - sometimes results surprise me ;) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: According to the current version of GT player code, each voice is updated in the following order (if buffer SID-writes is ON):
1.) Attack/Decay
2.) Sustain/Release
3.) Pulse Lo
4.) Pulse Hi
5.) Frequency Lo
6.) Frequency Hi
7.) WAVEFORM + Gate ... Gate/Test bits are set LAST
The other thing is, you can't really tell when the waveform/gate register is set because of how much raster-time the player uses, because Goat-Tracker seems to re-compile the player code to match what's necessary for the music (e.g. requests portamento, vibrato, funk tempo, etc) so the code size and CPU time is flexible to how detailed your tune is.
Maybe on the safe see you could modify the player to write SID data to temporary memory and then use the content of that memory to write to SID registers at another raster-time position, bearing in mind that it doesn't go over a bad line. I had this problem with 2SID tune, and that's how I got around it. Again, this is only towards 1x tunes mainly.
"Maybe on the safe see you could modify the player to write SID data to temporary memory and then use the content of that memory to write to SID registers at another raster-time position".
This is exactly what buffered SID-writes do together with ghost registers... |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
I could someday make it possible for ghostregs to be in any memory location.
Meanwhile, remember the existence of the alt-writeorder - waveform first - player, which is activated by having an HR ADSR value of Fxxx (like F800 or so.) It is theoretically less susceptible to badlines, but may change other characteristics of your instruments' envelope.
|
| |
Soren
Registered: Dec 2001
Posts: 547 |
Hmm... if wave+gate is not a part of the buffer routine.. why bother then? :-)
What I have heard is that the best order is:
(1)sustain/release
(2)attack/decay
(3)wave/gate
Not sure if the order of the other registers is important.
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: I could someday make it possible for ghostregs to be in any memory location.
Meanwhile, remember the existence of the alt-writeorder - waveform first - player, which is activated by having an HR ADSR value of Fxxx (like F800 or so.) It is theoretically less susceptible to badlines, but may change other characteristics of your instruments' envelope.
For The Wild Bunch we altered the ghose-reg player to push the register contents to stack instead. Thus in the raster code we simply did PLA+STA sidreg. Care had to be taken with reversed push-order and reversed speed-play order for the 4x-tune ofcourse. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
I committed modified sid write order to GT2 svn (http://sourceforge.net/projects/goattracker2), now it's
pulse lo - pulse hi - sr - ad - freq lo - freq hi - wave
which is same as JCH newplayer 21, apart from pulse & freq being swapped, but that has no difference related to note triggering.
According to very preliminary testing this results in better stability against badlines. However, release 1 will certainly bug randomly after this change, so the alt-write player is highly recommended if you need it.
This is yet experimental and I may rollback the change after more testing. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
@Jammer: Heh.. as if hoxs64 gave you the right answer :). The only true way is of course to run it on the real thing, and you need 4-5 of em with different SID-properties also i suppose :P. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
