#174444 - Ruben - Sat Jun 12, 2010 6:24 am
Hey, guys.
Well, I've recently been working on my latest music player (which I had named Sound-X). It plays Midi files, supports looping, up to 8 'songs' at once, dynamic loading [from filesystem], reverb, etc.
However, I was actually wondering if anyone would need it. I mean, I know I would need it since I don't particularly like the instrument formats for tracker files and it's faster for me to make Midi files... but would anyone else actually find any use for it?
I've uploaded a sample binary (that only works on emulators, sorry [using my own filesystem routines that read from DS-slot]) with 9 demo songs, no reverb, 16 channel polyphony, all ADPCM encoded.
Anyone actually interested? If anyone is, I'll have to re-write the engine to be more user friendly and less complex [it currently confuses even me].
Linky
EDIT:
Oh yeah, and it has been tested on hardware when the data is in RAM, not DS-slot ROM. It works flawlessly.
#174470 - sverx - Mon Jun 14, 2010 4:37 pm
The test sounds good! I don't know if someone could be interested or not, I wouldn't care about it and release a good library -as much as I can- and see how the community receives it... :)
#174475 - fincs - Tue Jun 15, 2010 9:25 pm
Go ahead, I'm also not exactly fond of tracker formats.
#174562 - Ruben - Sat Jun 26, 2010 10:05 am
Well, I've been working on it, but got stuck on a decision:
What should the sample limit be, and should the sample instance limit be the same?
I mean, if the sample instance limit and sample limit are the same, it simplifies + speeds up the code a fair bit, but may take up more RAM. The other way around, it slows the code down a fair bit as it has to search for an empty slot and/or look for the right sample index but has virtually no limit on samples in the catalogue/database.
What should I do?
EDIT:
Or should I let the user pass a pointer to a wave table [place to keep loaded sample info] [I think this is done in maxmod]?
#174635 - Ruben - Sat Jul 03, 2010 10:13 pm
Well, that's not good...
Long story short, the player was about to be released [I only had to make a RAM-export version of the conversion utility]... when my hard drive pretty much died, leading to me losing all my data.
That is, I've lost ALL my code, all my backups, all my songs, all my images, etc. So yeah... Hopefully I'll do more productive things in this spare time before I go back to programming >_________<
#174643 - Azenris - Sun Jul 04, 2010 3:52 pm
damn that sucks :/
Btw I still have an older version of the SAS source you sent me. Was from awhile ago though, so wont be that upto date with what you was doing.
_________________
My Homebrew Games
#174644 - Ruben - Sun Jul 04, 2010 5:10 pm
Hm, thanks. I'll see what I can do with it.
*has started to re-download everything that can be retrieved*
Oh and another question for everyone: Would you prefer ARM, THUMB or both? Personally, I love ARM cos of all the purdy things you can do, but THUMB is a lot more compact.
Also: Should music players + channels [that is, the actual structures] be passed as pointers from ARM9 rather than all data being ARM7-only therefore inaccessible by ARM9?
#174749 - relminator - Wed Jul 14, 2010 4:39 pm
Hi, almost all my game related BG sounds are in MIDI format so a MIDI DS lib is a welcome addition to me.
_________________
http://rel.betterwebber.com
#174763 - Ruben - Sat Jul 17, 2010 4:36 am
Well, for the time being, I'm using THUMB for all functions except when setting hardware channel stuff. I'm also going to make the initialization function receive main RAM pointers for channels/music players so that the ARM9 can read with no problems.
#174939 - Ruben - Fri Aug 06, 2010 3:45 pm
Well, the music player and sound handler has been complete for about a week, but I only just got the motivation to write the conversion program... and did it, yay.
But now that that's done... Does anyone have any ideas on how to load from files in a user-friendly way? I mean, should I just place function calls to externals provided by the user (ie. DSeq_fopen could be linked to fopen)?
#174952 - Ruben - Sun Aug 08, 2010 4:52 pm
Ok, so that's sorted: User provides links to the file functions as needed.
Now the next problem...
Currently, the system allows for up to 65535 samples in ROM. However, this comes at the cost of having to look through a table for indexes. The solution to this is to have a table that is index BASED, but this limits the amount of samples in ROM.
Any ideas?
#174973 - Ruben - Wed Aug 11, 2010 1:59 pm
Well, it seems to be done, for now. Still appears to have a nasty bug that triggers a slight 'pop' upon note-off. Grr.
Specs:
-16 channel polyphony (14 if reverb is enabled)
-All ADPCM samples upon conversion, but can also use PCM8/16
-Channel locking
-Loading from ROM (such as filesystem)
-Plays Midi files at a resolution of 24 ticks = 1 beat
-Not sure about usage, but it's definitely under 5% at all times
-Tones (patches) with up to 256 key regions (splits if will)
-User assign the data tables so data may be in main RAM
-Updates at a resolution of 240bpm (96Hz)
I've got a small demo up and running, but it runs with filesystem and isn't built with libnds so... While I build a libnds compatible one, anyone want to provide better test Midis? The ones I have right now tend to use over 16 channels, which cuts off soft channels >_>
#175018 - relminator - Mon Aug 16, 2010 4:13 pm
Cool dude!!! vgmusic has a lot of great midi files from the NES era.
_________________
http://rel.betterwebber.com
#175033 - Bregalad - Fri Aug 20, 2010 11:54 am
| Quote: |
| Well, it seems to be done, for now. Still appears to have a nasty bug that triggers a slight 'pop' upon note-off. Grr. |
To fix it you'd want to add a "release" phase, where the volume of the sample is quickly decreased instead of becoming zero instantly (causing the pop). Even if you want the sound to terminate immediately you should implement a very quick release will fix that. Since you say the engine updates at a resolution of 96 Hz => period of 10.42 ms, you'd want a release of slightly less than this.
Otherwise it sounds great to me. Will GBC channels be supported ?
#175034 - Ruben - Fri Aug 20, 2010 2:28 pm
It actually supports ADSR envelopes: it turns out that the 'bug' was nothing more than a crappy sound sample >_<
As for the square/noise channels:
I used to support them, but have decided to not do so as the use channel 8-13 for square and 14-15 for noise while all sampled waveforms can use all channels, so I decided that the user should provide samples.
TL;DR: No GBC channel support because it limits the amount of channels used for them.
#175035 - Ruben - Sat Aug 21, 2010 8:19 am
Ok, I've uploaded the old demo that uses the filesystem for its data. (NOTE: Will NOT work on a real DS because it reads from DS-slot)
Link
Now I just need to find better Midis for testing and port to libnds without using the filesystem.
#175037 - kusma - Sun Aug 22, 2010 2:30 pm
very nice!
#175081 - Ruben - Fri Sep 03, 2010 6:08 pm
Well, this is embarassing...
Since I don't know how libnds works, I've tried to port it to the best of my ability... Apparantly it isn't enough xP
The only problem appears to be FIFO not catching messages so... as soon as I fix that, I'll upload the demo.
#175085 - Ruben - Sat Sep 04, 2010 10:26 am
Ok, finally ported.
All sources included (but since I still haven't 100% finished it, no converters or their sources). Link
#175159 - Ruben - Sat Sep 18, 2010 9:41 am
Ok, here's everything:
-Driver renamed from DsSeq to xAS (Extended Audio Sequencer)
-Removed echo effect (not hard to implement, and rarely used, anyway)
-Fixed 99% of bugs
-Improved routines
-Ported to libnds
-Tested on hardware - works perfectly
However, I'd like to point out that it hasn't been tested for compatibility with threads, so watch out if you use threading.
Demonstration (with source)
Library only (source code, no .lib)
Conversion tool A (creates a master file for loading from FAT)
Conversion tool B (creates individual constant DATA files rather than FAT-related)
#175167 - kusma - Sun Sep 19, 2010 8:48 pm
| Ruben wrote: |
-Fixed 99% of bugs
-Tested on hardware - works perfectly
|
Heh, these two are pretty bold claims ;)
#175168 - Ruben - Mon Sep 20, 2010 7:36 am
Hey, 99% of bugs are all I know of =P
And it worked perfectly on hardware: no lockups, no bugs, nothing. Worked just like on emulators. =P
#175174 - Ruben - Tue Sep 21, 2010 11:15 am
Ok, fixed a major bug in the file loading routines.
*shakes fist at kusma* =P
Updated code (xAS_File.s, ARM9 source)
#175192 - Rajveer - Thu Sep 23, 2010 2:43 pm
Is that 100% now? ;)
#175193 - Ruben - Thu Sep 23, 2010 6:15 pm
You guys are jinxing me >_>
Found a small bug in the conversion tool (not bug per se, but just didn't behave as intended). Recently fixed.
Linky