| |
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! |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:
1. am i right saying that multispeed means calling the playroutine multiple times per frame?
yes
Quote: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?
usually the player calls should be spread evenly across the full frame. however, some tunes also use different timing
Quote:
4. would loose $d012 polling be sufficient? (no stable interrupt)
yes, totally
|
| |
Higgie
Registered: Apr 2002
Posts: 127 |
hi Groepaz!
thanx for your fast reply!
is there any good way to find out if a tune is multispeed? if i just have a sid file from HVSC it seems a bit tough to me.
if i have a executable to examine it shouldn't be that hard, i guess.
atm i'm hunting through HVSC to find a tune that fits a certain 'demo part' that i'm working on.
(uuuh! i said demo. i'm a bit anxious calling it a demo. ;) ) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
if you only have the tune and no further info? good question :=) |
| |
Higgie
Registered: Apr 2002
Posts: 127 |
ok...
i found one strange example (atleast it appears strange to me) here: SCS*TRC Intro 07 (Big Scroll)
if i presume that the replayspeed of that sphere tune is correct in the intro, it is a 2x speed tune. but if i replay the sid in Sidplay2/w [win32 version (Jun 2 2005)] it gets replayed too fast. could this be a bug in the replay of sidplay?
if i save the tune from sidplay to .dat and use it as doublespeed in my program it sounds ok, as in the intro.
so, i guess i have to take care when only having a sid file as reference, not knowing how the tune was initially ought to be replayed. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
could be a bad rip, no idea :) |
| |
Stainless Steel
Registered: Mar 2003
Posts: 966 |
I believe if SidPlay shows "VBI" then the tune most likely is a singlespeed.
If it shows "CIA" then its likely to be a multispeed.
Just an idea, might not be that way in all cases. |
| |
Higgie
Registered: Apr 2002
Posts: 127 |
oh! that makes sense. i will check some of the tunes that i thought of being either one of both and compare with the vbl/cia info provided.
good idea. thanx joe! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
beware.... there exist quite a bunch of rips which appear to be singlespeed (and show vbl) but infact they arent, but the player is simply called 4 times in a row (resulting in bad sound quality, but atleast korrekt speed). |
| |
Higgie
Registered: Apr 2002
Posts: 127 |
buääähhh! :(
why must life be so hard!? ;)
if it is like you said, i'm lost. as checking for good/the right soundquality on an emulator is not that easy, i think. i don't know if i would recognize a missing sweep or beep or a slightly different drum sound. i'm not totally deaf but ....
i had a tune by randy (don't remember which one) which sounded ok in sidplay (and was showing vbl afair) but when i used it in my code (checking in winvice) there were some beeps added to the sound. and i couldn't figure out if it was the quality of sid emulation or some glitches in my code.
to sum it all up: it's not as trivial as i thought in the beginning.
btw: i need to check on the real hardware and that is why i need my 1541u NOW!!! :) |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
sidplay2 and vice use the same sid emulation engine so there shouldn`t be a difference. look for a bug in the play routine. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Quote: ok...
i found one strange example (atleast it appears strange to me) here: SCS*TRC Intro 07 (Big Scroll)
if i presume that the replayspeed of that sphere tune is correct in the intro, it is a 2x speed tune. but if i replay the sid in Sidplay2/w [win32 version (Jun 2 2005)] it gets replayed too fast. could this be a bug in the replay of sidplay?
if i save the tune from sidplay to .dat and use it as doublespeed in my program it sounds ok, as in the intro.
so, i guess i have to take care when only having a sid file as reference, not knowing how the tune was initially ought to be replayed.
if the tune sounds ok, after being exported to C64, it COULD be that the intro uses too much raster time, which slow the tune down. compare to when it it running alone.
Anyhow, HVSC will check the rip. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Not all CIA timed sids are multispeed. Some simply have a fixed speed, or are 60 hz.
To check if a tune is multispeed, go read the code at the start of the play address. If it is switching values for dc04/dc05, then it is multispeed.
The values for dc04/dc05 are:
1x - $4CC7
2x - $2663
3x - $1997
4x - $1331
5x - $0F5A
6x - $0CCB
8x - $0998
10x - $07AC
12x - $0665
16x - $04CB
So when you want to use a 4x tune with d012, you take 312 rasterlines / 4, and place the jsr to music at even spaced interval. Remember the first call is to the music player, then next 3 calls are to the speed routine.
Players usually have 1003(play) 1006 or 1009 (speedplay).
So
d012=0 jsr 1003
d012+4e jsr 1006
d012+4e+4e jst 1006
d012+4e+4e+4e jsr 1006
Or something like that
|
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
Just use the tune and see if it sounds like it should. You will notice a difference especially if you listen for drum sounds or arpeggios.
It really only matters that the music sounds good for your use. |
| |
Higgie
Registered: Apr 2002
Posts: 127 |
hey jan!
many thanx for your detailed explanation. now there is some hope again for me to use the tune i want with my code. :)
is there always a speed routine involved that i have to call or could it also be repetitive calls of the play routine?
if there is a rule of thumb it would be great to have such info added to the sid files in HVSC. would that be possible?
btw: i'm still open for exclusive tunes! hint!!! ;)
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
also not all multispeed tunes are originally played in even spaced intervals :) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Correct.
Anyhow, wilfred bos looked at that sidtune, and:
It plays at 115Hz while the demo plays it at 100Hz.
sid is now fixed. |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
For the majority of tunes the timing is not critical, I'd say. I know that GRG and DJB made some very timing dependent tunes, but if it's just a 2x or 4x tune it mostly doesn't matter really.
Also, not every player has a specific speedcall. For example Goattracker uses only $1003 for play. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Quote: hey jan!
many thanx for your detailed explanation. now there is some hope again for me to use the tune i want with my code. :)
is there always a speed routine involved that i have to call or could it also be repetitive calls of the play routine?
if there is a rule of thumb it would be great to have such info added to the sid files in HVSC. would that be possible?
btw: i'm still open for exclusive tunes! hint!!! ;)
Only tune i know that does repetitive call is rainbow dragon (jsr exxx, jsr exxx, same address) - thats not real multispeed.
In 99.8% cases, there is a speed routine you must call on 2nd and the rest of calls. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
@Rambones: Multispeed is multispeed, no matter where your jsr goes :).
Btw. i also experienced that some multispeed .sid-tunes sound different when i ran them in Vice, so i believe there is some difference to sidplay anyways. ..and yes, i know how to play a multispeed tune in Vice :). |
| |
Dane
Registered: May 2002
Posts: 423 |
And some multispeed tunes do not even have a second JSR for playback. Instead some idiot came up with the idea to just transfer zeropage values into D400. Totally lame. |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
HCL: the Resid tab in Sid settings in Vice will tell you what sampling method is in use. if its set to fast there`s no difference to Sidplay2. using cycle based sampling (interpolation or higher) makes some difference to sound reproduction quality but you wont get any new sounds as in Higgie's example;) |
| |
Hate Bush
Registered: Jul 2002
Posts: 465 |
i could be wrong, but judging from my amateurish experience - multis made in goattracker are all rather timing-sensitive. one scanline too early/late and the note triggering will suffer. so beware. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Quote: @Rambones: Multispeed is multispeed, no matter where your jsr goes :).
Btw. i also experienced that some multispeed .sid-tunes sound different when i ran them in Vice, so i believe there is some difference to sidplay anyways. ..and yes, i know how to play a multispeed tune in Vice :).
HCL, if you have interpolation turned on in VICE, it will sound different. i guess thats it. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Quote: i could be wrong, but judging from my amateurish experience - multis made in goattracker are all rather timing-sensitive. one scanline too early/late and the note triggering will suffer. so beware.
Because goat dont have seperate speed call that only update specific d4xx.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
are you trying to say that it would be less criticial when a different method of updating the sid would be used?
*slap* |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
In GT multispeed, tempo should be a multiple of the multispeed-factor, and same with the gateoff timers. If that's ensured, theoretically the sensitive playcalls containing triggering related stuff should happen on the same rasterline (same as singlespeed). |
| |
HCL
Registered: Feb 2003
Posts: 728 |
For the record.. I'm always using sid settings "reSID" and sample method "fast", and that's when i have encountered these differences in sound.
..and btw. there are far too many sound settings in Vice. We don't have Pentium90MHz anymore so just throw away all those low-end emulation settings plz!!
I second Randall there also, especially GoatTracker multispeeds seems to have these problems. I didn't really dig too deep into this, but i think i found out that when turning off the screen (d011=0) i got somewhat better sound. If that's the case, it must be the badlines that cause the timing problem, and i haven't experienced such sensitiveness with other players. My 5 cents. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: For the record.. I'm always using sid settings "reSID" and sample method "fast", and that's when i have encountered these differences in sound.
..and btw. there are far too many sound settings in Vice. We don't have Pentium90MHz anymore so just throw away all those low-end emulation settings plz!!
I second Randall there also, especially GoatTracker multispeeds seems to have these problems. I didn't really dig too deep into this, but i think i found out that when turning off the screen (d011=0) i got somewhat better sound. If that's the case, it must be the badlines that cause the timing problem, and i haven't experienced such sensitiveness with other players. My 5 cents.
I agree with both Randall and HCL regarding GoatTracker sounds. The 4x tune used in the intro for The Wild Bunch had much better snare drums in the original from Linus than in the final production. It was very sensitive to where we STA'd the SID-registers. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
The problem in GT playroutine in both multi & singlespeed is that it does (buffered mode):
- exec channel 1
- write regs 1
- exec channel 2
- write regs 2
- exec channel 3
- write regs 3
while better would be to write all regs in succession. Bad lines indeed make a difference - it takes a varying amount of time to execute the channel code. If you don't mind losing some zeropage, use the zeropage ghostregs-mode, and you can then write the ghost registers to SID yourself.
|
| |
dalezy
Registered: Apr 2002
Posts: 476 |
i never really understood the multispeed-player-example that came with goattracker, at least not to the extend that the output made sense the way it was intended to sound like .. my tune plattenbauknecht for example was a hard beast to get played right using that one code-example, is there a surefire way to make tunes that were done in gt to sound like they should once they're loaded in a player routine? iirc, i had to multiply that one call-routine, that's all i understood, but maybe i was doing it all wrong. =) |
| |
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. |
| |
Jammer
Registered: Nov 2002
Posts: 1336 |
@HCL >> sure, it's still not 100% what was prooved by my 'galaxy bounce remix' - it sounds apparently different on real chip. |
