| |
Sasq
Registered: Apr 2004
Posts: 156 |
SID streaming
I am experimenting with recording SID writes from Vice and replaying them as a stream, and so the question on how to compress the stream comes up.
The naive way is to record value (8bits), sid offset (5 bits) and cycle delta (~16bits). This can then be compressed in various ways.
But I am more interested in the assumptions you can make because of how the SID-chip works. With writes can you reorder for instance? Is there in fact a safe fixed order you can used for single speed songs?
Also is there writes you can skip which have no effect? |
|
... 10 posts hidden. Click here to view all posts....
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
If you get your data from some external high-speed source like those you mention, then go for very light compression or even just the raw writes. Stay off unaligned bit coding if you can.
The cycle delta does not need to be 16 bits. For long deltas you can just stack multiple dummy ones. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
for streaming i'd just send a 16bit timer value plus register+value. not sure if i'd go through the trouble of trying to make it work with (any kind of) samples though - that seems kindof hard for the generic case. when streaming via net or even reading from sd card, i somehow doubt you can keep up with the timing requirements (with those modern sample player things almost all CPU is burned by the sample player already) |
| |
Soren
Registered: Dec 2001
Posts: 547 |
Remember this order of storing in sid registers, for the following registers of each voice:
Sustain/Release, Attack/Decay, Wave.
Atleast to my knowledge that's the least buggy way of doing it.
Another thing, you could create a tune that has the same ADSR settings throughout the whole piece, so you only need to set those once... Or stable pulse (perhaps square)and do the same thing... |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Soren, it really depends on the sequence being programmed. If the original player assumes gate is written before ADSR then swapping to ADSR first could easily trigger the ADSR bug.
For example, if the player's done a hard reset by clearing gate then setting attack and release to zero for two frames, it's perfectly safe to set gate before setting an ADSR of (eg) $00d8, as the rate limit counter will switch to using the attack rate before the release rate is changed.
Set ADSR before gate, and the rate limit counter will be free to escape (it will be using the release rate in the time between setting SR and setting gate, and probably rise past eight). Bam, no note start for another frame and a half. |
| |
Soren
Registered: Dec 2001
Posts: 547 |
ok :) |
| Previous - 1 | 2 - Next |
