RJDMC 1.4

Discuss NSF files, FamiTracker, MML tools, or anything else related to NES music.

Moderator: Moderators

tepples
Posts: 21806
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Wed Dec 15, 2010 3:41 pm

Wave wrote:
tepples wrote:For an illustration, have a look at how I handle samples in the source code to LJ65.
So you have to do it manually for each sample?
Wouldn't it be better to have samples padded to 64 bytes and use the trail as I suggested?
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
Posts: 110
Joined: Mon Nov 16, 2009 5:59 am

Post by Wave » Wed Dec 15, 2010 3:51 pm

tepples wrote:
Wave wrote:
tepples wrote:For an illustration, have a look at how I handle samples in the source code to LJ65.
So you have to do it manually for each sample?
Wouldn't it be better to have samples padded to 64 bytes and use the trail as I suggested?
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.
Except the starting address, that would be set 1 time, length and freq would be outputted by the program.
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...

tepples
Posts: 21806
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Wed Dec 15, 2010 4:19 pm

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.

Wave
Posts: 110
Joined: Mon Nov 16, 2009 5:59 am

Post by Wave » Thu Dec 16, 2010 1:14 am

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.
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.

User avatar
RushJet1
Posts: 154
Joined: Wed Nov 10, 2004 10:17 pm
Contact:

Re: RJDMC 1.4

Post by RushJet1 » Wed Jul 01, 2015 10:52 am

Bumping for updated file.

Post Reply