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

[TurboXray]

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..

[NecroPhile]

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 Asylum]

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.

[TurboXray]

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.

[TurboXray]

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. 

[TurboXray]

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.

[TurboXray]

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).

There's a saying an old manager used to tell us, "Don't put your wallet in someone else's pocket". I always found that saying funny, because why in the hell would anybody do that? His point, though, was that we always think things from our own perspectives and expectations. This would be an example of me, doing just that. I can see the appeal of cooked format having almost zero overhead compared to a more complex player processing overhead. So.. that's where that line of thinking came from - haha (the demoscener or system pusher).

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).

But it wasn't hblank interrupt driven (from what I remember).  It was timer interrupt + timed code. In other words, you couldn't do anything else. That was my point.

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?

The only problem, is if no one keeps up with him and it's not apparent of where to find the older builds (of deflemask). It's not a big concern, but just something to point out.

[elmer]

His point, though, was that we always think things from our own perspectives and expectations. This would be an example of me, doing just that. I can see the appeal of cooked format having almost zero overhead compared to a more complex player processing overhead. So.. that's where that line of thinking came from - haha (the demoscener or system pusher).

That's perfectly valid thinking, and I'm just-as-guilty of looking at things from my own "game-production" perspective. 

You're right ... it's all just a case of trade-offs.

I'm pretty-confident that for general-purpose homebrew usage, any new driver should try to minimize both CPU and memory usage as much as possible, even if that has some effect upon the theoretical-best quality that the PCE might produce.

The System Card player certainly takes the same route!

But it wasn't hblank interrupt driven (from what I remember).  It was timer interrupt + timed code. In other words, you couldn't do anything else. That was my point.

OMG, that's horrible! 

The only problem, is if no one keeps up with him and it's not apparent of where to find the older builds (of deflemask). It's not a big concern, but just something to point out.

It's definitely a valid concern. It would be sensible to archive old versions just-in-case they disappeared from his forum, and are needed in the future.

But ... I'm still hoping that he's going to be sensible-enough to keep the version-upgrades reasonably compatible.

As I said ... from what I've seen *so far*, everything for the last few versions can be handled by a few simple "if" statemants in the converter code.

This is my workflow for creating music for PCE and MSX:

1) I open up FruityLoops

OK, I'm curious enough to try it out.

Since you're the "music" guy around here, I figure that I'd better see what you're seeing on the screen if I'm going to even *think* about trying to improve the process.

It's on sale at the moment, down from $99 to $69 at Musician's Friend ... so I'll bite.

Just in case anyone else is interested, that price comes up on Google, and on the Musician's Friend "Special Deals" webpage, but the price jumps up to $99 when you go to order it.

I telephoned them, and they were happy to sell it to me at the $69 price ... so make sure to do that if you're interested in it.

But now I wish that I hadn't looked at Musician's Friend ... it's too easy to get sucked into all the pretty toys. There's a really good "upgrade" offer at the moment for my copy of Cakewalk Sonar. 

[Gredler]

It's on sale at the moment, down from $99 to $69 at Musician's Friend ... so I'll bite.

Just in case anyone else is interested, that price comes up on Google, and on the Musician's Friend "Special Deals" webpage, but the price jumps up to $99 when you go to order it.

I telephoned them, and they were happy to sell it to me at the $69 price ... so make sure to do that if you're interested in it.

But now I wish that I hadn't looked at Musician's Friend ... it's too easy to get sucked into all the pretty toys. There's a really good "upgrade" offer at the moment for my copy of Cakewalk Sonar. 

I foolishly spent any wiggle room from the budget on black friday games, I should've picked this up but even 70$ is high for me to spend on a hobby right now, especially since I have no musical experience and will just be learning it to hope something decent comes out of it or at least train someone on a workflow. If its still on sale next payday I will try to pick it up then

A guy on the facebook threads posted a link to his "Turbo Graphics 16 Album" of music he made in deflemask, he sounded kinda interested in using it outside of an "album" but also said he has no idea what to do with his work to get it into mml. I tried to spark the discussion between he and Arkan, but not much dialog sprung from it. I was hoping we had a community musician to work with.

[elmer]

... especially since I have no musical experience and will just be learning it to hope something decent comes out of it or at least train someone on a workflow. If its still on sale next payday I will try to pick it up then

It certainly could just be a good end-of-year sale, who knows?

But be careful ... I shared a house with a professional-musician-turned-programmer for a few years, and ended up with $1000's of dollars worth of beautiful equipment that I never learned to play, except for the factory-demo. 

I suspect that you need a certain exposure to it all as a kid in order to really be able to pick it up later as an adult.

But that's the "creative" side.

A "technical" understanding of what goes on isn't that hard for anyone with a reasonable brain.

A guy on the facebook threads posted a link to his "Turbo Graphics 16 Album" of music he made in deflemask, he sounded kinda interested in using it outside of an "album" but also said he has no idea what to do with his work to get it into mml.

There is no way for him to do that at this time.

Deflemask has NO native import or export capability to/from MIDI or MML.

It's one of the biggest problems with it from my POV.

But, it can hopefully be worked-around, eventually.

Do you have a link to that guy's work?

This is one of my favorite deflemask tracks at the moment ...

Noroi no Fuuin - Bloody Tears
https://youtu.be/GIvxiusv1v8

[DildoKKKobold]

Noroi no Fuuin - Bloody Tears
https://youtu.be/GIvxiusv1v8

You know, you raise an interesting point with this, one that has bothered me for a long time.

While music appreciation is subjective, there are pieces of music that are objectively good. If we look at just the nes, no matter what top 10 list you look at, the same 3-5 tracks appear, in some random order, 90% of the time.

Mega Man 2: Dr. Wily Level 1
https://youtu.be/aFeL7kTw2CU

Duck Tales: Moon Theme
https://youtu.be/G_80PQ543rM

Castlevania 2: Bloody Tears
https://youtu.be/EjazC45Qkww

Silver Surfer
https://youtu.be/FYjHdt254lU

Here's the thing about music. No one can make you like it. It doesn't matter what someone tells you about a music's complexity or history, you either like it or you don't. But here is the crazy thing about this. Despite the variety of opinion on what is good or bad music, the majority opinion tends to agree that the tracks listed are the 'best' of the NES. This means, despite the variety in taste, there is something intrinsic that can make a music track exceptional.

To me, that is basically magic. As someone with near zero music ability, there is a zero percent chance that I could ever create something that most people would consider exceptional. I just wish I understood what made the difference between a 'good' track on the NES (which there are plenty of) and something truly exceptional, which time and time again, are demonstrated to be the best of the best, despite how they are remixed (as elmer showed.).

I guess, in short, I'm just in awe of truly amazing music.

[TurboXray]

All this rambling

Apparently someone uploaded a "longplay" of Squirrel on youtube... LOL!

Edit: Opps.. oh yeah, here's the link: https://youtu.be/RTBUz0LDvoI

[Gredler]

All this rambling

Apparently someone uploaded a "longplay" of Squirrel on youtube... LOL!

Edit: Opps.. oh yeah, here's the link: https://youtu.be/RTBUz0LDvoI

Dannnnnng who is the mystery person, and does any one recognize the tune or is it original? A masterful performance.

[touko]

i love this tune made with deflemask :
https://youtu.be/6DA6JAfDqIw&index=29&t=20s&list=FLZ9bAVsaYiNrpRuFATEv9Vg

[Psycho Punch]

All this rambling

Apparently someone uploaded a "longplay" of Squirrel on youtube... LOL!

Edit: Opps.. oh yeah, here's the link:

Someone needs to add it to pcedaisakusen.net, that would go nicely along my System Card clears.

[elmer]

i love this tune made with deflemask :
https://youtu.be/6DA6JAfDqIw&index=29&t=20s&list=FLZ9bAVsaYiNrpRuFATEv9Vg

I was more impressed with it before I saw the crazy list of samples that it uses ...
[tt]
Sample  1 : NTSC loopbasup.wav
Size      - 83148 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  2 : NTSCloopbasdown.wav
Size      - 83230 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  3 : snarelong.wav
Size      - 21145 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  4 : 47741__wimwam__clap1.wav
Size      - 12536 samples
Rate      - 16000 Hz
Pitch     -     7
Amp       -    50
Bits      -    16

Sample  5 : NTSCloopbas.wav
Size      - 82252 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  6 : NTSCloopbasB3.wav
Size      - 82961 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  7 : 0n0  loopbasG#3.wav
Size      - 83376 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  8 : NTSCloopbasF#.wav
Size      - 82487 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  9 : 191600__nabz871__kick-drum-hard-1.wav
Size      - 24462 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample 10 : Dance Snare.WAV
Size      - 14138 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample 11 : reversecymbal.wav
Size      - 66150 samples
Rate      - 22050 Hz
Pitch     -     7
Amp       -   100
Bits      -    16

Sample 12 : Cymbal02.wav
Size      - 78704 samples
Rate      - 32000 Hz
Pitch     -     7
Amp       -   100
Bits      -    16

Sample 13 : c64tomC#.wav
Size      -  3088 samples
Rate      - 32000 Hz
Pitch     -     5
Amp       -   100
Bits      -    16

Sample 14 : c64tom.wav
Size      -  7042 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16
[/tt]

[TurboXray]

i love this tune made with deflemask :
https://youtu.be/6DA6JAfDqIw&index=29&t=20s&list=FLZ9bAVsaYiNrpRuFATEv9Vg

I was more impressed with it before I saw the crazy list of samples that it uses ...

Sample  1 : NTSC loopbasup.wav
Size      - 83148 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  2 : NTSCloopbasdown.wav
Size      - 83230 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  3 : snarelong.wav
Size      - 21145 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  4 : 47741__wimwam__clap1.wav
Size      - 12536 samples
Rate      - 16000 Hz
Pitch     -     7
Amp       -    50
Bits      -    16

Sample  5 : NTSCloopbas.wav
Size      - 82252 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  6 : NTSCloopbasB3.wav
Size      - 82961 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  7 : 0n0  loopbasG#3.wav
Size      - 83376 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  8 : NTSCloopbasF#.wav
Size      - 82487 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample  9 : 191600__nabz871__kick-drum-hard-1.wav
Size      - 24462 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample 10 : Dance Snare.WAV
Size      - 14138 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Sample 11 : reversecymbal.wav
Size      - 66150 samples
Rate      - 22050 Hz
Pitch     -     7
Amp       -   100
Bits      -    16

Sample 12 : Cymbal02.wav
Size      - 78704 samples
Rate      - 32000 Hz
Pitch     -     7
Amp       -   100
Bits      -    16

Sample 13 : c64tomC#.wav
Size      -  3088 samples
Rate      - 32000 Hz
Pitch     -     5
Amp       -   100
Bits      -    16

Sample 14 : c64tom.wav
Size      -  7042 samples
Rate      - 22050 Hz
Pitch     -     6
Amp       -   100
Bits      -    16

Yeah, but that's not bad at all. The "beat loops" he has, translates into a single pattern frame at the most in length. I.e. those longer loops (which are the largest ones there) are like 13kbytes if you converted to 7khz 8bit output (5bit in but in bytes). If you can get the timing down right, beat loops are a nice aid IMO. That's what I'd be doing if I was using ADPCM for drum stuff on the PCE with PSG; beat loops.

 And I'm not sure he's even using all of them (the HES in a raw wave editor would suggest he's not).

[elmer]

Yeah, but that's not bad at all. The "beat loops" he has, translates into a single pattern frame at the most in length. I.e. those longer loops (which are the largest ones there) are like 13kbytes if you converted to 7khz 8bit output (5bit in but in bytes).

I think that you're mixing up "samples" in that printout with "bytes"

Sample  1 : NTSC loopbasup.wav
Size      - 83148 samples
Rate      - 22050 Hz

-> 27716 samples @ 7KHz

And sorry ... but 7-or-so 27KB samples is effing horrible IMHO! 

Nobody BITD would allocate half of their cartridge space for a bunch of instrument samples.

It's the same kind of "retro" bullsh*t as all of those "NES-like" games made in Unity on the PC that try to claim that they're developed with the old hardware restrictions, and then include megabyte textures or put hundreds of sprites on the screen.

I have a lot more respect for people like Mirichin9801 and JIR-O who are more interested in keeping their tracks a bit more "honest" with respect to the limitations that musicians were really faced with (and worked-around) back when all the original tunes were made that people love so much.

[TurboXray]

Yeah, but that's not bad at all. The "beat loops" he has, translates into a single pattern frame at the most in length. I.e. those longer loops (which are the largest ones there) are like 13kbytes if you converted to 7khz 8bit output (5bit in but in bytes).

I think that you're mixing up "samples" in that printout with "bytes"

Sample  1 : NTSC loopbasup.wav
Size      - 83148 samples
Rate      - 22050 Hz

-> 27716 samples @ 7KHz

And sorry ... but 7-or-so 27KB samples is effing horrible IMHO! 

Nobody BITD would allocate half of their cartridge space for a bunch of instrument samples.

It's the same kind of "retro" bullsh*t as all of those "NES-like" games made in Unity on the PC that try to claim that they're developed with the old hardware restrictions, and then include megabyte textures or put hundreds of sprites on the screen.

I have a lot more respect for people like Mirichin9801 and JIR-O who are more interested in keeping their tracks a bit more "honest" with respect to the limitations that musicians were really faced with (and worked-around) back when all the original tunes were made that people love so much.

Ahh samples not bytes. But still 7 x 27k = 189k.

 Hardly a dent in later gen 16bit softs though. Maybe for PCE where hucards didn't get a chance to evolve, but just looking at SF2 mapper 256k is only 10% of the total rom size. There are roms out there where original devs devoted space to whatever importance. IIRC, SF2 on the PCE has over 120K worth of samples. Bloodshot on the Megadrive is an 8megabit cart and 768k of that is precalculated code paths to render the game! Night Creatures on the TG16 wastes a lot of rom space on a large 128x128 dynamic tile set animation, as well as just using uncompressed tiles/sprites. Batman on the PCE is 384k and the sample pack (just for music instruments) is 64k. I'm sure official devs BITD have "wasted" rom resources on all kinds of things. Supposedly that "Sega" sample at the beginning of Sonic 1, took up 1/8 the cart space. And that was only used in one instance of the game. A dev even developed a mapper with a built in FM chip and shoved it into a Japanese Famicom game. I dunno. I just don't see this chiptune with some beat loops as a big deal.

 I like pushing the system. That means audio and video. It's ok in my book.

[touko]

I was more impressed with it before I saw the crazy list of samples that it uses ...

Effectively,not really the PCE standard .

And sorry ... but 7-or-so 27KB samples is effing horrible IMHO! 

i agree , but with bit packed, you can reduce this by 1/3 =>18 ko (still big, but more acceptable)

Of course like bonk said with a SF2 mapper and a 32/64 Mb hucard it's easily dooable,and with a good PCM driver and clean samples even at 7khz you can do an impressive PCM quality for a 8 bit system,better than MD @14/16 khz ones(with stef's driver), due to hardware .

[OldRover]

A dev even developed a mapper with a built in FM chip and shoved it into a Japanese Famicom game.

This reminds me of the special sound chip shoved into Pitfall II on the Atari 2600. Even back then, people were doing new things to overcome the inherent limitations of the system they were working with.

[TailChao]

Of course like bonk said with a SF2 mapper and a 32/64 Mb hucard it's easily dooable,and with a good PCM driver and clean samples even at 7khz you can do an impressive PCM quality for a 8 bit system,better than MD @14/16 khz ones(with stef's driver), due to hardware .

You still have to be a little careful with ROM size since once you pass 2MB it gets more difficult to find affordable 5V components (4MB, 8MB+ NOR Flashes are increasingly uncommon). There are workarounds of course, but nothing is ever "for free."

This reminds me of the special sound chip shoved into Pitfall II on the Atari 2600. Even back then, people were doing new things to overcome the inherent limitations of the system they were working with.

It's even easier to do stuff like this nowadays. Microcontrollers are cheap, and Cypress has some that are both equipped with analog outputs and 5V tolerance.

[touko]

You still have to be a little careful with ROM size since once you pass 2MB it gets more difficult to find affordable 5V components (4MB, 8MB+ NOR Flashes are increasingly uncommon). There are workarounds of course, but nothing is ever "for free."

Ah, is not as easy as i though then .. 
Do you think that even nowadays,it's not affordable ??

[TailChao]

Ah, is not as easy as i though then .. 
Do you think that even nowadays,it's not affordable ??

I wouldn't phrase it as "not affordable" to have a huge NOR Flash, but rather it's good to be aware of what restrictions it would impose on the manufacturing end so you can consider alternatives.

Generally, once you get over 512KB - 1MB, 3.3V NOR Flash is much cheaper. Once you get over 2MB it's nearly impossible to find large quantities of 5V tolerant parts, and what you can find is usually new-old-stock. So you'd need level shifters and a regulator on the cartridge.

If you're adding a mapper, you need either a CPLD or several 74xx components.

Sometimes it's cheaper to add more RAM to the cartridge and depack data to it rather than using a larger ROM and more complex mapper. I ran into this with the game I'm working on now.

Once you get into several megabytes of data, it might be best to use a combination of NOR Flash + RAM + SPI Flash + Mapper + Level Shifters.


Basically it is good practice to think ahead for what parts are available and what are not. Sometimes the "best" option is completely different now than what you would do 25 years ago.

Edit : But again, the PCE is quite competent on its own, so there's that.

[touko]

thanks for this explanation .

Another question, do you think the Hucard format by himself, was a big limitating factor for larger ROMS than a classic one, like on MD/snes ??

[TailChao]

Another question, do you think the Hucard format by himself, was a big limitating factor for larger ROMS than a classic one, like on MD/snes ??

Honestly, no. Most HuCards are chip-on-board, which is cheaper in volume and when you have the right manufacturing setup. Using larger Mask ROMs isn't a big deal as the dies are still much smaller than the card dimensions. I mean really large volume, though. Hundreds of thousands minimum.

I think the biggest factor was the prevalence of the CD-ROM format on the platform.

Again though, I didn't work for Hudson or NEC. So I can't definitively speak for what they were or were not trying to do.

[esteban]

Another question, do you think the Hucard format by himself, was a big limitating factor for larger ROMS than a classic one, like on MD/snes ??

Honestly, no. Most HuCards are chip-on-board, which is cheaper in volume and when you have the right manufacturing setup. Using larger Mask ROMs isn't a big deal as the dies are still much smaller than the card dimensions. I mean really large volume, though. Hundreds of thousands minimum.

I think the biggest factor was the prevalence of the CD-ROM format on the platform.

Again though, I didn't work for Hudson or NEC. So I can't definitively speak for what they were or were not trying to do.

I think you are correct about the manufacturing process and its benefits.

Sure, we don't have all the info. We might never know if there were unusual, historically unique factors affecting manufacturing (such as low yields--initially--for larger mask ROMs...or the logistics of upgrading/revising manufacturing/fabrication processes).

However, these issues would have been resolved in time, especially if larger-size mask ROMs were an absolute *necessity* for PCE to compete.

[spenoza]

Well, since we're still chatting about Sqirrel and MML.

[Arkhan Asylum]

LOL

What the fuck?!

SCHLAUCHI posted a longplay of Squirrel!?   It's just GNOP's tune on repeat forever!  LOL.


and Atlantean is 300$ on eBay?!

I AM A CELEBRITY.

lololo


Anyway, yeah, when you go MIDI, you lose the loop structure.

It's relatively easy to put back in with MML, though, since it supports patterns and loop/repeating.

No problem there.

Elmer, did you try FruityLoops in the end?  I believe I posted the links to a tutorial-ish thing in here already.

[elmer]

Anyway, yeah, when you go MIDI, you lose the loop structure.

It's relatively easy to put back in with MML, though, since it supports patterns and loop/repeating.

No problem there.

Errrr ... no "insurmountable" problem there, but a bit of a PITA for the musician that has to recreate those loops by hand-editing an MML text file once the tune is finished.

"Yes", it's how things used to be done, but it's not even remotely "modern-day-friendly".

Unfortunately, I can't think of any alternative except for the MOD/tracker style of music creation, which has it's own set of problems.

Elmer, did you try FruityLoops in the end?  I believe I posted the links to a tutorial-ish thing in here already.

It arrived last night, but it may be some time before I install it and try to get it working.

Michirin9801 joined the forum here a few days ago, and he's creating some of the best deflemask PCE music that I've heard.

So I'm currently a bit more inspired to put some time into continuing to rip-apart the deflemask output format and see if it can be converted into something that would be usable by my music-driver (when I port it over to the PCE). 

[Gredler]

So I'm currently a bit more inspired to put some time into continuing to rip-apart the deflemask output format and see if it can be converted into something that would be usable by my music-driver (when I port it over to the PCE). 

[Arkhan Asylum]

Its a little tedious, but not really complicated to add the looping in, at least.   I'd imagine someone who uses trackers and music software would be able to do it pretty quickly since the syntax is really easy.

IE:  ChannelName:  ***MML STUFF**** /ChannelName/  <<< Creates an endless loop of that channel.  Great for efficient drum usage.

or [2(pattern name)]  <<< Loops the pattern twice. 

It's unfortunate that going to MIDI loses the concept of repeating and looping.   Maybe there is a way, but, FruityLoops outputs a time-line of patterns.   You also lose the looping when you go MOD to MIDI, though.   MIDI is always an unrolled output. 



Do you have examples of the Deflemask PCE music from michirin9801 person?   I want to hear.

EDIT:  Oh, I found them.

Yeah, they sound good, especially because of the samples.

I was hoping for something besides covers though, lol.


That Eurobeat Night of Fire song cracked me up.   Good stuff.

[elmer]

IE:  ChannelName:  ***MML STUFF**** /ChannelName/  <<< Creates an endless loop of that channel.  Great for efficient drum usage.

I imagine that it's easier for the original musician to see and edit these things than it is for me as just an ignorant programmer.

Being able to take advantage of the inherent repetition in music is really important for keeping the music data small.

Yeah, they sound good, especially because of the samples.

Well, according to his post in response to Chris Covell's music-analysis video on YouTube, he doesn't use samples much.

I *believe* that things like the drums are just the classic rapidly-changing noise+wave combination.

But since I can't find any of his tracks to actually download, I can't rip them apart to confirm that ... but I'd love to have the chance to do so!

I'm surprise that you didn't mention his Misty Blue cover ...

【PC-88】Misty Blue - Opening - Turbografx 16/PC engine arrange【Deflemask】

[Arkhan Asylum]

IE:  ChannelName:  ***MML STUFF**** /ChannelName/  <<< Creates an endless loop of that channel.  Great for efficient drum usage.

I imagine that it's easier for the original musician to see and edit these things than it is for me as just an ignorant programmer.

Being able to take advantage of the inherent repetition in music is really important for keeping the music data small.

I would think a musician using a tracker should be able to manage adding the looping back to MML.   If they can manage the goony ass effect columns of a tracker, they should be OK, I would hope.    Looping is one of the easiest parts of it, I think.   Outside of ABCDEFGing.

Well, according to his post in response to Chris Covell's music-analysis video on YouTube, he doesn't use samples much.

I *believe* that things like the drums are just the classic rapidly-changing noise+wave combination.

But since I can't find any of his tracks to actually download, I can't rip them apart to confirm that ... but I'd love to have the chance to do so!

I'm surprise that you didn't mention his Misty Blue cover ...

【PC-88】Misty Blue - Opening - Turbografx 16/PC engine arrange【Deflemask】
https://youtu.be/SgziA7yvTmc

Some of the tunes seem to have had samples, but I was also clicking on more than just the PCE tunes.

I hadn't seen the Misty Blue one.   That's pretty awesome.   Yuzo's compositions would sound good on a bunch of toy xylophones and kazoos.   That dude's a machine.

I wonder if these are from scratch, or if some reference is used.  When I was messing around testing/demonstrating that Squirrel was actually working, I was just yanking MIDIs off VGmusic.com to throw through and fiddle around. 

One of my next goals personally for PCE music is to make some more elaborate music either as standalone stuff, or for upcoming games.   

I intentionally kept the music in Insanity and even Atlantean relatively simple/semi repetitive and to the point, mostly to avoid having it be a distraction while playing, since they are arcade-y games.

Insanity doesn't even have good drums.   I hadn't figured out how to do a good one yet, and we didn't really have time to be dicking around.   The soundtrack has re-mml'd ones with actual drums instead of a little crunchy noise.

You can definitely get some pretty convincing drums without samples.   I really like the kick drum I use in GNOP, Reflectron, and Atlantean.   

[touko]

This one is really good too :

[DildoKKKobold]

Would a sample-based engine allow us to get more realistic sound effects? It'd be nice to have realistic sound effects, rather than trying to reproduce a cat meow or screech using musical notes.

[Gredler]

This one is really good too :
https://youtu.be/mumE3EWRW2w

Very good, I love this

[TurboXray]

Would a sample-based engine allow us to get more realistic sound effects? It'd be nice to have realistic sound effects, rather than trying to reproduce a cat meow or screech using musical notes.

Sample-base synthesis would allow you to get sounds (instruments) that you normally couldn't with the PCE chip.

 What you're referring to is just simple sample playback. Completely different thing and has nothing to do with music. You record a cat meowing, and then play the sample (think wave file) on the PCE... whenever. It's not really an engine. More like a driver in the simplest of terms. Such a driver can exist independent of any music engine.

[DildoKKKobold]

Would a sample-based engine allow us to get more realistic sound effects? It'd be nice to have realistic sound effects, rather than trying to reproduce a cat meow or screech using musical notes.

Sample-base synthesis would allow you to get sounds (instruments) that you normally couldn't with the PCE chip.

 What you're referring to is just simple sample playback. Completely different thing and has nothing to do with music. You record a cat meowing, and then play the sample (think wave file) on the PCE... whenever. It's not really an engine. More like a driver in the simplest of terms. Such a driver can exist independent of any music engine.

Don't they use the same chip? I'm not sure how the sound chip works, but a sample would have to disrupt the music to play. Also, I'm not sure how I understand how you'd ever play a sample, since you'd have to recreate it with the various waveforms available on the PC Engine.

[OldMan]

It'd be nice to have realistic sound effects, rather than trying to reproduce a cat meow or screech using musical notes.

If you can settle for low quality.....
Convert the effect down to 5 bits, split it into 32-byte chunks, assign a wave number to each, and cycle through them. (load wave n, play note, load wave n+1, etc) It's not gonna be high-quality, but someone else was trying to do this a few years ago.  I remember fixing squirrel to get it work.

BUT...

What you're referring to is just simple sample playback.

...a sample would have to disrupt the music to play.

Not necessarily. We haven't figured it out yet, but there are 2 channels on the psg that can be set to "direct-dda" mode. In theory, you could use those for sample playback. Would require a streamlined irq routine, I think.

[Gredler]

Thanks Old Man!

If you can settle for low quality.....
Convert the effect down to 5 bits, split it into 32-byte chunks, assign a wave number to each, and cycle through them. (load wave n, play note, load wave n+1, etc)

I'll take your question if we can settle for low quality as a compliment, because if you've seen my abilities so far to make this game I think it'd be a given that we have to settle with low quality ;)

Really though, I would be interested to at least try this and see what it sounds like, but have no idea where to start.

Is there documentation for loading wav files, and would you convert them to ascii then back to smaller wav files? I googled this a bit and it looked like a rats nest of reasoning and workflows for converting wav to 5bits.

Not necessarily. We haven't figured it out yet, but there are 2 channels on the psg that can be set to "direct-dda" mode. In theory, you could use those for sample playback. Would require a streamlined irq routine, I think.

This sounds promising, I can get us royalty free sound effects and wavs made by homies to use.

Thanks for the progress and further discussion, this and the huc thread are my favorite reading of the day lately

[TurboXray]

Would a sample-based engine allow us to get more realistic sound effects? It'd be nice to have realistic sound effects, rather than trying to reproduce a cat meow or screech using musical notes.

Sample-base synthesis would allow you to get sounds (instruments) that you normally couldn't with the PCE chip.

 What you're referring to is just simple sample playback. Completely different thing and has nothing to do with music. You record a cat meowing, and then play the sample (think wave file) on the PCE... whenever. It's not really an engine. More like a driver in the simplest of terms. Such a driver can exist independent of any music engine.

Don't they use the same chip? I'm not sure how the sound chip works, but a sample would have to disrupt the music to play. Also, I'm not sure how I understand how you'd ever play a sample, since you'd have to recreate it with the various waveforms available on the PC Engine.

Have you ever looked at a wave file? A just is 1D array. The axis is time. So, in principle, read in a sample from an array, write it to a port. Of course, PCs have code that does this for you (to put it simply). On the PCE, if you're not using someone else's code, what you need to do is find a way for the CPU to read the sample, in this case just a BYTE, and write it to a DAC (digital to analog device; a port).

 On some systems, there is hardware that grabs the byte it needs at whatever interval (time). The PCE doesn't have this. So you need to use the Timer Interrupt, which runs independent of the main cpu code. It grabs bytes from memory and writes it to a whatever channel DAC you choose. There are 6 channels on the PCE, you can stream up to 6 samples (wave files). It won't stop the music, but like sound FX - it will silence that channel while the sample is streaming. Think of the Timer interrupt routine like a second thread or additional core. Except it's not free. Overall it will take away from some cpu resource, but you won't ever need to incorporate it directly into your main code.

 If it's someone else writes it, then you can just simply interface with it: call function to tell the driver to play a sample. Simple as that. So yeah, it takes some overall cpu resource - but it doesn't "stop" your code to play a whole sample/stream.

 There are a lot of cool things you can do with interrupts. You know that point in your code where you want for the vsync() pass? Think about how much cpu resource is just going to waste. I've written a system on the PCE that has a main processing thread, and a background processing thread. The background processing thread runs during the wait loop part of a frame. I usually put decompression stuff there (or anytime I need data, but know that I need it X amount of frames ahead of time). On top of having an interrupt playing samples. And video interrupt doing full screen scanline effects. Interrupts are awesome.

 Just to note: You could do the main thread/background thread thingy in C. You need to move main loop to be called inside V-int. It gets a little tricky to setup, but it's doable. 

Not necessarily. We haven't figured it out yet, but there are 2 channels on the psg that can be set to "direct-dda" mode. In theory, you could use those for sample playback. Would require a streamlined irq routine, I think.

All channels, or any specific channel and any number of them, can be set to DDA mode. Or do you mean from the BIOS psg player?

[TurboXray]

Is there documentation for loading wav files, and would you convert them to ascii then back to smaller wav files? I googled this a bit and it looked like a rats nest of reasoning and workflows for converting wav to 5bits.

I only have like a bazillion and 1 converters and drivers for this sort of thing, for the PCE. If you guys end up using Squirrel, I can even hack the TRIQ for my own hook to play samples. Unless Old Man and team get this figured out in time when you need it, hit me up when you guys want to do sample streaming support.

 But if you do the hack method in squirrel that Old Man is talking about, it's not just lower sample quality - you'll also get a 60hz-120hz loud buzz/hum that accompanies it. You might not hear it on the SGX or CoreGrafx I models, but you'll hear it on other systems (Duo, TG16, original PCE, Coregrafx II, Duo-R, etc)

[Psycho Punch]

Wait a second.

I thought that the channels 0-1 were the proper "sample" channels. Are you saying that it's possible to play them on any channel?

Does anyone have a proper doc for audio?

[TurboXray]

Yes. All channels. Are people really ignorant of PCE audio stuffs??? Nobody reads the PCM threads I post either? I thought DDA mode was pretty common knowledge.

 PSG.txt from Magickit docs (I think it's in HuC PCEAS section too). Everything should be correct in that doc, except the LFO scaling part.

[TurboXray]

Just thinking out loud...

So I was looking over the TIRQ code for BIOS player. To hack in sample support, it seems that simply setting the PSG player tick to 1 and have the hook do the down counting and call the PSG player when that expires, for tempo control. Otherwise, outside the PSG player call - the main TIRQ hook outputs samples to whatever channel DAC.

 Those are just the small details. I'm not sure how much space the ripped player takes up in squirrel package, but I think it would be a better idea to keep using it instead of the built in one of the sys card (I assume it switches and uses that for CD projects - haven't looked that far ahead). That would easily solve how to introduce sample support into MML.

 The CD psg player (bios rom version) can be hacked for the hook that I described, but I'd need to know a few more details of how to optimally incorporate sample support for sound FX (aka not drum kits). Otherwise the unoptimal way would be to just reserve one channel for all sample playback. It's crude, but it should work. Again, this is for sound FX - not sample instruments (drumkits, orch-hits, etc).