Totally Awesome to the MAX!!

Ask anything your want about the 32X Mushroom programming.

Moderator: BigEvilCorporation

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Feb 28, 2011 8:09 pm

mic_ wrote:
I'm comparing against Audacious/ModPlug for my testing.
Doesn't ModPlug have a bad reputation among Amigaphiles? I recall seeing lots of complaints about it. Maybe you could try XMPlay instead. Or something based of libfmod.
The base of the code is the Amiga version ProTracker, but Tiido complained it didn't sound like the PC... in which ModPlug is the most popular mod player, followed by libmikmod. I suppose I can look at what xmplay does instead of modplug, but the base code is still the ProTracker code.

I need to go back and redo some of the changes anyway - the current code sounds good, but some song like (Fountain of Sighs) got "sluggish" for no apparent reason. So I'm going to go back to the first code and check FoS at each step to find what caused that.

Libfmod isn't open source. Also, the mod playing can't be based DIRECTLY on any of the PC libs (like xmplay or mikmod) because they all assume you're on a modern PC with infinite speed and memory. Even using the old Amiga ProTracker code required some changes, like processing the patterns on the fly instead of at load time like everyone does.

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Mon Feb 28, 2011 11:00 pm

You can always look at Milkytracker's source code.

For my MOD player wip, I used a number of docs (one was particularly great) - but I always ended up testing the effects directly in milkytracker and comparing them to my player. MOD format has sooo many of "start on tick 0" and "start on tick 1" - it's annoying as hell. Also, what did you use for the vibrato table? It was a little tricky at first because I forget to AND the pointer between rows continuing vibrato (like $400) and let the left over accumulate still. Just tiny little things like that.

Also, what MODs use tremolo? XM format shouldn't be much more complex if you got MOD fully functional. But the sample storage format is stupid for XM. It's stored as deltas, but not 'compressed'. Nobody could give me a straight or logic answer as to why.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Mar 01, 2011 1:05 am

tomaitheous wrote:You can always look at Milkytracker's source code.
Good idea. I'll grab the latest version.

For my MOD player wip, I used a number of docs (one was particularly great) - but I always ended up testing the effects directly in milkytracker and comparing them to my player. MOD format has sooo many of "start on tick 0" and "start on tick 1" - it's annoying as hell. Also, what did you use for the vibrato table? It was a little tricky at first because I forget to AND the pointer between rows continuing vibrato (like $400) and let the left over accumulate still. Just tiny little things like that.
As mentioned, I used the ProTracker code for the Amiga off AmiNet as the base.

http://aminet.net/package/mus/play/Ami-PlayMOD_V1_0

Also, what MODs use tremolo?
Darned if I know. I never paid much attention to mod before other than playing mods I liked.

XM format shouldn't be much more complex if you got MOD fully functional. But the sample storage format is stupid for XM. It's stored as deltas, but not 'compressed'. Nobody could give me a straight or logic answer as to why.
XM isn't much more complex as far as being a tracker format is concerned, but it's a LOT more complex as far as playing instruments is concerned. Just look at the envelop and panning.

I just compiled Gens/GS r7 with my patches for DMA PWM, and it works fine with my MOD player... even down to the "sluggishness" on a couple mods with my latest code. Talk about accurate emulation! :lol:

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Mar 01, 2011 6:46 am

Found the reason some mods were "sluggish" in the last couple versions, and it was QUITE LITERALLY the VERY LAST thing I checked. :lol:

It was the song speed effect - the original code didn't support beats per minute, so I added in some code. I was pretty proud of it - it was simple and compact... and the source of the problem. So I gave in and went to look how everyone else handles bpm; turns out, they DON'T! In every other player, for modules, they ignore the speed effect if it tries to use bpm. Apparently there are a LOT of mods that just don't use the bpm correctly, so rather than have some god-awful mess that deals with it, everyone just ignores it... so now I do too. 8)

I'll be uploading my latest code and binaries as soon as I've listened through them to make sure nothing broke in the meantime. This code "fixes" the "sluggish" mod problem, and even more importantly, has cleaner sounding audio that's actually FASTER than the older code. :twisted:

As mentioned in an earlier post, I was originally using the volume to scale down the 8-bit samples before summing them. The result was a 9 or 10 bit sample I could just convert straight to PWM. The new code uses the volume to scale the 8-bit sample to a 13 bit sample that sums (over 8 voices) to a nice 16-bit sample. Then I scale that down as I convert it to PWM. It's a little slower the ONE TIME I convert to PWM, but it's faster when generating the samples (up to eight of those), so overall it's faster and I get cleaner audio on top of it.

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Fri Mar 04, 2011 5:48 am

It was the song speed effect - the original code didn't support beats per minute, so I added in some code. I was pretty proud of it - it was simple and compact... and the source of the problem. So I gave in and went to look how everyone else handles bpm; turns out, they DON'T! In every other player, for modules, they ignore the speed effect if it tries to use bpm. Apparently there are a LOT of mods that just don't use the bpm correctly, so rather than have some god-awful mess that deals with it, everyone just ignores it... so now I do too. Cool
Are you sure about that? Maybe only the original MOD format supported tick changing and not master clock changing, but the extended MOD format does. And, IIRC, there is only 1 MOD that gets the master tick setting wrong. It was in some doc. Probably proprietary to some game engine or particular MOD tracker. Else, the BPM setting - or rather the master clock setting for the tick time resolution, works fine. Unless you're limiting yourself to the very first revision of the MOD format.

I'm curious as to how you're handling the original/default BPM (master clock setting) of 50hz on NTSC 32x? You're not stretching the ticks to compensate for 60hz, are you? That could definitely make the FX sound different than normal.

Also, S3M is sort of in between MOD and XM. It's very close to MOD and uses the Amiga period frequency, even though it was designed for PC only. It has all the MOD effects, but an extra column per channel like XM.
but it's a LOT more complex as far as playing instruments is concerned. Just look at the envelop and panning.
The envelope system is extremely easy to emulate. It's rather primitive IMO. It's just a series of deltas and fixed to tick offsets. I mean, it's not dynamic in anyway. Very easy to handle (not much different than envelopes on older PSG sound engines in software). The only real thing to worry about, is that XM supports both linear frequency range and Amiga period steps. An XM module can be set to use either one of them. And all FX that touch/modify the frequency of the channel behave differently in Linear frequency mode than Amiga period mode.

Edit: Here's a best doc I could find: http://www.pcedev.net/docs/FMODDOC.TXT

Explains the BPM setting in Section 3.2

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Mar 04, 2011 7:08 am

tomaitheous wrote:Are you sure about that? Maybe only the original MOD format supported tick changing and not master clock changing, but the extended MOD format does. And, IIRC, there is only 1 MOD that gets the master tick setting wrong. It was in some doc. Probably proprietary to some game engine or particular MOD tracker. Else, the BPM setting - or rather the master clock setting for the tick time resolution, works fine. Unless you're limiting yourself to the very first revision of the MOD format.

I'm curious as to how you're handling the original/default BPM (master clock setting) of 50hz on NTSC 32x? You're not stretching the ticks to compensate for 60hz, are you? That could definitely make the FX sound different than normal.
My new code has a hack for BPM. It seems to work okay, but it's certainly not "correct" by any means. :lol:

Looking at some of the newest code out, what most folks do is run the audio system at 250 Hz, not 50. That allows them to fine tune the BPM handling.

I don't use the vblank for timing - I use the audio. The sample rate divided by the number of samples gives me a 50Hz period, regardless of the 32X TV mode. I check for PAL/NTSC when setting the cycle period, using the correct clock for the TV mode. I also use the Amiga PAL clock when converting the note periods to sample rates, so it should give the "proper" results on either NTSC or PAL.

Also, S3M is sort of in between MOD and XM. It's very close to MOD and uses the Amiga period frequency, even though it was designed for PC only. It has all the MOD effects, but an extra column per channel like XM.
Sounds pretty simple.
The envelope system is extremely easy to emulate. It's rather primitive IMO. It's just a series of deltas and fixed to tick offsets. I mean, it's not dynamic in anyway. Very easy to handle (not much different than envelopes on older PSG sound engines in software). The only real thing to worry about, is that XM supports both linear frequency range and Amiga period steps. An XM module can be set to use either one of them. And all FX that touch/modify the frequency of the channel behave differently in Linear frequency mode than Amiga period mode.
Ah - I need to read up more on it I guess. I really want to get XM to work. That would solve a lot of my music woes - I have converters that allow me to convert MIDI into 8 channel XM with 8-bit instruments with no more than X sample rate (e.g., 11kHz). So I tried that on the Doom music and it sounds just about the same as the original MIDI.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Mar 04, 2011 8:35 am

Okay, I've changed the code again to get rid of the ugly hack. What I do now is change the number of samples when the beats per minute is set. So the BPM on playback is as accurate as you can get by changing the number of samples with a fixed sample rate. On the few mods I have that use bpm, it sounds pretty damn accurate to me. I'll post an arc with the latest code and binaries in the other thread a bit later.

Right now, the max number of samples is 512, which limits the low end to 108 bpm. The high end is only limited by how long it takes to process the samples; 176 bpm (the highest I've seen) would use 312 samples. The default of 125 bpm uses 441 samples.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Mar 06, 2011 3:13 am

Been reading up on XM, and while the format itself is pretty easy - mostly a slight update to the regular MOD format, I did find a VERY serious impediment to playing an XM directly - the samples are all in delta format.

This means each sample is the difference between itself and the previous sample. That's bad for the 32X... or most computers in general. Most players simply change the format when the instrument is loaded. The 32X doesn't HAVE memory for loading instruments - it's one of the BEST things about MOD is that the samples are all 8-bit signed values. Made it VERY easy to work with. Delta values? Since there's no memory for loading an instrument, you'd have to have some god-like routine that could convert delta to absolute on the fly while skipping indeterminate numbers of samples. The only way I see that being done would add WAY too much overhead to the mixer.

Your other choice is to "preprocess" the XM before it gets added into the rom; but if you're going to do that, why even bother with XM at all? Go with another format that makes more sense... and I'm open to suggestions.

Requirements:

Simple structure - no complex compression since we have no memory for decompressing to, nor much time to decompress on the fly.

Samples should be 8 or 16 bit signed samples. No ADPCM or delta format or that kind of nonsense. Again, we have no memory for decompressing to, nor the time to decompress on the fly. That's DOUBLY true of the mixer. We could probably do simple decompression of the tracks, but decompression in the mixer would mean only handling a few voices at the same time. We should be able to mix eight channels with little overhead like the current mixer.

Has decent support... meaning there's converters for most other formats into this one.

EDIT: I think I won't be able to get around pre-processing the files, so I'm looking into MaxMod again. That converts MOD, IT, XM, S3M, and WAV into a bank suitable for including in a rom; the music is all pre-processed into a form making it easier for the GBA/NDS to run directly from rom, so it's probably the best for 32X as well.

TotOOntHeMooN
Interested
Posts: 38
Joined: Sun Jun 01, 2008 1:12 pm
Location: Lyon, France
Contact:

Post by TotOOntHeMooN » Mon Mar 07, 2011 6:07 pm

Amazing use of the 32x Slave ! :)

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Mar 07, 2011 7:04 pm

This thread is old - for the latest version of the mod player, see this thread:

viewtopic.php?t=890

TotOOntHeMooN
Interested
Posts: 38
Joined: Sun Jun 01, 2008 1:12 pm
Location: Lyon, France
Contact:

Post by TotOOntHeMooN » Mon Mar 07, 2011 7:24 pm

Old since ... Yesterday ! :D
OK, I'm looking the new tread. Thanks !!!

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Mar 07, 2011 9:28 pm

TotOOntHeMooN wrote:Old since ... Yesterday ! :D
OK, I'm looking the new tread. Thanks !!!
The first post in the other thread is March 1. While there are still posts in this thread, the opening post and the software therein is older. The latest code and binaries are in the other thread... that's all I wanted to point out.
8)

Post Reply