Extracting gm.dls samples for tiny demo trackers

[Jim]

Sounds like a mission

Jim

[Rbz]

I already did my tests with playsound and directsound, and I'll be using directsound, I'm finding it very powerful (as it should be) and I have coded a basic player and working on a tracker.

Player features:
- 4 sound channels (can be expanded to 8 channels)
- 8 gm samples
- 32 rows per page
- 8 pages
- 32 postions for pattern order
- Player runs in real time, yeah I can easily add synch with intro effects.

There's no fx added yet, only volume control for each sample.

It's very very simple player, but it can able to produce some sort of music , oh yeah and very tiny - around 650~700 bytes for player and music data.

[taj]

There's no fx added yet, only volume control for each sample.

It's very very simple player, but it can able to produce some sort of music , oh yeah and very tiny - around 650~700 bytes for player and music data.

Try adding reverb or any fx and see what size your exe jumps to - my guess is you'll be >1k.

Well done on producing all that!

Chris

[Rbz]

Well done on producing all that!

Thanks, just looking to what you already did, make me motivated to code my own!

Try adding reverb or any fx and see what size your exe jumps to - my guess is you'll be >1k.

Ok, I'll see what I can do...

Btw, do I really need to add midi notes (change frequency) for the samples, you know, I'm not a musician and I don't know if I *must* add this... 

[Raizor]

Excuse the necro-posting, but I've been playing around with GM.DLS and using Jim's example program as a reference.

I noticed a little problem when processing extra elements in GM.DLS RIFF file. Sometimes the payload (data) for an entry is marked as having an odd number of bytes. In this case, the data is padded with an extra byte in the DLS file. This was causing me a few problems, which I resolved by changing the 'dlist' method slightly:

I changed

      riff = (unsigned int *)((unsigned char *)riff + 8 + *(riff+1));

to

      unsigned int dataSize = *(riff+1);
      if (dataSize % 2 != 0) dataSize++;
      riff = (unsigned int *)((unsigned char *)riff + 8 + dataSize);

It then takes into account the extra padding byte and enables you to process any of the elements without issue. Just for reference, the issue I experienced was due to the uneven ICOP entry in the INFO lists.

I thought that this may prove helpful to someone at some point. Depending on how deep I end up delving with this, I may have a C# application similar to Blackpawn's at some point. If so, I'll post a link to it on the forum.

[Raizor]

I had a little trouble tracking down the PDF specs document for DLS files (lots of dead links). I've attached it to this post.