(Cross-posted from Cemetech)

Over the past couple of weeks, I've been working on a four channel interrupt-based music player for use in assembly games. This program is for 15MHz+ calculators, so no, it won't work on normal TI-83+. Today, I'm proud to report that I've gotten more than just a frequency sweep test written. Today, I've got actual music to play.


For this test, I embedded the source (almost verbatim) of the track "Same One (Bellon)" found with QuadPlayer, and wrote a small routine that feeds that information almost verbatim into the sound driver. After tweaking the frequency delays of the audio interrupt and messing with the tracker timing, I ended up with this: https://soundcloud.com/iambian-zenith/audiotest2/s-q7HJz

(Note: The music is much cleaner on hardware. And when the computer trying to record this isn't struggling)

More work needs to be done with the actual timing or file interpretation (or perhaps the source is at fault? I dunno.) and there does seem to be distortion in the sound at higher frequencies. For the sound linked above, the crystal timer for the sound driver is set at CPU (15MHz) / 8 with a delay count of 30 (which resolves to about 62.5KHz), while the timer for the music tracker was ... well.... guessed and tested until I found that it played it at a rate "close enough" to how QuadPlayer played it.

At the mentioned rate above, I ran further tests to see how much of the CPU is actually taken by the audio interrupt. Using Wabbitemu, I got ~76.5% used, while on my TI-84+SE, I got ~74.8%. During tonight's HCWP, I'd like to distribute this test program to see what numbers other people are getting. I'm especially curious to see if the timings vary a bit more on TI-83+SE hardware.

Another note: Since this an audio-only program, there isn't much in the way of screenshots, unless you like watching a blank screen for the current test, or a bunch of rapidly-changing numbers for the prior test.

Link modified in original post. Quick link here: https://soundcloud.com/iambian-zenith/audiotest2/s-q7HJz

To answer that question, at the moment, you'd have to ask anyone who created QuadPlayer music files. It's probably a pain since it's done PC-side, but seeing as people has done it, it's not as difficult as messing with hex values. Try downloading QuadPlayer and figure out how to make music for that. Once you do, it's as simple as copying (most) of the source into the test program (as it stands). I'll eventually throw together a way to play music external to the player

At the moment, the audio is simply four square wave channels. I have a way to put in a noise channel, but nothing that I know of is tracked to play that type of sound. That's what the tracker I'm planning will include the ability to put in.

Very impressive. Sounds great, especially considering it's interrupt-timed. Looking forward to the tracker! I'd also be very interested to see the source of the player, of course.

Yeah noise channel should be trivial to implement, by simply parsing a sufficiently pseudo-random part of the ROM - I usually use $3000 as a starting point. You might be able to save more CPU time though, by doing the "click drum" trick used in many ZX Spectrum routines. SpecialFX and Savage both pull their drums on interrupts, check the code included in Beepola if you want to know more.

Now, in case you were aiming for full GB sound emulation, to emulate the gameboy's wav channel on the other hand is something entirely different. It's probably doable with intersective pulse width modulation, but i doubt it will be possible with interrupts running.

Sounds awesome! 4 channel, thats Nintendo quality right?

Not quite, The NES has 5 channels, The Commodore 64 is 3 channels. I *think* the Gameboy is 4 channels. Anyho, this is coming along quite nicely Iambian. ^^

It's more like the zx spectrum with its bleeper routines. Wil you add pulsewidth modulation too (using envelopes or LFO's) so you can create some complex compositions?

The current audio driver does not support that and cannot support that in any way. Sorry.
--------------------------------------------
And now, a crosspost from Cemetech:

I've started working on a full-featured tracker. When I dove into that project, I thought it would be all nice and easy, given that I had written out plans for the actual tracking part, but then reality hit me.

File selection would be easy, but creating a new project file? That's what I spent the last two days working on and it's still not fully complete. The menu that allows the user to type it in, however, has been (functionally) completed. So many thing went wrong in it. If you look at the screenshot below, you'll understand why it took so long.

Screenshot: http://imgur.com/sbWFQVi

The code is a huge mess, as well. I'll clean it up after I apply brain bleach and let it simmer so I remember absolutely none of it.

Next in line: Input verification and file creation.
-----------------------------
Also, I talked about adding background music for the tracker's title screen. Good idea? Bad idea? If it's included, there will be a (hidden) option of opening that track for editing.

A tracker would definitively be nice, but since our crowd is mainly oriented towards graphical music creation interfaces, future feature additions that would be nice would be note presets that you can select from a list (Do re mi fa sol la ti do) after choosing the octave, then when selecting the note, it would automatically translate it to its hex equivalent.

Right off the bat, I'm not going to be showing people a hex view. To me, it's not productive at all and discourages actual use. If you want to see hex, you can anyway by switching the view mode, but what you will see instead of hex is a pitch notation A-G, prefixed by which octave it is. For example:

Code: [Select]

CH1 CH2 CH3 CH4 TIME
0A. 1A. 3G. 3C. /16
The time code only really makes sense if you've defined a tempo earlier. In the example above, I defined a sixteenth note. The dots in the pitch notation is to show that it is not showing a hex value, which *can* happen if the hex underlying the pitch value doesn't correspond to anything the program knows. As for timing, it'll make a best guess if the time value is off, tho display "" if it simply can't figure it out.

How will sharps/flats be represented? It seems to me that it would be best to use an extra character to specify when note values are hexadecimal, making hexadecimal values always three characters, and then using the third character in letter notation to display sharp/flat when necessary.

Also, notes with octave values attached traditionally have the octave following the note letter and sharp/flat symbol. What do you think about representing notes more like this, then:

CH1 CH2 CH3 CH4 TIME
A♯0 $1F G♭3 C3  /16