MML: What are people's actual complaints with the damn thing

[Bonknuts]

The issue has always been the supporting tools around it.

This.   This is literally why I said "f*ck it" so many years ago, and we went with something that would be functional..

 And honestly you deserve a lot more credit than I've ever said. Sometimes I get caught up in the criticism of smaller details, that I forget to publicly acknowledge the larger picture. I mean, I'm thinking it - I just don't say it because sometimes I feel its implied.

Oh.  I didn't know you finished that compiler.   That was awhile ago.  Where is it?   

 Probably sitting on a hard drive somewhere - lol. It was an exercise in writing something like that I hadn't done before. I let a few chiptune sceners from.. some IRC channels mess with it, test it - but nothing ever came of it other than I finished it. It wasn't supposed to be a tool for the PCE community, just both an experiment and to complete the music driver project.

Because, I see a few things going down.
1) It will be made by non-musicians*
2) Egos and overconfidence will f*ck up an open source project pretty bad.  (Please, never say "I could've done that in a day" or "a solid month".  It almost always leads to foot-in-mouth, lol)
3) Endless chasing of the dragons will lead to it never being done. 

 I totally understand. But by advanced, I didn't mean the really craze shit. The really crazy shit, is for people to do for themselves; write their own driver and toolset for it.

 Things like: more envelopes. I like the idea of synths and in particular FM. Not that I want FM on the PCE, but I think envelope control concept makes instrument sounds easier to understand.

 - envelope to control waveform updating (happens while a note is in play)
 - envelope to control when vibrato or tremolo kicks in
 - envelope to control the amplitude of vibrato and tremolo envelopes
 - envelope to control the speed of vibrato and tremolo envelopes
 - envelope to phasing (i.e. detune - linear though)
 - envelope to control pitch slides (which can terminate if you use slide-to-note option)
 - all envelopes to support key on/off
 - volume ADSR envelopes with key on, that allows you to set global decay
 - a linear finetune step between notes (no exposure to the underlying period system)
 - other obvious things like transpose
 - ADSR envelope in relation to frequency (based on octive:note:finestep)
 - detune should be done with finestep linear notation, and is always the same regardless of the note or octave - that includes vibrato and pitch sliding
 - envelope for panning each channel.
 - all envelopes should have loop points for the key on, which can be placed anywhere.
 - envelopes should not be restricted to "ADSR" format: they should be points on a time line. You can construct an ADSR envelope, do so something more advanced. How many points there should be, is up to the design stage.
 - ability to enable time stretching of envelopes relative to note and octave position

 And sample support (DDA, not waveform). Samples that have loop points. Not only loop points, but "key on" for loop points. I.e. A single sample has three parts: attack, sustain, decay. These are three individual samples parts that make up the whole sample. It doesn't need to have three parts: It can be AD or just simply A (regular samples). Super easy to do. Note: Batman on the PC-Engine does this - it's where I got the idea from. No frequency scaling or any of that fancy stuff.

 That would be my entire suggested blue print for a music engine driver, minus the obvious stuff that's in every music engine driver.

 That's the kind of stuff I'm talking about. Some of this stuff might sound like it'll eat up some resource, but the resource is only relative to the stuff you use. If you're not using an envelope that time stretches something else (which is one 16bit multiplication operation per 'point' calculation - the delta is created but doesn't need constant multiplication: only when a new "point" is encountered), then it won't be processed.

[Arkhan]

Hahaha ... yeah ... there's our continuing misunderstandings and different generational-uses of terminology to deal with. At least we're reasonably polite about them these days.

I'm always ... polite.   I think.   Blunt/whatevery, but never ill-intenty, lol.   Most people that talk to me online think I'm a total a$$hole until they meet me in person and hear me talk, and go "oh.".

Half the time I'm swearing, I don't even realize I'm doing it.  Nailed it.

In "practical" terms, even if it were OK to legally distribute a modified version of the SquirrelPlayer with new features, it would be absolutely pointless without changes to the Squirrel MML compiler in order to support the new features.

I think that it's just best to leave your Squirrel package the way that it is ... it accomplishes exactly what you wanted it to do, and it's an excellent way for folks to develop sounds for the System Card player.

If, and it's a huge "if", there's a reason to develop a new sound driver, then it will need new tools to go with it.

I would prefer to always support MML, myself.   In theory, squirrel could output stuff for a different engine.    I would always want to go that route, though.

but you could just the same write a new compiler entirely for a different thing.

It's not "gray", it's full-on "black" if someone uses the "SquirrelPlayer" in a HuCard.

But, once again, in practical terms, Konami are very unlikely to give a damn. There's not even enough money/pride involved for them to bother digging up a lawyer from the crypt and having them write a C&D letter.

And that's the process if you piss someone off enough ... a "Cease & Desist" probably at the same time as contacting your ISP to have all your web pages taken down under the DMCA.

Well, I am not sure HOW we might piss off Konami.   Tobias bootlegged Dracula X, complete with stealing their art and logos, AND THEIR GAME, and has been reselling them in boxed sets.  Konami's reply was "cool, we want one too".

If THAT doesn't piss them off, I highly doubt using the system card player is going to make them mad.  lol.

That's why I'm calling it a gray area...   I think Konami has the rights, and literally gives negative f*cks about it.

That's definitely a noble goal ... but has Tobias shown *any* interest in copying people's homebrew?

Does Tom's Rockman game count?
He's also profiteered off of fan-translations.

Anything that looks like something he can dupe people into paying $$$$ for, he grabs and produces.

He's a douchebag.

That would be the "sensible" course ... except for the "Elephant in the Room" in that there isn't anyone clamoring for it, or projects that need it, or any musicians lined up wanting to use it.

Squirrel exists because Arkhan wanted to use it for his own projects.

HuSound exists because TailChao wanted something better (to him) than the System Card player for his music.

I'm just not detecting the pent-up desire for something else.

Has anyone here even *tried* using TailChao's HuSound to make a tune???

I've never tried using HuSound.   I haven't had a reason to yet.  When it was still being made, or whatever, it required "programming" stuff, and I was like "ehhhh", but since there's a MIDI way to do it, it's tempting to try.   I don't have an itch in my pants to write music like a C program.   I already did weird shit like that on the C64 with the one synth program that had this ASM-scripty language to program the SID, and it was *awful*.

It sounded cool in the end, but holy crap, it was not worth the effort, lol.

and yes, there really aren't .... people making PCE games, so Deflemask works fine for people that just want 32byte beewoopdoodlebops to show people on YouTube.    Before that, people were just sampling the PCE directly, or using their own 32 byte waves to sound close enough, and just using basically any tracker.    It's like how people were sampling C64 on the Amiga because they were attached to that shweeeeooooooeoooooooeeeeeooooo noise that Galway basically invented, lol.

I'd say what we really need are people wanting to make games.   There's Me, and Rover.  And Gredler, and Cabbage / Touko when they're not busy, basically?  lol

Yep, if a tracker is used as the user-interface, then outputting into a command-string format would seem to be the best option to me, rather than just trying to process a MOD data in realtime on the PCE.

That's pretty-much what Arkhan was saying earlier with his comment about exporting a MOD into MML format.

Yep. 

I guess that's my real gripe with trackers.  Stop trying to f*ck around with playing back that nonsense directly.  Make it something more practical before you do that part.


How performant is that XM player thing Tom made? 



FWIW:  You can make new envelopes and such with Squirrel.  You do have a bit of control over stuff, but you really have to just sit and experiment with it.

That's generally how you get sounds that are good, anyway.   Real synths, you twist knobs and sliders.

MML, you just change numbers and listen.


One day, maybe I'll f*ck around with putting samples into Squirrel, but it would only exist for the HuCard player, obviously.   

I think the most obvious use of samples is for tom rolling. 

[Bonknuts]

How performant is that XM player thing Tom made? 

 Which one? This:

Or this (bare bones):
http//www.pcedev.net/HuPCMDriver/HuPCMDriver_Demo_HuXMPlay.zip

Or this.. hybrid thing (command string that has specific XM features):

 I wouldn't use any of them. Dude.. stick with what you have and hack in sample support, or lets do an open source music engine. Or we all race to make the best one and the losers can suck it. Either way, none of my music drivers have universal appeal. They were all tailored with very specific goals in mind.

 Just to note: My HuPCMDriver is not a music engine. It could work along side of the PSG player or any other music engine. But it's specifically if you wanted the PCE to have "sampled-based synth" capability. I like the thing. I'm proud of the design (the whole thing is octave:note:finestep format - no weird period system or frequencies. Also does transposing. And the whole thing is linear scale in frequency). But it's not a music driver. It's a sound driver to emulate hardware that's not part of the PCE.

[Arkhan]

Either.   I was just curious.  It's always been my impression that using XM/trying to do all that directly will basically eat too many resources to make games a viable thing.

[TailChao]

Either way, none of my music drivers have universal appeal. They were all tailored with very specific goals in mind.

This is probably true of most sound drivers and their associated toolchains for dinosaur hardware.
Which is not a bad thing, really. I don't think there should be so much paranoia related to writing audio tools.

Whatever works best for your needs and allows the product to ship is what should be used.

[Bonknuts]

Resource wise? Nah. XM format is pretty simple. It has envelope support for volume and pan, and that's about it. It does support mapping different 32byte waveforms to different keys, so you have timbre scaling on note basis.. if that's your thing. It also allows swapping a waveform mid note (which is an FX). Other wise, the FX columns is pretty easy to implement. I'd say it's probably about the same as the syscard PSG player, or possibly a little lighter in resource. It's not resource heavy simply because you can only do a limited number of "FX" per line entry. Some FX allow two things at once, but that's about it.

 I just kind of lost faith in it, because it's not directly a PCE XM format spec. Besides, command string arch allows for more advance things than fixed pattern with column FX. The idea of using envelopes to shape an instrument, as operators, seems more natural and powerful to me. It's not that tracker can't do this (FM trackers for instance), it's just that none do for the PCE (deflemask kinda... moved into that direction, but it's nowhere near what I'm talking about). Chasing the dragon..

[Necromancer]

I'm always ... polite. 

ROFLCOPTER!

[Sunray]

I have no experience with MML, in my understanding it's just a container format for music just like MID. I don't care about that as I hate working DAW tools.

For my game I run my XM player on PC and convert every tick (or every other tick if you don't want full resolution) to an absolute PCE period and volume value and save that to a file. Then on the PC Engine I would just read a byte that tells me what's in the current tick, and if'ts not empty I read and apply the PSG states (period, volume).

This way I support all effects and envelopes without any runtime overhead. The downside is that it might use a bit more ROM than other solutions.

Currently I can generate the file but not yet play it. I haven't worked on my game for a few months for reasons but I hope to continue on it next year.

[Arkhan]

That sounds similar to what the first iteration of Squirrel was doing.  It was frequency/duration based and would plug stuff right into the appropriate spots to get it to play.

[Bonknuts]

For my game I run my XM player on PC and convert every tick (or every other tick if you don't want full resolution) to an absolute PCE period and volume value and save that to a file. Then on the PC Engine I would just read a byte that tells me what's in the current tick, and if'ts not empty I read and apply the PSG states (period, volume).

 Ohh.. a cooked format. Like VGM. If you're doing that, why not just use Deflemask and re-purpose its VGM output?

[Sunray]

Well, isn't the purpose of programming to do things yourself? Plus I already have an accurate XM/S3M replayer so outputting this data was easy.

[Bonknuts]

Well, I mean if you're using trackers - deflemask has more capabilities related to the PCE. But nevermind, deflemask is doing some retarded things with both its cooked formats (when it comes to samples). So that makes the whole thing moot.

 Forget about all of that. What is the average size of your output files?

[elmer]

Well, I mean if you're using trackers - deflemask has more capabilities related to the PCE.

Hahaha ... yeah, like letting people use 32KHz 16-bit samples that are 160KB long in the song that I'm looking at! 

I hope that he downsamples that for his playback, or else musicians will have wildly crazy expectations of what the PCE sounds like! 

But nevermind, deflemask is doing some retarded things with both its cooked formats (when it comes to samples). So that makes the whole thing moot.

I've not looked at the "cooked" format that he outputs ... what is he doing that seems weird to you?

The raw .dmf format seems reasonably straight-forward, but it's massively-wasteful in terms of memory usage, and would need some processing to turn it into a command-string (or MML) format.

But at least he has documented the .dmf format, and has a thread on his forum that links to a number of different revisions of it. 

[Bonknuts]

He down samples the res but not so much the sample rate. I found samples of 16khz in the HES files. That's completely unusable in a game. Whoever wrote the HES part, pretty much just wrote a PCE specific version of VGM format instead of a proper cooked format (aka, 7khz timer plays the samples). I dunno. I didn't bother with it passed that.

 If we write a DMF converter to something a little more realistic structure wise on for the PCE, chances are he'll update the PCE spec later on. So people would have to know what version to use, etc. I'm not sure he keeps a selection of versions or just the latest build.

 The cooked format version isn't a bad idea, and it does kinda future proof things if he adds new PCE features. But the format as it, won't work. It needs another layer of compression (because something like 100k is too large for a single song without samples), and the sample system needs to be redone. It might be easier to look at the PCE VGM format and convert from that.

[elmer]

The cooked format version isn't a bad idea, and it does kinda future proof things if he adds new PCE features. But the format as it, won't work. It needs another layer of compression (because something like 100k is too large for a single song without samples), and the sample system needs to be redone. It might be easier to look at the PCE VGM format and convert from that.

I don't know how-on-earth you'd go back from that cooked format and get any sensible compression on it. 

I'll be interested in hearing the results if you choose to go down that path! 

In my experience, chiptune data (basically transformed-MML) only needs approx 2KB per tune (+samples).

He down samples the res but not so much the sample rate. I found samples of 16khz in the HES files. That's completely unusable in a game.

So (I assume) he's playing 16KHz samples at 1-per-hblank (nominally 15.7KHz). The 2% error shouldn't be noticable on short instrument samples.

I guess that's fine for their purpose, but not what would normally be used in-game (either 8KHz for 2-hblanks-per-sample, or 7KHz if using the timer interrupt).

Either way, sample rates could be modified as part of a conversion process.

If we write a DMF converter to something a little more realistic structure wise on for the PCE, chances are he'll update the PCE spec later on. So people would have to know what version to use, etc. I'm not sure he keeps a selection of versions or just the latest build.

I think that there's just the latest verion on the main page link, but you can get old versions by going to the "Changelogs" section of his forum.

All the DMF files contain a version number, and the changes in the last few versions of the file are so minor that they can be easily dealt with during conversion.

Going forward ... what's the problem if he improves things? Wouldn't you want things to get better for users? Perhaps he could add a 7KHz sample rate option?

Sure ... it would be a bit of a PITA to keep on updating the converter, but that's just life in the software-industry.

If the converter is open-source, then someone can either fix it, or people have to use the older version of the DefleMask.

*******************

The alternative is to keep on going down Arkhan's path and having people use modern MIDI sequencers to create their tunes.

That's an absolutely viable way of doing things, as Arkhan and a few generations of games developers, have shown.

But it's not neccessarily a "nice" way of doing things if the composer can't hear what things will sound like without going through a number of time-consuming conversion steps.

I don't remember if Arkhan has already said that he's made a batch file or simple action that he can run inside his sequencer that will save the current MIDI file and run a batch file to automatically convert it and run the resulting test ROM in Mednafen.

That's the minimum workflow that I'd expect for musicians/composers these days.

But ... a standard-MIDI-file is still not the *perfect* format, because it's linear, and you lose all of the looping information about the tracks.

Remember ... tunes are naturally repetitive, i.e. verse/chorus/verse/chorus, but on an even lower level.