Some audio stuffs

[TurboXray]

I posted here: https://pcedev.wordpress.com/2015/10/31/pcm-player/

tl;dr

On the topic of audio, have you guys ever heard the PCE stream 55khz 5bit PCM using the channel's waveform memory as a buffer? Check it out: pcedev .net/6280a/sgx_dump.wav That was recorded from my SuperGrafx.

So, basically I know what I can do on the SGX or more specifically the 6280a, but I wanted to get some recordings from PCE owners (6280), if possible. I'll post a few demos. I'm looking for recordings like the one above and what console it was recorded from.

[touko]

Great, i always wanted to know what's the max PCE's frequency for PCM ..
55khz is awesome, but i think (even if it's useless) it could be higher ??

[TurboXray]

Supposedly, up to 3.5mhz if you can write to it that fast - lol. With a 7khz interrupt, you can output 224khz if you use all 32 bytes in the waveform buffer.

[elmer]

I posted here: https://pcedev.wordpress.com/2015/10/31/pcm-player/

Cool stuff! 

I'm definitely curious to hear something that takes advantage of all those capabilities.

IIRC, the typical CPU budget for sound/music on home-computers was around the 10%-15% range.

With a 7khz interrupt, you can output 224khz if you use all 32 bytes in the waveform buffer.

Music for bats? 

[touko]

224khz

whow, i think a NG cartridge is needed .

Music for bats? 

[pceslayer]

What would be the best way to record the samples? RCA -> 3.5mm into aux input?

I have quite a few variations of PCE/TG hardware I can test with.

[spenoza]

I'm still clueless as to why they put the 6280a in the Core, but not in any of the other PCE systems. Any thoughts?

[CrackTiger]

I'm still clueless as to why they put the 6280a in the Core, but not in any of the other PCE systems. Any thoughts?

Same reason the SuperGrafx (which also has it) wasn't supported. The PCE as it was, was already good enough and proved it by going the distance.

[spenoza]

I'm still clueless as to why they put the 6280a in the Core, but not in any of the other PCE systems. Any thoughts?

Same reason the SuperGrafx (which also has it) wasn't supported. The PCE as it was, was already good enough and proved it by going the distance.

Except that the improvements in the 6280a are minor enough that I doubt they increased production cost, and they clearly already had the ability to manufacture the chips. That's why I'm confused. It seems like it should have been one of those seamless upgrades nobody would have noticed.

[CrackTiger]

Just read the blog post. 29% cpu resource for 4 XM channels is pretty amazing since Air Zonk does everything it does with 21% wasted on audio. I'm guessing that 6 channels would be fine running with most sections of an RPG.

[touko]

since Air Zonk does everything it does with 21% wasted on audio.

Yes airzonk's driver sucks .
I have a driver with compression/buffering and banking it uses 3/4% per channel .

[ccovell]

Yes airzonk's driver sucks .
I have a driver with compression/buffering and banking it uses 3/4% per channel .

Doesn't 3%-4% x 6 mean 18%-24%?

[touko]

Deleted

[TurboXray]

Just read the blog post. 29% cpu resource for 4 XM channels is pretty amazing since Air Zonk does everything it does with 21% wasted on audio. I'm guessing that 6 channels would be fine running with most sections of an RPG.

Airzonk is a lot higher than 21% cpu resource. Just to be sure, before posting this reply, I took 10 readings from the game's TIMER interrupt. The actual cpu resource floats between 29% and 33%.

It was at 33% when it had to reload the bit shifter (decompress the samples), which if I recall is every three samples or so. It was about 30% for just playing the sample. That doesn't include any music engine stuff (reading the byte code music for the normal channels). I made sure the samples (sampling of the code) I read didn't touch that part (that would give a false reading). So 30% just for playing the samples, and whatever cpu resource for regular channels.

 For an RPG, I think you could get away with almost 70% cpu resource dedicated for audio (if the game is coded in assembly). That would allow much higher rate sampled channels.

[CrackTiger]

So that adpcm player you posted a video of playing that Mega Man cover would be doable cpu-wise in an RPG then? It'd be a cool way to do snippets of voice acting in cinemas (which I assume are even less intensive) or for repetitive bgms.

It's crazy to think that ineficient sound alone in Air Zonk eats up at least a third of cpu resource when it throws around as much as it does compared to SNES and Genesis shooters.

[touko]

Thanks tom for clarifying about the cpu used for PCM , i was not sure about the number of percent,this is why i deleted my answer for chris ..
Of course i spoke only for PCM and my values are for PCM only .

It was at 33% when it had to reload the bit shifter (decompress the samples), which if I recall is every three samples or so.

i probably use the same method to compress samples .
1 sample in the first 5 bit of the 1st byte
1 sample in the first 5 bit of the 2nd byte
and the 3th packed in the 3 last bits of the first byte, and the 2 last ones in the 2nd byte, in fact only the 3th sample needs to be shifted .
Of course you lose 1 bit, but your sample is reduced by 33% ..

[TurboXray]

I found over the years that good game developers, don't necessarily produce the most optimal code or design - to put it nicely. I've attempted to understand the thinking and philosophy of Japanese programmers in the 80's and 90's, and I'm just at a complete loss. I know there are factors keeping them from optimizing and fine tuning every little thing, but as a programmer and people that I known as programmers - there's this idea, this desire, this drive - that you want to create the best/fastest/whatever code possible; you want to push something to its limits. I guess that's a cultural thing and that's not what motivated most Japanese programmers at the time (with exceptions of course. There are always exceptions). 

 I read an interview with one of the guys that worked with Nintendo to get 3D on the SNES (originally meant for NES - the MARIO chip), and how he ended up moving to Japan and working directly with Nintendo programmers and producers for a number of years. He mentioned that game developers, like Miyamoto, would often take a game back to ground zero - many times during its development. If that was the case, I can see how optimizing stuff would be a waste of time during the development cycle. But to me, that shows that the producers were simply dictating to the programmers rather than working with them. Like I said, I really don't know.

So that adpcm player you posted a video of playing that Mega Man cover would be doable cpu-wise in an RPG then? It'd be a cool way to do snippets of voice acting in cinemas (which I assume are even less intensive) or for repetitive bgms.

Yeah, but it doesn't save a whole lot space (although the final sample output quality is better).

 There are a lot of things you can do with an traditional JRPG that you couldn't normally do with an action game. For instance, you don't need to run the game at 60fps. It doesn't really benefit from it. But imagine what you could do with essentially a 14mhz cpu (basically what it translates into; twice the cpu cycles per "frame")? You already know the limitations of some of the graphics on the PCE; mainly tile flipping and layer priority (different than parallax). For instance, you could do tile streaming engines, where not only would it solve the tile flipping issue - but you could also create unique sets of tiles on the fly by compositing small details (later gen SNES games use multilayer BGs as a single BG to do this). Sprites could be AND'd in realtime with masks to create priority on a per pixel basis (I did a routine that can do this at 2% cpu resource per 16x16 cell sprite). All kinds of graphic effects for the overworld. The same could be applied to battles, etc. 

[TurboXray]

Thanks tom for clarifying about the cpu used for PCM , i was not sure about the number of percent,this is why i deleted my answer for chris ..
Of course i spoke only for PCM and my values are for PCM only .

It was at 33% when it had to reload the bit shifter (decompress the samples), which if I recall is every three samples or so.

i probably use the same method to compress samples .
1 sample in the first 5 bit of the 1st byte
1 sample in the first 5 bit of the 2nd byte
and the 3th packed in the 3 last bits of the first byte, and the 2 last ones in the 2nd byte, in fact only the 3th needed to be shifted .
Of course you lost 1 bit, but your sample is reduced by 33% ..

AZ is using a full 33% for a single channel though. You have it down to 3-4% per channel, right?

[touko]

AZ is using a full 33% for a single channel though. You have it down to 3-4% per channel, right?

Yes, 3/4% with banking, buffering,decompress and of course playing sample .

Even my first unoptimised pcm driver was far under 30%, may be 6/7%,i can not understand how coders could be satisfied with 30%.

[Sunray]

Hello, my first post here.

What is the difference between HuC6280 and HuC6280A exactly? I've head different things like click reduction and panning fixes?

[TurboXray]

Touko, this should give you an idea.... ;_;

Code Select Expand

    phy
    phx
    pha
    sta $1403
    lda <$f1
    bne .skip
    lda #$01
    sta <$f1
    cli
    tam #$02
    pha
    tam #$03
    pha
    tam #$04
    pha
    tam #$05
    pha
    tam #$06
    lda #$31
    tam #$02
    inc a
    tam #$03
    inc a
    tam #$04
    inc a
    tam #$05
    inc a
    tam #$06
    jsr $4000     ;jumps to DDA and music routine
    pla
    tam #$06
    pla
    tam #$05
    pla
    tam #$04
    pla
    tam #$03
    pla
    tam #$02
    stz <$f1
.skip   
    pla
    plx
    ply
    rti
 This is just the intro and extro code (TIMER routine). It's ridiculous because none of that overhead is needed for the DDA streaming part. And yet, there it is.

 To clear any confusion, music engine is tied to the TIMER interrupt and not the Vblank interrupt. But I think even an entry level programmer could see the issue here. All those bank mapping and saving, etc - none of it has anything to do with the DDA sample and the bank it comes from. And it's mapped every time @ 6991khz even if a sample isn't playing.

[touko]

Touko, this should give you an idea.... ;_;

LOL, it's crazy how it's very bad coded,i understand why it takes 30% 

[TurboXray]

Yeah, it's bad. Not just that, but the Hsync routine is a mess as well. I'm surprised this game isn't in perma slowdown.

[touko]

Yeah, it's bad. Not just that, but the Hsync routine is a mess as well. I'm surprised this game isn't in perma slowdown.

right, i'll say more it's impressive in fact,it's like running a maraton with a mobil home attached ..

[elmer]

I found over the years that good game developers, don't necessarily produce the most optimal code or design - to put it nicely. I've attempted to understand the thinking and philosophy of Japanese programmers in the 80's and 90's, and I'm just at a complete loss. I know there are factors keeping them from optimizing and fine tuning every little thing, but as a programmer and people that I known as programmers - there's this idea, this desire, this drive - that you want to create the best/fastest/whatever code possible; you want to push something to its limits. I guess that's a cultural thing and that's not what motivated most Japanese programmers at the time (with exceptions of course. There are always exceptions). 

 I read an interview with one of the guys that worked with Nintendo to get 3D on the SNES (originally meant for NES - the MARIO chip), and how he ended up moving to Japan and working directly with Nintendo programmers and producers for a number of years. He mentioned that game developers, like Miyamoto, would often take a game back to ground zero - many times during its development. If that was the case, I can see how optimizing stuff would be a waste of time during the development cycle. But to me, that shows that the producers were simply dictating to the programmers rather than working with them. Like I said, I really don't know.

I don't have the time (or interest) to write a long article to try to explain the history and the different development philosophies over the last 30 years ... but if you hang around the right bars surrounding GDC or E3 you'll probably find some old-timer to tell you about the realities of the industry.

Most programmers like a beer, and free beer definitely helps lubricate a discussion!

With your personal passions and capabilities, a big company would put you on the Engine team, where your talents would be used best.

In a small company you'd probably be a lead-programmer.

Either way ... you'll find that it's usually not cost-effective to over-optimize things, no matter how programmatically "beautiful" it is.

Having enough experience to know where to draw that line is something that usually comes with time ... and with working too many late nights in a row in order to hit a deadline.

When you're an amateur (or retired), then you get the freedom to do things however you like, and to spend as much time as needed to wring every-last-cycle out of a particular piece of code. As you already know, it's fun! 

Yeah, it's bad. Not just that, but the Hsync routine is a mess as well. I'm surprised this game isn't in perma slowdown.

And that's kind of the point ... in a lot of companies, "not-actually-causing-a-problem" really is "good-enough" when it comes to shipping a project.

When if comes to hitting a deadline, it's often cheaper-and-easier to just remove an enemy sprite or a background effect, rather than get a programmer to rewrite their code to make it faster.

Not all programmers are "great" ... and sometimes you'll find a "really-not-great" one on a team, particularly in the larger teams that some of the Japanese developers used.

[CrackTiger]

Considering the reception the game has enjoyed (including being technically impressive to most people), Air Zonk really was good enough as it is. But it's fun to imagine what could be possible on PCE if a team really pushed the hardware efficiently.

[touko]

@elmer: you're right, and i agree with you ..
But the code that bonk showed us, is really a pure shit, even with a deadline and commercial obligations,the reality is here .

Air Zonk really was good enough as it is

Of course, and it's the impressive parts IMO, nobody has thinked, how the code was bad when they were playing with this game(in fact it's just the opposite),i'am really surprised by the amateurism .

[TurboXray]

I don't think my XM PCM engine should really be compared to the average PCE game sound engine. Not that what I've done is amazing (it's not; anyone who can count cycles and optimize could do this - there's nothing revolutionary in my approach), it's just really tightly optimized. It looks more complicated that it is, in the source code, because of how it is made compatible for hucards - and PCEAS makes relocatable code a pain (this is where an intermediate object format would be great - linker). But it's just self-modifying code (nothing some PCECD games didn't do).

When you're an amateur (or retired), then you get the freedom to do things however you like, and to spend as much time as needed to wring every-last-cycle out of a particular piece of code. As you already know, it's fun! 

I think that's one of the really fun things about coding on these old consoles. Seeing what they could really do. I think it's safe to say that the most popular systems of their era, tend to have thee examples of games that push the system just because of the whole dynamic of competing developers, pushing that bar. Maybe the other half of coding for these old consoles is just to put out something people will want and play. Maybe even fulfilling that childhood dream of make of game for your favorite system. But the PC-Engine is kind of a gold mine for exploring what can be done with it. Sometimes the approaches are extreme, but it's still fun. 

Having enough experience to know where to draw that line is something that usually comes with time ... and with working too many late nights in a row in order to hit a deadline.

I always try to keep that in mind. It's all too easy to criticize after the fact. But there is always that part of me that feels; if you going to create something, present something, people are only going to see the end result. You can't go back fix it after the fact. And no amount of excuses (valid or not) will ever change the experience and impression of that presentation - what people got out of it. Trying to get a feel for where to draw that line, is difficult in my opinion. Especially when you can see nothing but promise and capability. Not just with coding, but with any sort of creation (literary works, art, music, etc). Finding balance with personal creations and being part of a team or company that sets restraints or limitations - it never leaves a completely satisfying feeling. I guess that's where hobbies are supposed to come in and fill that gap?

When if comes to hitting a deadline, it's often cheaper-and-easier to just remove an enemy sprite or a background effect, rather than get a programmer to rewrite their code to make it faster.

Sometimes, there are examples where companies should have taken that approach - lol. Instead, games flickered beyond belief or were plagued with slowdown (no console in specific). To me, that's a higher level design decision - the producer or managers ultimate responsibility.

But the code that bonk showed us, is really a pure shit, even with a deadline and commercial obligations,the reality is here .

Yeah. I try to limit my criticisms to stuff that's more on the extreme side of things. For PCE, it's usually sprite optimization - or rather approaching the system like an arcade machine with lots of sprite pixel line bandwidth.

Most programmers like a beer, and free beer definitely helps lubricate a discussion!

I don't know anyone in real life that codes. And if I did, it probably wouldn't be for old consoles. A beer and talking shop sounds great!

[ccovell]

Touko, this should give you an idea.... ;_;

Code Select Expand

    phy
    phx
    pha
 ...
    ply
    rti
 This is just the intro and extro code (TIMER routine). It's ridiculous because none of that overhead is needed for the DDA streaming part. And yet, there it is.

This looks to me like he's trying his darndest to make the game crash-proof in all situations -- for example, if you store MPR shadows somewhere upon interrupt, they could get overwritten when a second interrupt happens.  MPRs on the stack might be the fastest way when you have 2 or more simultaneous asynchronous interrupts going on.  (Although I didn't look at the rest of the Air Zonk code, so I dunno...)

[TurboXray]

I don't think it's testing for crashes (stack overflow). There's an internal state flag that prevents the routine from being called again, once CLI is executed inside it. So it can't be called inside itself. 

It's mapping banks for the main music routine to use. It's definitely a lot of banks. Maybe some of the samples are there as well (it doesn't have a lot of samples in the game - maybe it fits within 16k of that block). But it's definitely a large block map procedure.

 But my point is that the music routine only needs that support (banks) at the most - twice per frame. I.e. the music engine might run a song at 76hz instead of 60hz so you'll get a double call in a single frame once in a while. But that overhead is being called 116.7 times per frame, since the DDA routine is also using the timer interrupt. All they needed to do what prioritize for the DDA and map what's needed for what needs it, when it needs it. On the one or two instances it happens per frame, then map in that support.

 It's only one sample stream playing at a time. You only need to map in one bank for that. Maybe two if the tiny DDA routine really needs to be at $4000, but it should have been able to fit into the last bank. I dunno - priority and all that sort of thing.

[touko]

Yeah. I try to limit my criticisms to stuff that's more on the extreme side of things. For PCE, it's usually sprite optimization - or rather approaching the system like an arcade machine with lots of sprite pixel line bandwidth.

i can understand that using the largest sprites size (32x64) for exemple is the easiest way(DD2 and strider did that) to avoid using metasprites,but i'am for a minimum of clean and/or logical coding, especially by a (supposed) professional .
There is a big marging between crazy ass optimised code, and crazy ass unoptimised one,and i did not expect that coders spend many hours optimizing their routines,but definitively not at this point .

[TurboXray]

Touko: What if I said that I could give you 8 PCM channels at 6bit depth, each with full volume control, driven at 7khz... all with a total cpu resource requirement of 21.5%?

Btw, those 8 PCM channels still leaves 4 regular PCE audio channels remaining (a total of 12 audio channels). What would you do with all those sample channels? Mind you, they would be fixed frequency (no pitch bending). Also, those PCM channels would be mono. But the regular PCE channels would still be stereo.

[elmer]

8 PCM channels? That fast?  ... Cool! 

[touko]

What if I said that I could give you 8 PCM channels at 6bit depth, each with full volume control, driven at 7khz... all with a total cpu resource requirement of 21.5%?

I will answer ,it's you manfred trenz !! ;-)

It would be awesome of course .

[TurboXray]

it's you manfred trenz !! ;-)

Manfred Trenz!?!? But.. I don't have a beard ;>_>

So now I just need to deliver on the goods. I've written it all the routines, I just need make a split table and a volume table.

8 PCM channels? That fast?  ... Cool! 

I didn't think it was a big deal, because they aren't frequency scaled like fancy mod/xm channels. I always though it was apparent that the PCE could soft mix channels pretty fast, so I never really bothered with showing it off. But the other day, I was reading over the comments of single channel ADPCM demo I posted (I didn't write that demo, I just optimized/modified it to play faster; mednafen author wrote it).. and people seem to think they're impressive. The main point of those demos wasn't high frequency, high resolution PCM playback - but to demonstrate realtime decompression capabilities of the PCE (4bit storage for 10bit output is pretty decent savings). Then it dawned on me a couple of days ago.. I guess people really aren't aware of capabilities of the PCE to do soft mixed streaming samples. It's as if the 65x core were design to do this - lol. Super fast indexing, direct memory access, and look-up tables are the ingredients in the magic elixir for the 65x. Sprinkle a little self-modifying code and voila - power.

 Off topic of this, I was messing with frequency ranges from 7khz to 15.3 khz (256 samples per frame). And right about 9.5khz there is a sharp increase in clarity. The difference from 7khz to 9.5khz is bigger than any difference above it. Well, in response to this one clip. The Gameboy Advance "Sappy" driver, the driver Nintendo provided in the devkits, had 8 frequency scaled PCM channels feeding an 8bit DAC. There's two 8bit DACs, but if you're doing stereo it's still 8bit. The playback rate of that player is ~13khz. Advance Guardian Heroes on the GBA uses ~7.88hz playback. It kind of puts a perspective on things.


 All this assumes the direct write to DDA port method. I haven't explored abusing the waveform buffer.

 I'm also toying with the idea of maybe abusing some sort of bias into the analog signal, to create a lower frequency tone. Something bass-ish. An example would be if you ran a timer interrupt that always feed a DDA channel (even line zero data), but assuming the DDA channel really does respond to a ceiling of 3.58mhz, you could write two "pulse" values 40 cycles before the actual DDA sample. That pulse would exist at 178.9khz, changing at a rate of 7khz. Not really sure how it would sound, or how much of an impact it would have in terms of amplitude. Might not be worth the overhead, even if it is small. It needs testing. If it does work, it'll be one of those things that only works on the real system (unless an emulator can respond to DDA writes that fast).

 There are just so many different ways to create audio stuffs on the PCE. It's kinda like being a kid in a candy store. Which one to choose?

[touko]

There are just so many different ways to create audio stuffs on the PCE. It's kinda like being a kid in a candy store. Which one to choose?

Ahahah, too many ideas, and no enough time .

Manfred Trenz!?!? But.. I don't have a beard ;>_>

Lol true, but beard is not the most difficult skill to have . ;-)

Better quality for samples means more space in rom eaten,it's not a big deal if you have a 20MB(or more) card or AC, but definitively with classic ones.

[TurboXray]

Hmm.. this thread is soo off topic. I'll continue audio stuffs in the other pin'd thread.

 For those that can test the rom that I'll provide a link for.. just give me a few days.

[ccovell]

The Gameboy Advance "Sappy" driver, the driver Nintendo provided in the devkits, had 8 frequency scaled PCM channels feeding an 8bit DAC. There's two 8bit DACs, but if you're doing stereo it's still 8bit. The playback rate of that player is ~13khz. Advance Guardian Heroes on the GBA uses ~7.88hz playback. It kind of puts a perspective on things.

Apparently, the GBA DAC converts the PCM channels through PWM (at 65Khz) which degrades the sound quality *lots*.

I speak for myself, but one of the reasons not a lot of people hit the sample hardware (& make trackers, etc.) on the PCE is complete lack of musical know-how.

[TurboXray]

one of the reasons not a lot of people hit the sample hardware (& make trackers, etc.) on the PCE is complete lack of musical know-how.

You mean music composition?

[ccovell]

Not even composition -- if a person doesn't know how musical time signatures work, note lengths, etc. etc. then he wouldn't even know how to make an optimal music format or player.  You know, the stuff that aids in composition.

[touko]

on the PCE is complete lack of musical know-how. if a person doesn't know how musical time signatures work, note lengths, etc. etc. then he wouldn't even know how to make an optimal music format or player.

i agree with you chris,i'am able to do a sfx driver(the more easy part), but i'm not able to create any sfx(except white noise) from scratch,music (driver and compos) is simply out of questions for the reasons you said .

[elmer]

Not even composition -- if a person doesn't know how musical time signatures work, note lengths, etc. etc. then he wouldn't even know how to make an optimal music format or player.

I totally agree with this.

When I wrote my first music driver, I started off completely ignorant of all of those things, and it was only because I was working directly with a musician, and basically coding to his design requests, that I began to get even a simplistic understanding of how music was put together.

If I hadn't been working with that guy, I wouldn't have know where to start.

As a programmer, I still don't understand how musicians think and how they work their magic. 

You know, the stuff that aids in composition.

IMHO this is the critical part these days. To be productive, the musician must be given a way to easily edit the music that gives them rapid feedback.

There is plenty of cheap software to create music now, and I suspect that anyone working on a "new" driver needs to tie into (and extend?) some existing format that has a mature and comprehensive editor ... or else it may see little use. Most folks just don't like to have to learn completely new stuff in order to use something.

[TurboXray]

Depends on the musician. Some of the competing chiptune musicians nowadays want ultimate flexibility in sound design and aren't too afraid to get their hands a bit dirty.. in the mix of it (pun intended).

 But I think an interface that allows both a simplistic and easy approach, at the same time while also offering a complex side for more flexibility when the user gets acquainted with the setup - is the best approach. Nothing sucks more than, "oh! I love this engine but... if I could only do this.." Well, almost. I guess there could be worse things.

[TurboXray]

Ok guys, I need some testers to test this out on the real hardware:
http://www.pcedev.net/audio/SamplePlayer/test_sm_note_stereo.zip

Let it cycle through the high octaves, and then wrap around to octave one. You can stop it at octave three on the wrap around.

 I just want to make sure it works on other real hardware. This is just a single channel and note incrementing. I have other tests coming up with finestep and multiple channel stuffs.

[touko]

I'll test asap on my sgx .

EDIT: tested ,it works fine, there is some noise on the sample playback, but the pitch change works very well,but sound is only on the left speaker .

Display is ugly thought, the text is distorded .

[TurboXray]

Cool. Thanks Touko.

 I've been rewriting almost all the interface code to the PCM driver, so I need to retest a lot of things. Also moving stuff around, and making it as flexible as possible.

 I also have some print string libs that I'll probably make public. I haven't really seen any for PCE assembly (public).

[TurboXray]

Hey guys, I'm just writing up the doc/usage file so I can release this MOD-ish driver.. but I'm stuck as what to name it.

 Any ideas? Hu-MOD? Hu-XM? <- I picked XM in that example because the audio driver uses linear steps in frequency scale instead of period based scaling.

[elmer]

Any ideas? Hu-MOD? Hu-XM? <- I picked XM in that example because the audio driver uses linear steps in frequency scale instead of period based scaling.

HuTrack??? 

I'd suggest not calling it "XM" anything unless it's actually going to play existing XM mod files.

[TurboXray]

Yeah, the XM thing is pretty misleading. HuTrack is better than HuMOD, too.

[Nazi NecroPhile]

HuEargasm?