They are padded to 64 bytes (see .align). It's no more manual than manually specifying the addresses of the trail. If you mean something else, please quote the part of the source code that you're claiming is too manual.Wave wrote:So you have to do it manually for each sample?tepples wrote:For an illustration, have a look at how I handle samples in the source code to LJ65.
Wouldn't it be better to have samples padded to 64 bytes and use the trail as I suggested?
RJDMC 1.53
Moderator: Moderators
Except the starting address, that would be set 1 time, length and freq would be outputted by the program.tepples wrote:They are padded to 64 bytes (see .align). It's no more manual than manually specifying the addresses of the trail. If you mean something else, please quote the part of the source code that you're claiming is too manual.Wave wrote:So you have to do it manually for each sample?tepples wrote:For an illustration, have a look at how I handle samples in the source code to LJ65.
Wouldn't it be better to have samples padded to 64 bytes and use the trail as I suggested?
The way I am saying you don't have to realign all samples if the first one changes it's size.
EDIT: on NESHLA is something like this:
#rom.org 0xC000
tostarStart:
#incbin "../../music/dmc/tostar.dmc"
byte tostarData[] = {lo((tostarStart - 0xC000)/64)}
#incbin "../../music/dmc/tostar.tra"
flipStart:
#incbin "../../music/dmc/flip.dmc"
byte flipData[] = {lo((flipStart - 0xC000)/64)}
#incbin "../../music/dmc/flip.tra"
etc...
Length would be computed from the starting address of the following sample minus the starting address of this sample. Frequency is manual, I admit, but due to the coarse frequency control, it can't easily be changed unless your converter program resamples the data. Music engines usually have to change the frequency anyway for something like a Sunsoft bass, SMB3 timpani, or a Dr. Mario/Hello Kitty World drum line. But perhaps we could combine these approaches. The converter would store the default frequency as part of a 15-byte footer, and the same reference to the $4013 value for sample n+1 would let the playback code look up sample n's precise length and default frequency.
That's the idea, store on the footer the original data. For "fixed rate" samples, for Drum or Bass, you could select the sample via code.tepples wrote:Length would be computed from the starting address of the following sample minus the starting address of this sample. Frequency is manual, I admit, but due to the coarse frequency control, it can't easily be changed unless your converter program resamples the data. Music engines usually have to change the frequency anyway for something like a Sunsoft bass, SMB3 timpani, or a Dr. Mario/Hello Kitty World drum line. But perhaps we could combine these approaches. The converter would store the default frequency as part of a 15-byte footer, and the same reference to the $4013 value for sample n+1 would let the playback code look up sample n's precise length and default frequency.
Re: RJDMC 1.4
Bumping for updated file.
Re: RJDMC 1.53
v1.53 released
-
- Posts: 1
- Joined: Sun May 28, 2023 7:53 pm
Re: RJDMC 1.53
When I try to go to 4x86.com, it asks me if I'm interested in this domain. It also says that the related searches are [Mod note: Edited to remove SEO terms]
Re: RJDMC 1.53
The same goes for the FamiTracker website. It says "Avstängd webbplats". Please attach RJDMC because it's lost media now.
Re: RJDMC 1.53
Was only able to find v1.4 via Wayback Machine; attached it to this post. Hopefully someone comes across the later v1.53 version.
- Attachments
-
- RJDMCv1.4.zip
- (113.09 KiB) Downloaded 37 times