So then even the "in-game" version of that SoR track is more or less maxing out the cpu resources, because deflemask is simply a wholy inefficient method of producing PCE chip tunes, even when the end result isn't any more special than existing chip tunes from commercial games?
With the locked-loop code that's in the Deflemask .hes player, I can't see much reason why they couldn't support 44.1KHz or 48KHz samples, if they'd wished to have done so.
It's Deflemask's .hes code that's cr*p, and the reason that it can never be anything other than cr*p, is the ill-conceived decision to allow sample rates other than 7KHz, 8KHz, or 16KHz.
Those are the only ones that can be processed on the PCE with any measure of efficiency.
There's not really even anything wrong with deflemask's .hes exporter ... it was designed to do a single job, and not to be used in new game production. It fulfills its purpose, so I shouldn't really call it cr*p.
The .hes format itself is totally unsuitable for games.
It's just a recording of the register values that are sent to the PSG by each game's own sound driver.
No in-game sound driver ever worked like that (that I know of), because it is terribly inefficient.
Deflemask itself, as a tool, is a perfectly good way to develop music for new games, and has little
practical difference to how folks used to create music back-in-the-day, except that it's a lot more user-friendly with its GUI and its in-GUI emulated playback (what-you-hear-is-what-you-get).
It is actually by-far-the-best way that I've seen to develop music for these old systems, and beats the heck out of what was available BITD.
There are only a couple of "tricks" (that I know of) that the old drivers could do that Deflemask can't (currently), but that can be worked-around, and possibly added in future versions.
Just, for-gawds-sake, limit yourself to never using anything other than 8KHz or 16KHz samples in it (and hopefully 7KHz, someday)!
The biggest problem, at the moment, is that there is no way to get the music data out of deflemask and into a format that can be used efficiently in an in-game sound driver.
That's what I'm currently working on doing.
The way that the music notes, and timing, and effects data themselves are created is perfectly fine for in-game use, and has no important difference from how Japanese developers used MML back in the 1980s/1990s.
Remember ... pure MML data from a text file, or exported from 3MLE isn't usable with the PCE's System Card Player either. It needs to be translated/compiled into the right format for that driver to understand, and until Arkhan wrote Squirrel, nobody here could use that, either.
Now we just need to do the same sort of thing with deflemask data.
****************
While I continue to be mean to poor bonknuts about it ... there's no particular reason to say that the 16KHz sample rate is a bad one to use. It's just a balance of how much CPU power and memory space you have, and how you choose to use it.
My background prompts me to fight to keep as much time as possible available for the game itself, but that doesn't mean that it's always the right thing to do, especially at points where the game code isn't actually doing very much (i.e. title screens, etc).
It's not even a hard-and-fast rule for in-game use ... it all depends upon what your game code is doing. It's up to the programmer to know that, and for any development team to decide for themselves.
