next »

[nikki]

To generate music procedurally, (been chatting with baconman )
I figure its a good file format, with alot players, editors libraries and everything available. And it sounds nice. Eventually some values will be changed at runtime in these files (or atleast thats my current naive approach) that will change melody, speed and instruments.

The thing is i found the  actual file format and i don't understand some things. here we go:

Code:

--- Pattern header
The patterns are stored as ordinary MOD patterns, except that each note is
stored as 5 bytes:

	  ?      1   (byte) Note (0-71, 0 = C-0)  [b]// this is the note value, but ?MSB?[/b]
	 +1      1   (byte) Instrument (0-128)
	 +2      1   (byte) Volume column byte (see below)
	 +3      1   (byte) Effect type
	 +4      1   (byte) Effect parameter

A simle packing scheme is also adopted, so that the patterns do not become TOO
large: [b]Since the MSB in the note value is never used, it is used for the
compression[/b].If the bit is set, then the other bits are interpreted as follows:

bbcode seems messed,; Since the MSB in the note value is never used.. what is msb ?

I'll probably add more questions to this post as we go, and hope to be a master of the xm file format quite soon 

[increpare]

MSB = most significant byte I'd guess (the leftmost one).

Oh wait, maybe they mean the most significant bit of the note value, because it never goes to or above 128.

[nikki]

seems logical, thanks!

[increpare]

see my edit...

[nikki]

ok, next question,

in the file format i see types like this :  char, word, dword, byte.
it ought to tell me howmany bytes will be my next read in the file , but what about dword ? what size IS that ? google tells me that it depends on the architecture.. and char ? what is that?

in the language i will be attempting to conquer this file i have :
 byte(,short(16),int(32),long(64),float(32),double(64) .

wich one would map to the dword and char ?, or should i start bit-fiddling ;(

[nikki]

oops

[jmp]

in the file format i see types like this :  char, word, dword, byte.
it ought to tell me howmany bytes will be my next read in the file , but what about dword ? what size IS that ? google tells me that it depends on the architecture.. and char ? what is that?

FastTracker II was written for MS-DOS where the word size was 2 bytes (16 bits).  Double word is therefore 4 bytes.  Maybe this (written by one of the programmers) is more clear.  It gives all the lengths in bytes as well.

[nikki]

  thanks alot  
i'll study then sleep.

thanks again



edit: i also needed to find the mod file structure here it is , it might be a better place to start for me (no packing shemes and less data to handle)

[lansing]

for mod, you might find this useful, it's from the multimedia.cx wiki which is dedicated to multimedia formats

[nikki]

great , thanks, i think i'll focus on mod and maybe later see if xm is possible, and needed (at this point the only advance xm has (that i see and could need) is that it has more then 32 instrument-samples in the song..)

btw i fixed that link wiki.multimedia.cx/index.php?title=Protracker_Module

[baconman]

Hmm... I would still side with XM off the bat, because it's definitively pattern-based (much like real music structure is), and videogaming soundtracks rarely have anything more "whimsy" than a good guitar/drum solo going on in them. MOD may be better if you're going for a more whimsical, easily-tweaked folksy kind of sound.

Admittedly, I was hoping to completely internalize my music playback system (just not all of the instrument samples, load those as needed), and simply produce the music by referencing a few strings of code/variables in a player's savegame. So "note scale x" combines with "note/timing patterns n1-n4" to make a verse on the fly; without having to produce an entire song file every time a level is played. The only additional "data weight" is a number of variables like that; and even those can mix and match to some extent.

But if XM support is capable of compiling quickly enough, a wiser move may be to use said variables to construct a temp.xm file and then use ordinary playback functions with it. *hmm*

[muku]

Admittedly, I was hoping to completely internalize my music playback system (just not all of the instrument samples, load those as needed), and simply produce the music by referencing a few strings of code/variables in a player's savegame. So "note scale x" combines with "note/timing patterns n1-n4" to make a verse on the fly; without having to produce an entire song file every time a level is played. The only additional "data weight" is a number of variables like that; and even those can mix and match to some extent.

But if XM support is capable of compiling quickly enough, a wiser move may be to use said variables to construct a temp.xm file and then use ordinary playback functions with it. *hmm*

Sorry for the shameless plug, I don't know if you've seen it, but I've been working on a synthesizer library called Cosyne which is very easy to embed in games; see the link in my signature. It doesn't have any pattern support at the moment, but that should be easy enough to build on top of it.

So if you want to avoid mucking around with temporary files and such, that might be an option.

[nikki]

Hmm... I would still side with XM off the bat, because it's definitively pattern-based (much like real music structure is), and videogaming soundtracks rarely have anything more "whimsy" than a good guitar/drum solo going on in them. MOD may be better if you're going for a more whimsical, easily-tweaked folksy kind of sound.

well i'm no expert but the musicstyle is entirely up to the maker
what xm has over mod is: 16 bit samples, more instrument 'slots', more channels and compression. Wich makes it a little harder to try to understand (and read/write) So mod is a better start-point i guess. (since both those filetypes share alot of properties)

btw check out my current favourite mod (jazzfunk.mod 135 KB).

Admittedly, I was hoping to completely internalize my music playback system (just not all of the instrument samples, load those as needed), and simply produce the music by referencing a few strings of code/variables in a player's savegame

That would be nice indeed, it does however need a) alot of samples or b) a way to generate those samples in realtime.
Before going into the b) write a synth without knowing it yet path.. , i thought "let's look at the old solutions that are here ", the a) many samples way is not nice i think.

This could all be not a problem at all, if you have exactly the right tools at your command...

@muku : Yeah i saw your post a little ago, I like the acroname its super.
I am interrestet in your library, because if i understand it correctly its particularly suited for generated sample data right ?
I'm assuming that such data is easy to use in another language (like for example blitzmax)
But i haven't really properly looked into cosyne yet .

the temporary file woudln't bother me much tough, your procedural generated samples tickle me beter.

anywy, i haven't got anything working yet 

[baconman]

Looking back, if there's a way to pitch-shift a recorded note, without changing the timing of it (or more precisely, changing it independently), it's quite possible that most of the instruments can be "written" with but a single sampled note recorded! Or perhaps simply by using one note per scale, at the most, and a limited shifting variable for clarity (+/-3, for instance). Drums are about the only thing that would require multiple files, that way.

 

b) write a synth without knowing it yet path.. ,

Gah. Therein lies the problem, I suppose.


EDIT: On second thought, recording the highest or lowest note per scale, and then adding/subtracting a constant variable (per note) might result in the best quality, instead. May take some experimentation to see for sure.

[muku]

Looking back, if there's a way to pitch-shift a recorded note, without changing the timing of it (or more precisely, changing it independently), it's quite possible that most of the instruments can be "written" with but a single sampled note recorded!

Changing pitch and timing independently is possible to a degree, but it's quite computationally expensive. What I think mod/xm players do is just take the sample and resample it at a higher/lower frequency to get the pitch shift. This changes the timing of course; they do have an optional looping region in the sample which can be used to compensate for the change in duration.

Or perhaps simply by using one note per scale, at the most, and a limited shifting variable for clarity (+/-3, for instance). Drums are about the only thing that would require multiple files, that way.

That's basically what the SoundFont format does; you can find huge libraries of sampled instruments in SF format online if you care to look. Some of them have quite high quality.

[pgil]

XM files can do that too. You can have (I think) up to 32 samples per instrument, and assign each of them a pitch, and a place on the keyboard.