PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: Arkhan on November 20, 2016, 08:36:34 PM
Title: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 20, 2016, 08:36:34 PM
All this rambling about HuC/MML/Mod players has me wanting to ask some questions, as a survey.
So
1) What actually scares you about MML? 2) How is MML any scarier than trackers, which are just columns of bullshit that look like a bad session of VIM that happens to make sounds? 3) Are you aware that you can use any fancy-as-piss DAW to craft PCE songs, and then simply MIDI-->MML---> Run it through Squirrel (for example) to get it to play something on PCE?
I am just trying to sort out why people run to the hills or completely give up on it. It get's such a bad rap for no reason, I think. It's not isolated to these scene. There are people everywhere who go OMFG MML JESUS f*ckING CHRIST, NO. GIVE ME TRACKER.
Also, perks to using MML for PC Engine:
1) If you did everything in a DAW, you accidentally made a CD soundtrack too probably 2) If you're using Squirrel, you get the magic of sound effects. See: Atlantean. It's got chiptunes and SFX. 3) It's super usable for creating a game.
This is my workflow for creating music for PCE and MSX:
1) I open up FruityLoops 2) I use the mouse cursor to pet the cute girl that is my wallpaper in FruityLoops 3) If PCE, I make a 6 channel song. If MSX, I make a 9 channel song. 4) If PCE, I use Chip32 to approximate instruments. If MSX, I use an MSX PSG VST, and an OPL2 FM VST. 5) I make the songs with MIDI controllers/piano roll editing. 6) Ok cool, it's done. I hit the "midi" button and export a MIDI 7) import midi into 3MLE. Every channel is conveniently converted to MML 8) If the songs are long, I use 3MLE's optimize button to shrink em up. 9) Paste into Squirrel file, or Musica file for PCE and MSX respectively. 10) Hit a button or two. Done.
I made YouTubes about this before. It's stupidly simple. https://www.youtube.com/watch?v=XeZTqqN0FtM https://www.youtube.com/watch?v=yy9gNPfTmgU
I really want to basically dispel all these myths about MML, and get you goons to use it and get somewhere with tunes.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: ccovell on November 20, 2016, 10:19:20 PM
1) It looks like Brainf*ck. You say it's meant to be created by DAWs, but it's still a textfile, which itself makes peering into it (and recoiling in horror) an inevitability. 2) Columns are the operative word, a very good thing. Not every MML editor I've seen offers columns of notes that are editable in those columns. Trackers' emphasis on hex values for effects is bullshit indeed. 3) I'm not a musician, so never used one. No comment.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: touko on November 21, 2016, 12:24:04 AM
More or less like ccovell said . A deflemask user can make music for any systems supported by the tracker,and it's obviously easy to find some deflemask musicians than MML . I'am not a musician too, and i don't care if musics are mml or tracked, i only need musicians .
For now my fav goes with MML because there is a functional driver.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 21, 2016, 05:05:20 AM
1) It looks like Brainf*ck. You say it's meant to be created by DAWs, but it's still a textfile, which itself makes peering into it (and recoiling in horror) an inevitability.
But, you shouldn't be creating the song in MML. You can, but that would require you to be the kind of composer that is capable of sitting with a pencil and a blank sheet of staff paper to compose songs.
It was designed for people who at least understand sheet music. It wasn't really designed for you to just start smacking at it until it sounds like music.
Quote
2) Columns are the operative word, a very good thing. Not every MML editor I've seen offers columns of notes that are editable in those columns. Trackers' emphasis on hex values for effects is bullshit indeed.
The MML file can be formatted however you want. You can (and should) define patterns, and then stamp them down in each channel, similar to what you could do in a tracker. The Atlantean music files are very tidy like this.
You don't have columns. You have channels broken up by headers. You can even put commentblocks to separate channels. Every pattern that you define can be named whatever you want.
I'd go so far as to say if you do all of this, the file is clearer than looking at a song in a tracker.
Running through a converter produces some goobery looking stuff, but you can do a top-down sweep and reformat it pretty simply to make it readable.
Quote
3) I'm not a musician, so never used one. No comment.
I think this is the most important trait of people who are pretty averse to MML. You're not musicians. So, you probably can't read sheet music, which then implies MML is going to be gibberishy too.
To put it bluntly, the problem is you guys, not MML. You could manage MML with a little bit of effort, though, I think.
http://3ml.jp/
^^^^ This program has tabs for each channel. It shows a visual piano roll representation of the MML that you type into the editor.
It has a play button so you can hear it.
I honestly think this is more feature-full and intuitive than a tracker. You get that visual representation instead of columns of nonsense that happen to make a eurowank demotune if you hit play, lol.
It seems one of the big scaries is that people want live-note-editing and immediate results.
You can get that with 3MLE, or this goofy thing:
http://benjaminsoule.fr/tools/vmml/
BUT BE WARNED: THIS TOOL HAS THE OCTAVE SHIFT COMMANDS BACKWARDS FOR WHATEVER REASON.
I grew up using trackers and crap like Octamed to make music. Once stuff like FruityLoops came out though, I stopped, because the Amiga software was always a bit clunky and unintuitive.
but, here's the funny thing.
You can use a tracker, and still use MML to get music going in your games.
FOUR songs from Insanity are old MODs I had on a floppy disk that I made on an Amiga 500. I transferred them to PC, opened them in MODPlug, exported MIDIs, and turned them into MML....
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: DarkKobold on November 21, 2016, 05:25:11 AM
I hope none of this is 'inspired' by Catastrophy. Our problem has been finding a musician willing to work with us at all. We found one of Gredler's friends, who seemed unreliable, and lazy. Gredler was just trying to give him something to do.
We found the musician for Haunted Halloween 85 and 86, but he wanted cash up front.
Cabbage has been doing a few sound effects/midi conversions on the side, but he has his own projects. Catastrophy isn't a priority to him.
So, MML is not our problem. Interested musicians are.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 21, 2016, 05:33:43 AM
I hope none of this is 'inspired' by Catastrophy. Our problem has been finding a musician willing to work with us at all. We found one of Gredler's friends, who seemed unreliable, and lazy. Gredler was just trying to give him something to do.
We found the musician for Haunted Halloween 85 and 86, but he wanted cash up front.
Cabbage has been doing a few sound effects/midi conversions on the side, but he has his own projects. Catastrophy isn't a priority to him.
So, MML is not our problem. Interested musicians are.
Catastrophy didn't spark this.
People have been flailing and afraid of MML since before Insanity was finished, lol.
I am just curious what people's actual problems are, because some of them might be a tad unreasonable, or completely fixable with a bit of effort.
I'd like to help people get more into the swing of things, because it's pretty frigging useful.
What kind of music do you even need for Catastrophy. I can do it lol
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on November 21, 2016, 06:33:19 AM
I think things being "intuitive" or not, is kind of irrelevant once you have experience with whatever procedure or toolset. What matters, is efficiency or the perception of it. What matters is the learning curve. And what matters is the community behind the toolset. There's a large community behind trackers, so that's a valuable resource. If the community support is there, then things such as asking questions, figuring out techniques, and looking at other people's work. That's what matters. There is not one concept or idea that fits all.
Also, this:
Quote
https://www.youtube.com/watch?v=XeZTqqN0FtM
You claim this is stupidly simple, but look at all the conversions you have to do, and things you need to check and verify. You know what's simpler than that? Not having to convert a damn thing. If I were to use Deflemask right now - then that's it. There's no conversion processes. No avoid this, or fix or change this in during step X, etc. Not only is it one and done, it has ALL the advantages of a tracker interface - "what you hear is what you get".
People get comfortable with what they know, and don't like to change something that already works for them. And add to the fact that PCE really isn't in demand as a development system, don't except people to go out of their comfort zone just to produce something on this target platform.
Until you make a program interface that has NO conversion process, and has "what you hear is what you get" - one step process, then you're not providing a competing product on the same level. I don't know why that's so difficult to understand.
The fact that your "player" and Squirrel app doesn't support "samples", is a pretty big disadvantage IMO. It's one thing not to use samples, it's an entirely different thing not to have support for it.
And I'm with touko: I really don't care what the format is, as long as it can produce whatever PCE devs have done so far - then who cares. But knowing chiptuners, at least relative to the PCE era stuffs, you need to know your audience. Rant and rave all you want, and trust me I agree with most of the philosophy of your rants on this subject, it won't change the fact.
You want people to make music on the PCE? Make something like Fruity Loops that directly outputs PCE music files. A program that is ONLY specifically PCE. A program where "what you hear is what you get" type interface. Because chiptune musicians, the good ones, are always tweaking the sound to get something interesting or specific, and down to even just one part of a song. Visual presentation of this is important. Dicking around with MML output, is not its equivalent.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Gredler on November 21, 2016, 06:37:41 AM
I am not a musician, so it's hard to explain why I could not get a great squirrel song, as I generally can't get a great song anywhere else either, so my complaints should be chalked up to inability to compose music and lack of knowledge on the subject entirely.
The complaints I've gotten from the friends who tried to make music are probably less to do with squirrel specifically but making actual chip-driven-tunes, but I'll try to convey their trepidation's as best I am able.
1) The gap between in editor instrumentation/sound and in game. The two guys that I've asked to help have had issue finding a VST or instrument that is similar to the squirrel preset wave forms. The youtube video (https://youtu.be/VrS8JejvKK8) is appreciated but ultimately not very useful for finding a consistent sound between authoring software and the rom playing on emulation/hardware, especially considering how different each envelope and octave shift affects the sound of waveforms.
2) Timing monitoring and beat/bar/note consistency The guys also had issues with their songs getting out of sync due to dropped notes and or note lengths. The songs always spiraled out of coherence and would "break". If there is anything that I was happy with about my song I made with squirrel it's that I was able to overcome this by using macros/bars that I could loop. It still gets out of sync, I think I am 1/4th a note off somewhere, but it was very methodically planned and created straight in mml. I have not been able to make a good song converting a midi to mml because of this, the only "decent" music I've been able to get out of squirrel is by hand coding the mml.
3) Getting a midi that was compatible with a clean conversion to mml. The midis we've found royalty free have been so outside of the 4-6 channel midi requirements that I was not able to get anything to sound even half decent (also due in part to the above two issues, the songs even when truncated to 4 channels would eventually sound way off in instrumentation, and in timing). Without creating a midi with converting it to mml in mind, in a specific application (which so far only seems like 3mle and fruity loops are confirmed as working tools for this), it seems very difficult to recreate midis in squirrel as mml. Perhaps if I worked with a musician who could create a specifically planned mid that we could pipe through 3mle and "spot check" like you mention in the tutorials, but without knowing the sheet music/what I am looking for, converting from a random midi to mml looks like converting Russian to Portuguese - I can't understand either, so spot checking is impossible because I don't know what I am looking for.
Like I said - I am about as far from a musician as you can get and still be attempting this (DK is probably further off, but refuses to even attempt it) - so many grains of salt have to be taken with my issues with squirrel.
This might be the root of all evils. I'm a cheap (read: baf) guy and have not wanted to drop $100-200 on a music creation software sweet I would barely know how to use, but maybe if I could create midis with this all of our troubles would be over. :P Buying stuff makes you better at things right?
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 21, 2016, 07:05:13 AM
You want people to make music on the PCE? Make something like Fruity Loops that directly outputs PCE music files. A program that is ONLY specifically PCE. A program where "what you hear is what you get" type interface. Because chiptune musicians, the good ones, are always tweaking the sound to get something interesting or specific, and down to even just one part of a song. Visual presentation of this is important. Dicking around with MML output, is not its equivalent.
I think the expectation that someone in the scene write some sort of full DAW-esque program specifically for PCE is both selfish, and borderline stupid, and misses the point of what I said completely.
Writing something like that is a MASSIVE undertaking and realistically would require a small team, and to what end?
It's not simple. People have been banging away trying to do similar things on all kinds of machines for years.
The closest to successful was Prophet64 on the C64, but the player code for that is so resource intensive that it can't feasibly be used for anything but listening.
Also, you can already get a visual representation of a song with MML if you put it into 3MLE. Once you know where you want effects to be at, placing them into MML isn't really any different than putting them into a tracker. You do realize this, right? Dicking around with MML is the same as dicking around with hex columns in a tracker. Don't sit and tell me a tracker's effects column is somehow better. It's not.
On the topic of "chiptune musicians, the good ones", what do you think I do with my stuff? The deep ass kick drum sound I got wasn't an immediate result. Nor were the lead sounds in Reflectron, or that weird bass noise I made.
It's not really much different to compose a song, get it playing, and THEN go through and sprinkle fancy shit onto it like slides, vibrato, and such. You often start talking about sound design as opposed to musical composition. They are two different things, but you conflate them. This is an incorrect thing to do.
Example: MIDI. What is MIDI? It's a bunch of digital data that jams into any listening device and THEY ALL SOUND DIFFERENT. You compose and end up with a MIDI. You can sit and fiddledick with sounds all you want once you send it into some kind of synthesizer or software program. You're going on about step B, missing the point completely about step A.
The conversion process required is hardly that difficult. You make it sound like it's all super difficult and cumbersome. It isn't. Maybe it is for someone who doesn't understand music or the software, but it's all pretty commonplace stuff to worry about. You will have the same kind of issues in a tracker, honestly. Your drums are mapped to notes. If you don't make the MML drums to the same notes, you'll have to go update them later.
Whoop. Dee. Doo.
I don't think it's fair to knock something as bad because you may not get it. It's probably better to try learning it, as opposed to dismissing it, possibly because it's not what all the cool kids are doing.
The thing of it is, you're talking about hobbyish/trackertune scene people and their wants/desires. When you have a workflow that "has ALL the advantages of a tracker interface", you forgot to mention that it also includes all of the disadvantages of a tracker interface. Trackers are not the be all end all, despite what apparently everyone seems to think. I think writing a song in a much more sophisticated program, and then outputting midi, going to MML-->PCE is a much smoother process than trying to compose shit in a tracker.
Why did you put player and samples in quotes, anyway?
You have to realize, a lot of commercial software had songs written much differently than how you seem to think.
Hubbard wrote songs for C64 games on real instruments, and then converted things over to the C64.
ALOT of musicians did this. Mega Man's tunes were made this way, even. Do you think they had some visual representation of all of this crap? no. They didn't. I would go so far as to say people like Galway, Hubbard, and Follin are "the good ones" you speak of.
Some of Hubbard's noises were accidents due to bugs in the SID chip. It wasn't him sitting with some fancy ass program where he jiggled stuff around until he went OH COOL.
1) The gap between in editor instrumentation/sound and in game. The two guys that I've asked to help have had issue finding a VST or instrument that is similar to the squirrel preset wave forms. The youtube video (https://youtu.be/VrS8JejvKK8) is appreciated but ultimately not very useful for finding a consistent sound between authoring software and the rom playing on emulation/hardware, especially considering how different each envelope and octave shift affects the sound of waveforms.
Yeah. Chip32 is free, and you can get approximate sounds out of it. You can also take those waves from Chip32 and make them as custom waves in Squirrel, to get the same sounds out of them...
Once you have the song playing though, it's really a matter of just fiddling with wave parameters and listening to the song again. Building the ROM and relaunching is slower than getting an immediate playback, but, it's... not that bad. Maybe an extra second or two.
Quote
2) Timing monitoring and beat/bar/note consistency The guys also had issues with their songs getting out of sync due to dropped notes and or note lengths. The songs always spiraled out of coherence and would "break". If there is anything that I was happy with about my song I made with squirrel it's that I was able to overcome this by using macros/bars that I could loop. It still gets out of sync, I think I am 1/4th a note off somewhere, but it was very methodically planned and created straight in mml. I have not been able to make a good song converting a midi to mml because of this, the only "decent" music I've been able to get out of squirrel is by hand coding the mml.
Did they use 3MLE to verify that the timings were all correct? Sometimes, all that is needed is adding rests to finish off a measure so things stay in sync. If someone has an example, I can show you.
Othertimes, it's just a matter of importing with a different quantization setting in 3MLE when you import the midi.
Quote
3) Getting a midi that was compatible with a clean conversion to mml. The midis we've found royalty free have been so outside of the 4-6 channel midi requirements that I was not able to get anything to sound even half decent (also due in part to the above two issues, the songs even when truncated to 4 channels would eventually sound way off in instrumentation, and in timing). Without creating a midi with converting it to mml in mind, in a specific application (which so far only seems like 3mle and fruity loops are confirmed as working tools for this), it seems very difficult to recreate midis in squirrel as mml. Perhaps if I worked with a musician who could create a specifically planned mid that we could pipe through 3mle and "spot check" like you mention in the tutorials, but without knowing the sheet music/what I am looking for, converting from a random midi to mml looks like converting Russian to Portuguese - I can't understand either, so spot checking is impossible because I don't know what I am looking for.
lol, yeah, lots of MIDIs have polyphony on channels, so converting them is going to suck. It's better to write stuff with 6 channels, no polyphony in mind.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Gredler on November 21, 2016, 08:14:29 AM
Yeah. Chip32 is free, and you can get approximate sounds out of it. You can also take those waves from Chip32 and make them as custom waves in Squirrel, to get the same sounds out of them...
I have not used any music making tools (only coded directly in mml) but I have suggested Chip32 to the musicians I've talked to. These guys don't seem to understand the correlation between squirrel youtube video's wave #'s, and what they're making in Chip32. One of the three guys I've talked to was using "renoise" and apparently was not able to get Chip32 working with that. Like I abridged above, I will need to bite the bullet and purchase some music creation software if we can't land a musician who can be shown chip 32 and make usable midis :P
Once you have the song playing though, it's really a matter of just fiddling with wave parameters and listening to the song again. Building the ROM and relaunching is slower than getting an immediate playback, but, it's... not that bad. Maybe an extra second or two.
This is what I suggested to them as well, and how I came upon the music we have now except I was trial and error build and testing with MML programming by hand, since I don't have any music generation tools outside of free 3mle
Did they use 3MLE to verify that the timings were all correct? Sometimes, all that is needed is adding rests to finish off a measure so things stay in sync. If someone has an example, I can show you.
Othertimes, it's just a matter of importing with a different quantization setting in 3MLE when you import the midi.
I don't think any of the guys except for cabbage can do this. I have been able to do it with the royalty free midis I've downloaded, but like you say below here, it's basically giberish because the midis weren't made with 6 channel polyphony in mind :(. I just need to make some midis and go through the process knowing how it works so I can learn this timing verification process
lol, yeah, lots of MIDIs have polyphony on channels, so converting them is going to suck. It's better to write stuff with 6 channels, no polyphony in mind.
Thanks for the help and tips, maybe we can get a musician to chime in and join the conversation :)
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 21, 2016, 08:25:35 AM
If you want help making Catastrophy music, I could help. How many songs do you need? What kind of songs?
The timing verification process is pretty easy. You just have to look at the LAST note for a channel, and make sure it ends on the end of a measure. Otherwise, it will slowly fall out of sync. If you find that there's a gap, just add rests until the little white line indicates that you're at the end of the measure.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Gredler on November 21, 2016, 08:40:40 AM
If you want help making Catastrophy music, I could help. How many songs do you need? What kind of songs?
The timing verification process is pretty easy. You just have to look at the LAST note for a channel, and make sure it ends on the end of a measure. Otherwise, it will slowly fall out of sync. If you find that there's a gap, just add rests until the little white line indicates that you're at the end of the measure.
Thanks for the offer, we're not worthy! :D We are just a couple guys "curious if we can make a hucard game" for education and fun, no rush or urgency to get it done quickly. We can continue the discussion in a more appropriate thread, but yeah we will want tunes and sfx in the game eventually :D
I honestly think the issue with MML isn't MML, it's the lack of interested parties - where are all the musicians at? You can't be the only one who wants to make rad games and has elite keyboarding skills
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 21, 2016, 08:52:03 AM
I don't know. They're all using trackers, and waiting for someone to support them, I guess.
Once I finish Inferno I could probably goober something together pretty easily if you tell me about what you want out of it.
lol. use some of the demo tunes that came with Squirrel for now. I feel like the Shadow of the Beast example is a good choice.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on November 21, 2016, 12:10:23 PM
You bitch and moan about why people are or aren't doing this or that, and when given answers when you ask why - you're response is complain/attack/insult.
I'm not sure what want. Do you honestly want to know people's opinions and perspectives, or are you just interested in knocking people down or insulting them? It's like there's no compromise with you, unless it involves agreeing 100% with you.
Usually, when you posts stuff like this (one man crusade to rid the world of trackers), I try my best to ignore it and let your rant play itself out. I figured this time you wanted some honest feedback. My mistake. Whatever. Screw everybody else, right? By all means, continue on with whatever this post is supposed to be.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on November 21, 2016, 01:53:47 PM
You have to realize, a lot of commercial software had songs written much differently than how you seem to think.
Hubbard wrote songs for C64 games on real instruments, and then converted things over to the C64.
ALOT of musicians did this. Mega Man's tunes were made this way, even. Do you think they had some visual representation of all of this crap? no. They didn't. I would go so far as to say people like Galway, Hubbard, and Follin are "the good ones" you speak of.
Yes, it was all done very differently ... and Martin, Rob and Tim were all assembly-language programmers that wrote their own music drivers.
They knew exactly how the drivers worked, and they could tweak them whenever they wanted any changes.
In those days, the game programmer just received a binary blob with a few documented entry points to call. The musicians kept their code and techniques to themselves.
Oh ... and don't forget ... they were also being paid a living-wage for making those tunes. :wink:
That's just not how the computer-music world, and especially the homebrew game-world operates anymore.
What matters, is efficiency or the perception of it. What matters is the learning curve. And what matters is the community behind the toolset. There's a large community behind trackers, so that's a valuable resource. If the community support is there, then things such as asking questions, figuring out techniques, and looking at other people's work. That's what matters. There is not one concept or idea that fits all.
That is the world of today ... musicians don't write their own drivers. They don't need to. They just want to jump in, learn some reasonable-to-use tools, and get on with making music.
Writing something like that is a MASSIVE undertaking and realistically would require a small team, and to what end
Yep ... to what end?
It's already been done, and it's called deflemask!
Sure, it's far from perfect, but it seems to be meeting most people's needs, and it keeps on slowly getting better.
Just take a look on YouTube for chiptunes made (in the Western world) with MML rather than a tracker of some kind. I found a one, a video by you ... and that was pretty much it.
That was a search for "mml chiptune".
Then I searched for "deflemask chiptune", and pages of hits came up, lots of them for PC Engine tunes.
It really doesn't matter if your workflow is better, or if your results are better ...
... if a homebrew developer wants a chiptune from anyone other than you, then it's probably going to get done in deflemask.
Personally ... until there's a working deflemask player for the PCE (if ever), I'd just recommend that homebrew developers use the CDROM format and either ADPCM or CD-AUDIO for music.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 21, 2016, 02:10:37 PM
You bitch and moan about why people are or aren't doing this or that, and when given answers when you ask why - you're response is complain/attack/insult.
I'm not sure what want. Do you honestly want to know people's opinions and perspectives, or are you just interested in knocking people down or insulting them? It's like there's no compromise with you, unless it involves agreeing 100% with you.
Usually, when you posts stuff like this (one man crusade to rid the world of trackers), I try my best to ignore it and let your rant play itself out. I figured this time you wanted some honest feedback. My mistake. Whatever. Screw everybody else, right? By all means, continue on with whatever this post is supposed to be.
LOL, what? Seriously. What. in. the. f*ck?
Where did I attack or insult? Or complain? You are going to need to point out where, because I really do not see it. I suggest maybe going back and re-reading what I said a few times, because you've clearly misunderstood. I'm not bitching and moaning. I am trying to figure out and HELP people get to a better place with MML.
This starts with asking "what's the problem", and possibly pointing out "hey, that's only a problem because you're doing it wrong" or "you're thinking about this the wrong way. check this out."
With regards to what you said, I just pointed out the flaws in your statements that were honestly a bit short sighted. You made incorrect or misinformed statements like you often do with this topic.
[ul][li]Where you tried to draw a line and separate two things, I demonstrated that they are actually fairly equivalent. [/li][li]Where you conflate two separate parts of the music making process, I pointed out that they are different.[/li][li]Where you bring up "the good ones" with respect to chiptune composers, I pointed out that some legendary shit was not made the way you think.[/li][li]Where you suggested a full DAW be made for PCE, I pointed out the nonsensical nature of that thought process. [/li][/ul] My friend has been writing something like that for MSX for like 5+ years. That's alot of time to invest in something.
Really, though, I was more looking for musician feedback.
You're not a musician. So, you mostly just have skewed scene perspective on the matter, biased towards what you watch *other* people do, and you can't actually comment on your own experiences, because you don't have them. You just assume the majority must be right, or something.
What I am trying to do is dispel incorrect and/or misguided views on MML that people like you perpetuate because you don't listen or even consider the things I am pointing out before you assume I am just attacking you.
Also, this isn't a one man crusade to rid the world of trackers. You would know that if you actually read and absorbed what I have posted here.
Especially that bit where I mentioned that four songs I turned into MML for Insanity came from songs I made in a goddamn tracker. You can use a tracker and then make MML out of the song.
Seriously dude. Stop and actually read/process things before you do this shit.
If you're not going to bother to do that, just f*ck off already. You're not going to help the conversation if you start commenting like a knob before your brain has caught up to your hands.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 21, 2016, 02:25:56 PM
Yes, it was all done very differently ... and Martin, Rob and Tim were all assembly-language programmers that wrote their own music drivers.
Yes, this is true, but, you missed the point! :)
My point is that the songs were composed *externally*, and that they have an understanding of how music works, so programming knowledge aside, they would likely be able to translate the music into a simple to follow text representation of sheet music. That sort of maneuver hasn't changed. They didn't compose the song in some clunky beepboop assembly manner. They just translated it to that after the fact.
MML is a similar equivalent. I believe this is where people are getting hung up, as many seem to TRY to write the song in MML.
People need to stop doing that. It's not really the way to go about it.
MML is basically there so you can punch sheet music into a computer.
Quote
That's just not how the computer-music world, and especially the homebrew game-world operates anymore.
yes it does, ;)
See: MSX scene. See Mabinogi Music scene....
Where do you think I confirmed MML functionality for PCE? Commercial titles for MSX still use MML.
Sometimes, I feel the tracker scene is actually the vocal minority because of all the cool Nintendo chiptune stuff, lol.
There's a plethora of MML stuff in Mabinogi, and one of the best players for MSX expects MUSICA format, which is an MML engine.
Quote
It's already been done, and it's called deflemask!
Sure, it's far from perfect, but it seems to be meeting most people's needs, and it keeps on slowly getting better.
Deflemask is a tracker. It's hardly the DAW anyone wants. It's no better than any other tracker in terms of usability. Even if it supports PCE, it's still wonky to use. You could just do the same thing with other trackers if you use the right samples.
Now, lets say it gets a fantastic feature like other, better trackers (maybe it has it?), and allows you to import a MIDI file.
Then, if there were a Deflemask player, it would be great to just import MIDIs, save them as whatever Deflemask does, and play them in PCE projects.
MIDI really is the key here, I think. MIDI ---> Something for PCE seems to work. Compose how you want--->Save to MIDI--->convert and go.
Quote
Just take a look on YouTube for chiptunes made (in the Western world) with MML rather than a tracker of some kind. I found a one, a video by you ... and that was pretty much it.
That was a search for "mml chiptune".
Then I searched for "deflemask chiptune", and pages of hits came up, lots of them for PC Engine tunes.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: DarkKobold on November 21, 2016, 02:35:12 PM
Bonknuts, maybe a tracker is better, but lets remember that Catastrophy wouldn't even have sound if it weren't for Squirrel. Elmer's solution of "stick to CDROMs" seems like a step in the wrong direction.
Maybe the tools aren't ideal, but for what Arkhan's done, it should be appreciated. I mean, its all good and well to say "this is how it *should* be done," but that doesn't help shit coders like me add music to their HuC game.
And yeah, I can get why Arkhan gets defensive - Squirrel was probably really f*ckin' hard to do. So, I can see where he'd get defensive. When PP makes a new troll account and starts shitting on Catastrophy, I'm sure I'll get defensive too.
I'm just saying, I appreciate that Squirrel exists.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 21, 2016, 02:38:28 PM
The credit doesn't all go to myself. Squirrel is the hot mess love child of myself and OldMan, with help from the Develo book, and the MSX scene.
It initially started as a little engine that parsed and played the MML during the game loop. Then it turned into what it is now.
anyway, I'm trying to get people who are INTERESTED in actually using MML to a good place. What problems are you having. Here's how to fix it.
Shit like that.
People might be surprised once they start getting probably little mishaps sorted out and go "oh", and realize it's only bad if you make it that way.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on November 21, 2016, 03:08:25 PM
Bonknuts, maybe a tracker is better, but lets remember that Catastrophy wouldn't even have sound if it weren't for Squirrel. Elmer's solution of "stick to CDROMs" seems like a step in the wrong direction.
Maybe the tools aren't ideal, but for what Arkhan's done, it should be appreciated. I mean, its all good and well to say "this is how it *should* be done," but that doesn't help shit coders like me add music to their HuC game.
And yeah, I can get why Arkhan gets defensive - Squirrel was probably really f*ckin' hard to do. So, I can see where he'd get defensive. When PP makes a new troll account and starts shitting on Catastrophy, I'm sure I'll get defensive too.
I'm just saying, I appreciate that Squirrel exists.
I'm not saying a tracker is better; I'm just saying that's what the majority of chiptuners prefer. He asked WTF the deal was, and I answered to what chiptuners particularly would give him - based on the responses I've seen. Believe it or not, this came up a LOT when there was no tracker for PCE music. Squirrel wasn't the first MML related music tool for the PCE; there have been others. And in the scenes that I visited, Squirrel was unfairly lumped with the other two simply because of MML. But that's the way it goes. I've written many music drivers for PCE - some just for fun. Be it pattern music (tracked), or command string format (underlying mml structure). I do my own stuff, so I'm in neither boat. If I'm working with a chiptune artist, I find out what they want - work around that. If they want something like mml, or tracker - I could care less as long as they have what they need.
As far as personal preference; obviously I have more experience with trackers than midi or mml. I've used them enough in my youth that everything about them IS intuitive. I know how to massage and draw out very specific sounds for instruments in tracked music. I'm also aware of the faults of patterned music too. If I was serious about music, I'd probably ditch trackers. But I'm not. And I'm not going to get bent out of shape over it either, if people don't like them.
In fact, the only real criticism I have about Squirrel toolset is sample support (real samples).
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 21, 2016, 03:16:24 PM
Using them enough that they are intuitive... is not how intuitive works.
You are conditioned by them.
They were never intuitive. Theyve always been clunky, and a bit laborious at times.
Theyre a product of the time that everyone got used to, and likes as a result of little in the way of options.
I grew up on them, and happily ditched them when better tools arrived.
And, ive never had good luck with vsts in trackers. Renoise just barfed on them.
But, as mentioned, by all means, compose in a tracker. You could turn em into mml when done.
Adding effects back in is the only downside. Those tend to get lost during the midi step.
Sent from my D6708 using Tapatalk
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: touko on November 21, 2016, 07:45:22 PM
Quote
Using them enough that they are intuitive... is not how intuitive works.
You are conditioned by them.
Sorry ark i have to desagree, intuitive for me is when a musician who know shit about programming(or the need to be a tech guy) can make musics for any systems easily with a tool . A tool with a GUI is always more intuitive than a simple file based tool which require some other tools to works . And i don't speak about the need to compile a .pce for testing,you cannot say that MML for PCE is intuitive .
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 21, 2016, 08:24:13 PM
Using them enough that they are intuitive... is not how intuitive works.
You are conditioned by them.
Sorry ark i have to desagree, intuitive for me is when a musician who know shit about programming(or the need to be a tech guy) can make musics for any systems easily with a tool . A tool with a GUI is always more intuitive than a simple file based tool which require some other tools to works . And i don't speak about the need to compile a .pce for testing,you cannot say that MML for PCE is intuitive .
What are you disagreeing with?
The statement I made was with regards to trackers not being intuitive. If you have to become accustomed to it through repeated use, it's not intuitive. That goes against the textbook definition of the word.
Intuitive implies you can sit down and immediately get it to start working how you want based off of simple instincts. Trackers don't do that. Anyone who says they do, are completely lying. Nobody sat down at a tracker for the very first time and was like "oh yes this all makes perfect sense" and started getting exactly what they wanted/thought out of it.
Everyone's first tracker experience was more like "whats this do". "What is that". "Why isn't this working right?" . "What are all these columns". "Ok, I made a pattern now what.".
It's goofy.
You need a manual, and hex fiddling to create a song in a tracker. The benefit you gain from a tracker is mostly that it forces formatting for you、because it's all locked to steps, and has defined columns for all the things.
However, you are still just banging the alphabet into a mess of stuff that happens to play music, lol. The effects columns in a tracker are clunky and look like total nonsense. Even people that love trackers seem to be aware of that. :D
So, trackers aren't intuitive. More modern DAWs are, because they are modeled after actual musical devices which, by their very nature, were designed to be intuitive. (analog synths, drum machines, mixers, etc.)
That's why I think it's nice to make songs that way (with a more modern piece of software), and then go through a relatively painless conversion process to get it onto the PCE. On that note, I know at least three non-programmers who successfully got things to work with Squirrel.
I never said that MML for PCE was intuitive. MML is only truly intuitive if you can read sheet music, and understand how to compose music from a theoretical standpoint. Most tracker users don't really seem to know any of that, have no concept of time signatures, key, or anything. So, trying to use MML just doesn't automatically click for them.
Converting a MIDI to MML, and moving it into a more or less pre-formatted file isn't exactly a horrible process.
Also, you COULD just write the songs in 3MLE. It's got a piano roll and will show you exactly what you're doing as you add notes. That's not really any different than a tracker. It just goes >>>>> instead of VVVVVVVVVVVVVV.
3MLE supports soundfonts, so one could make a soundfont of PCE stuff for it...
and then you'd just need to have those same waves defined in Squirrel (or make the soundfont out of the waves from Squirrel that are built in).
It seems like the biggest hangup is the MIDI-->MML process. I'd like to see what people are doing, so I could maybe help sort out any scary issues, or confusion.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: touko on November 22, 2016, 12:17:43 AM
Quote
What are you disagreeing with?
About that's intuitive or not .
You can blame trackers as many times as you want,it's really the simplest way for interesting some musicians to start composing for old systems . It's the same about coding, some people cannot want to start learning a new language,and can do some homebrews in basic as they did with BEX on MD .
MML is good if you are a musician and not affraid to put your hands in the shit,else for the others 99% a GUI tracker is by far less scary and more affordable. In my non musician standpoint, MML or tracker are the same, i am not abble to create anything with those two method,and i know it's more easy to find deflemask musicians than MML .
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Hu-man on November 22, 2016, 05:14:09 AM
So, I've only posted here a few times, but I follow all of your work a lot. My goal is to pop out of the woodwork one day and say, "Hey! Look at what I made on the PCE!" and then have everyone respond in unison, "What a piece of shit!" But till then, I'm mostly just a reader.
And before I go on my rant about MML, I should preface it by saying that I don't have much experience with trackers, and that my PCE stuff is the only experience I have with making music on a gaming platform.
That said, for someone who can read music, MML seems like a pretty decent notation. In fact, I'm hard-pressed to think of a better way. It's pretty close to modern musical notation, and that's been around for maybe a thousand years, so you'd think it'd at least be fairly good.
As far as my process is concerned, I'll usually just write on a real instrument then transfer it directly to the MML file, but sometimes I'll use a Finale NotePad-like tool to notate the music and then export to MIDI. I mention this because Finale NotePad has a free download and might help some of the people that are having a hard time with MML but can read music.
And as far as the readability of the MML is concerned, I agree that it can be kinda tough. But when it all comes down to it, it's being used to represent instructions you're giving the processor (code). So, like all code, it's easier to read when formatted. I often do something like 1 or 2 measures per line and use whitespace between notes to visually inspect that the timing matches up.
I think one of the reasons you don't hear about more people using it is that most people aren't the pros who post here most often. Compared to all the successes of everyone here, it seems to be taking me far longer than I would've expected - both in the time to develop a game and the time to figure out how to work around all of the PCE's/HuC's idiosyncrasies. Even yesterday while reading the "The new fork of HuC" thread, I saw Dave Shadoff's message about parameter-passing being bad, then I saw Elmer's message on the switch-statement being bad, and I thought, "Well that sucks for me."
So, as a verified non-pro, I find that Squirrel is probably one of the friendlier tools out there for PCE development. You don't need to worry about pointers, memory management, two's complement, or (may god have mercy on us all) learning assembly. You just feed it the MML, tell it when to play, and you're done! For the novice, learning HuC is probably enough, so I'll probably never be interested in writing a custom sound engine when all of the hard work seems to have been taken care of already. My personal opinion is that most of the non-vocal folks aren't writing in machine language, and those same folks would rather spend a little time learning MML over the (IMHO) steep learning curve that'd be required to reinvent the wheel.
Also, I could be totally wrong about this, but it kinda seems like Squirrel is the only game in town for making both music and sound effects on the PCE (other than custom sound engines). If not Squirrel, what are most developers using? And even if one uses CD-Audio for homebrews as Elmer suggests, what are people doing for sound effects?
I'm not on this forum as much as some of you other guys, but the only other sound tool I can remember was BT Garner's SoundGen tool, which I found extremely cumbersome. Also, it seemed like it took a very long time for ANY sound tools on the PCE to come around, so I don't know that waiting around for a new tool is a feasible option, especially when that theoretical tool will yield the same end result.
That said, here are my complaints about MML/Squirrel: [uldecimal][li]Not that it's impossible, but getting triplets isn't straightforward, nor are a weird/staggered beats (I'm thinking the nasally horn riff in the lava level of Bomberman '94).[/li][li]MagicEngine doesn't emulate it faithfully (which I guess is actually a complaint about MagicEngine).[/li][li]And to Bonknuts' point, "what you hear is what you get" would be really REALLY nice, especially so that you could hear the waveform/envelope combinations. Still, I don't know if that's really the point of Squirrel. Maybe that'd be for another GUI for the future, but I kinda see Squirrel as a jam-in-an-MML-file-and-it'll-give-you-music-on-the-PCE tool.[/li][/ul]Most other complaints seem to be around the fact that people want a GUI to write music, but there's a lot of them out there that will let you output your song to MIDI, so I don't know what the benefit of yet another GUI would be (except for the aforementioned emulation of envelope/waveform combos). If people want to use trackers to create songs, do none of them have the ability to output a MIDI file? Again, since I only have limited experience, I guess I don't really understand the benefit.
But, yeah, take all of what I say with a grain of salt. I don't have a vast knowledge of all the possibilities that are out there. I'm not trying to diss anyone or stroke anyone's ego (especially Arkhan's :P ). I just think that MML and Squirrel are pretty solid, and I wouldn't want people being discouraged from using them or told to only use CD-Audio (not that this should at all be construed as a dig on you, Elmer, I think you're rockin it with your work on the HuC fork) when MML and Squirrel are totally viable options. Squirrel has made developing on the PCE easier for me, and I think other people might agree if they give it a shot.
Anyways, that's the end of my rant. Talk to you guys in five years or so!
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on November 22, 2016, 05:21:03 AM
My point is that the songs were composed *externally*, and that they have an understanding of how music works, so programming knowledge aside, they would likely be able to translate the music into a simple to follow text representation of sheet music. That sort of maneuver hasn't changed. They didn't compose the song in some clunky beepboop assembly manner. They just translated it to that after the fact.
MML is a similar equivalent. I believe this is where people are getting hung up, as many seem to TRY to write the song in MML.
People need to stop doing that. It's not really the way to go about it.
MML is basically there so you can punch sheet music into a computer.
Sure, I get it ... compose the tune in a decent package, and then convert that tune into the format that the target machine requires.
Yes, that's how things used to be done.
You're basically talking about having a musician do the same thing as TailChao was doing with his excellent HuSound package.
Now I find MML to be ugly-as-sh*t to be that format, and I find TailChao's SASS-format to be much more human-friendly, but that's just my preference.
They're basically the same process. I get it.
Here's an example of exactly the same process from the driver that I wrote for Jon Dunn (the guy that replaced Martin Galway when Martin bailed out to join Origin) ...
; ************************************************************************ ; ; Music commands. ; ; *+ REPEAT ,n Repeat next sequence 'n' times. ; n=[1 to 255,0=256]. ; ; *+ TRANSPOSE ,t Transpose next sequence by 't' notes. ; t=[-128 to +127]. ; ; * JUMP ,a Jump to 16-bit address 'a'. ; ; * END End tune/fx/sequence. ; ; LENGTH ,l Assume all notes have length 'l' until MANUAL. ; l=[1 to 255]. ; ; MANUAL Assume each note is followed by a length. ; ; TIE Increase length of next note by 256. ; ; REST Play an empty note. ; ; GLION ,t,l Glide to note from transpose 't'/2 over 'l' frames. ; 'l' MUST be a power of 2. ; N.B. Also cancels effect. ; ; GLIOFF Cancel GLION. ; ; EFFON ,t,l Transpose notes by 't' for their 1st 'l' frames. ; N.B. Also cancels glide and vibrato. ; ; EFFOFF Cancel EFFON. ; ; ARPON ,n Arpeggio, using arpeggio table number 'n'. ; ; ARPOFF Cancel ARPON. ; ; VIBON ,d,t,l Vibrato, delay 'd', amplitude 't'/4, over 4'l' frames. ; ; VIBOFF Cancel VIBON. ; ; ENV ,n Use volume envelope 'n'. ; ; DRUM ,n Play a 'drum'. ; ; POKE ,a,n Poke location $FFaa with value 'n'. ; ; WAVE ,n,... Set up the 16 bytes of waveform RAM and store ptr. ; ; TMP_WAVE ,n,... Set up the waveform RAM. ; ; OLD_WAVE Set up the waveform RAM from the stored address. ; ; DUTY ,n Set the duty register to 'n'. ; ; SWEEP ,v,l,n Special glide. Sweep from note 'n' by subtracting ; 'v' from the frequency (word value - hi/lo) for 'l' ; frames. ; ; ; * Only these commands can be used in a sequence list. ; + These commands cannot be used in a sequence. ;
You can blame trackers as many times as you want,it's really the simplest way for interesting some musicians to start composing for old systems . It's the same about coding, some people cannot want to start learning a new language,and can do some homebrews in basic as they did with BEX on MD .
MML is good if you are a musician and not affraid to put your hands in the shit,else for the others 99% a GUI tracker is by far less scary and more affordable. In my non musician standpoint, MML or tracker are the same, i am not abble to create anything with those two method,and i know it's more easy to find deflemask musicians than MML .
None of this gives any indication that a tracker is intuitive, though. Neither MML nor Tracker is actually intuitive.
Trackers are just such old juggernauts that tons of people have gotten a handle on them.
I don't disagree that a tracker is pretty accessible, and gives you immediate(ish) results. they are popular. I'm not blaming them for anything, so I am not sure what you mean there.
As said though, trackers can 100% be used to end up with MML. :)
As far as my process is concerned, I'll usually just write on a real instrument then transfer it directly to the MML file, but sometimes I'll use a Finale NotePad-like tool to notate the music and then export to MIDI. I mention this because Finale NotePad has a free download and might help some of the people that are having a hard time with MML but can read music.
And as far as the readability of the MML is concerned, I agree that it can be kinda tough. But when it all comes down to it, it's being used to represent instructions you're giving the processor (code). So, like all code, it's easier to read when formatted. I often do something like 1 or 2 measures per line and use whitespace between notes to visually inspect that the timing matches up.
That said, here are my complaints about MML/Squirrel: [uldecimal][li]Not that it's impossible, but getting triplets isn't straightforward, nor are a weird/staggered beats (I'm thinking the nasally horn riff in the lava level of Bomberman '94).[/li][li]MagicEngine doesn't emulate it faithfully (which I guess is actually a complaint about MagicEngine).[/li][li]And to Bonknuts' point, "what you hear is what you get" would be really REALLY nice, especially so that you could hear the waveform/envelope combinations. Still, I don't know if that's really the point of Squirrel. Maybe that'd be for another GUI for the future, but I kinda see Squirrel as a jam-in-an-MML-file-and-it'll-give-you-music-on-the-PCE tool.[/li][/ul]Most other complaints seem to be around the fact that people want a GUI to write music, but there's a lot of them out there that will let you output your song to MIDI, so I don't know what the benefit of yet another GUI would be (except for the aforementioned emulation of envelope/waveform combos). If people want to use trackers to create songs, do none of them have the ability to output a MIDI file? Again, since I only have limited experience, I guess I don't really understand the benefit.
Formatting is *definitely* key. Using any of the available MML editors out there gives a bit of highlighting so it's more readable than notepad. This is why I go with 3MLE, as it also lines up a piano roll to improve readability and give a visual representation of your tunes to make sure timings are right. If you run it through a converter, it pays to take the 5 minutes to break out things and make it more readable.
3MLE's conversion process actually puts measure comments in front of EACH measure, which is pretty nice.
Is there a tracker that has an accompanying piano roll? The piano roll is probably one of the most brilliant things to ever be added to music software.
Triplets are a pain in trackers, too. You sort of have to trick things either way into working right. Getting the little triplet riff in Atlantean's level music was a bit efforty.
But, you do it once, you can always reuse it.
MagicEngine's built in SystemCard has really.really.wonky. PSG. Is that what you were using?
I agree having a way to immediately hear stuff would be nice, but I take what I can get. I might look into sampling the default Squirrel waves, to make a Soundfont that can be dropped into FruityLoops or 3MLE, or even a Tracker.
It won't have the envelopes, though.
I usually just approximate with Chip32, and get it "about how I'd want", because I usually have an idea in my head already. Sort of like how composers wrote entire symphonies on a piano, just by imaginging what the rest of the crap would sound like. :D
To your last question, yes, trackers typically output a MIDI. MODPlug did for sure. I used that to get some songs I made years ago onto PCE.
So, you can use a tracker to go to MML, but you will have to re-do the effects part manually (slides, vibrato), because those are generally lost in the MIDI shuffle.
I don't find it too painful to keep changing waves and relaunching the tune. I do similar things on the MSX when I am fiddling around in Musica to make songs. Granted, Musica just requires pressing F5 to play the song, as opposed to rebuilding.
...but that's why I made that little batch file for Squirrel, so you can just press a button and hopefully have it launch and play!
Sure, I get it ... compose the tune in a decent package, and then convert that tune into the format that the target machine requires.
Yes, that's how things used to be done.
You're basically talking about having a musician do the same thing as TailChao was doing with his excellent HuSound package.
Now I find MML to be ugly-as-sh*t to be that format, and I find TailChao's SASS-format to be much more human-friendly, but that's just my preference.
They're basically the same process. I get it.
Here's an example of exactly the same process from the driver that I wrote for Jon Dunn (the guy that replaced Martin Galway when Martin bailed out to join Origin) ...
That's how things can still be done. I don't know about anyone else, but composing songs with real instruments beats the shit out of a tracker, or any DAW, anyday. That's why so many people get midi controlled drums/pianos/guitars to plop stuff into software.
It'd be great if that SASS thing from TailChao had a midi--->SASS conversion.
I think MIDI is kind of the key to making life easy, personally. and as I've said numerous times, it also allows you to recreate the songs for CD audio, too.
2 birds, 1 stone.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Gredler on November 22, 2016, 07:02:41 AM
Anyways, that's the end of my rant. Talk to you guys in five years or so!
Please make it sooner than 5 years, I appreciate you chiming in and adding more perspective to the conversation!
What software are you using to create your midis right now, or am I reading it correctly that you currently play music and then manually write the mml to match what you enjoyed hearing from your playing?
Do you have a musical background? I cannot play any instruments and have 0 musical background, so I should probably not even be in this conversation #-o
That's how things can still be done. I don't know about anyone else, but composing songs with real instruments beats the shit out of a tracker, or any DAW, anyday. That's why so many people get midi controlled drums/pianos/guitars to plop stuff into software.
This is my biggest disconnect from the process. My real instruments are a WASD keyboard and a mouse :-({|=
I think a midi keyboard is being added to my Christmas wishlist, unless you guys have a suggestion for where to go from straight trial and error MML coding :-k
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 22, 2016, 07:09:56 AM
A MIDI keyboard is definitely a good life choice. Using WASD + mouse for music kind of blows a lot. It's probably one of the most awful things I've ever personally tried doing. I would rather go play sports than try and poke music out with WASD, lol.
some of those midi keyboards come with free-ish versions of some nice DAWs too.
I'm pretty partial to FruityLoops, as it's been the most intuitive of all of them with respect to acting like you've got real shit sitting in front of you, and having it work like you would expect.
Cakewalk and Cubase had a few things that made them kind of irritating where FruityLoops didn't.
but, I believe, with trackers like Renoise, you can also use MIDI input. MilkyTracker might too, IIRC. I haven't used MilkyTracker since I got FruityLoops like 12 years ago.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on November 22, 2016, 07:54:26 AM
You can blame trackers as many times as you want,it's really the simplest way for interesting some musicians to start composing for old systems . It's the same about coding, some people cannot want to start learning a new language,and can do some homebrews in basic as they did with BEX on MD .
MML is good if you are a musician and not affraid to put your hands in the shit,else for the others 99% a GUI tracker is by far less scary and more affordable.
This.
That's 100% of the argument.
Approachability for people that want to experiment who aren't hardcore musicians with hundreds or thousands of dollars of MIDI software/instruments.
I can bitch and moan as much as I like about how programmers aren't "real" programmers if they use HuC instead of 6820 assembly-language, but that would be both extremely rude, and absolutely pointless.
I've come to appreciate how HuC has enabled new progammers to experiment and create things on the PCE, and I now see a wisdom in its creation that I missed a couple of years ago.
Exactly the same argument applies to Trackers, especially Deflemask.
Quote
Deflemask is a tracker. It's hardly the DAW anyone wants. It's no better than any other tracker in terms of usability. Even if it supports PCE, it's still wonky to use. You could just do the same thing with other trackers if you use the right samples.
The point is, that it is more usable for folks doing chiptunes, because it emulates the audio hardware of a bunch of consoles.
It's the classic WYSIWYG ... the tunes that people make in it are supposed to sound exactly the same when they're played back on real hardware.
You specifically say that that's not the case with the FruityLoops/3MLE/Squirrel process.
That's a problem, from my POV.
Yes, you can say how folks should just man-up and be like Beethoven, but that doesn't encourage people to your side.
But, the reality of the current situation is that ...
Also, I could be totally wrong about this, but it kinda seems like Squirrel is the only game in town for making both music and sound effects on the PCE (other than custom sound engines).
Until there's a usable Deflemask player for the PCE, then nobody is going to be using it in homebrew, and it is only going to be used to create stand-alone chiptunes for fun.
Hu-man, you might consider taking a quick look at TailChao's HuSound to see if it offers you anything.
If nothing else ... the excellent demo/test environment and the PCM playback channels are both something that it would be nice to see in the Squirrel package.
Yes ... I know that PCM playback in particular would break compatibility with the System Card ... but that's the point.
The System Card player has been stagnant for decades.
Having some extra features would be rather nice ... and the 8KB cost for a new sound driver isn't very much with the 256KB environment of the Super System Card, and even less in the 768KB environment of a Turbo Everdrive 2.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 22, 2016, 08:14:46 AM
The System Card player hasn't been stagnant for decades, lol. Nobody was really using it until Insanity. We just hit the 7th year anniversary of that dumpster fire of a game.
\o/
It does suck that you don't get *exactly* the same sounds, but I think you get close enough that it doesn't hinder you *writing* a song. Melody, progression, and beat aren't dependent on the instruments and effects really. That's why you can hum Soldier Blade's music and smack your hands on a table, and people know what you're doing still. :)
Maybe that's where the real difference is. I'm trying to make music that's functional in the games I am making. So, I make the slight sacrifice while composing, and then go fiddle with it as much as I want once it's playing on real hardware. I can change the waves and envelopes by changing @# and @E# values to different #s. I can add some effects, or mess with detunes/slides.
The sound design part can (and should probably) come after you have a functional song. You don't do audio mastering before the band shows up and starts strumming.
and *again*, I'm not blaming trackers. Go ahead and use them.
I am just saying, here's this thingy you can use to produce sounds, so let's work together to get everyone on the same page so more people can go "oh" and realize it's really not as bad as everyone thinks.
To your point about thousands of dollars for MIDI hardware and software...
3MLE is free. MIDI controllers are roughly 30$. There are free MIDI programs...
The only thing you ought to buy is a MIDI keyboard. But, I would suggest that even if you're using a tracker, because punching notes in with a WASDboard blows.
There are lots of great tools out there to deal with MML.
EDIT: Is there something wrong with Squirrels demo/test setup? It was made assuming you at least have HuC installed, but other than that, is just "press this button to go".
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on November 22, 2016, 02:19:10 PM
The System Card player hasn't been stagnant for decades, lol.
"Stagnant" as in "not improving".
The System Card player was frozen in time with the System Card 1.0 in 1988.
Think of how many PCE HuCard games were released after that, a lot (most?) using their company's own custom sound drivers.
Chris Covell's great new video shows some of the fun techniques that developers used to make their tunes sound more interesting.
I'm curious ... do you believe that the System Card 1.0 Player can recreate ALL of those effects???
But again, apart from academic curiosity, it doesn't really matter ... the System Card Player is one of the only two alternatives that's available and working right now, and I agree that a lot of folks can learn to use it, and maybe even learn to love it.
Your Squirrel converter is the tool without-which they wouldn't be able to do that.
Quote
Maybe that's where the real difference is. I'm trying to make music that's functional in the games I am making. So, I make the slight sacrifice while composing, and then go fiddle with it as much as I want once it's playing on real hardware. I can change the waves and envelopes by changing @# and @E# values to different #s. I can add some effects, or mess with detunes/slides.
And that's great! That's how it all used to be done. :wink:
Quote
To your point about thousands of dollars for MIDI hardware and software...
3MLE is free. MIDI controllers are roughly 30$. There are free MIDI programs...
My point was more about how much gear you have to play with that makes things more familiar, and easier for you. :lol:
**************
Gredler - if you haven't seen this, it might help with your investigations into MML.
The page also has a download with approx 12,000 tunes. There should be something in there that you can tweak and use.
The System Card player hasn't been stagnant for decades, lol.
"Stagnant" as in "not improving".
Yeahhhhh, I know what you meant, lol.
Quote
I'm curious ... do you believe that the System Card 1.0 Player can recreate ALL of those effects???
But again, apart from academic curiosity, it doesn't really matter ... the System Card Player is one of the only two alternatives that's available and working right now, and I agree that a lot of folks can learn to use it, and maybe even learn to love it.
Your Squirrel converter is the tool without-which they wouldn't be able to do that.
I'm not sure. I haven't had time to sit and watch all of that video. Do you have any in particular that I should look at? I've made some pretty f*cking weird/interesting noises with Squirrel, just by goofing around.
I really do think people can learn it and mostly just need to get over the fact that it's not a tracker. If it's still functional for the MSX, there's clearly some merit to it.
Quote
And that's great! That's how it all used to be done. :wink:
Eh, its still done that way in a pretty good amount of places. :D
Quote
My point was more about how much gear you have to play with that makes things more familiar, and easier for you. :lol:
Well, for what it's worth, Insanity's tunes were composed with a MIDI keyboard I got at a garage sale for 10$, FruityLoops (but could be replaced with a free thing), and 3MLE. So, I didn't really use anything spectacular for this stuff.
The only weird thing I did, was I ran the MIDI out to a C64 with a MIDI board in it, and captured that for the leads on the CD version. I mostly did this because I had it and was like "hmmm".
The MIDI was all done in real time, though. All of those songs were made by me pressing record, and playing.
Gredler should also check out all the Mabinogi MML archives for stuff. There's lots of good stuff out there, already in functional MML.
http://mabinogimusic.tumblr.com/code
so many songs
There are a few things in Mabinogi that you need to omit as they're not part of the MML standard, but it's nothing crazy.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: TheOldMan on November 22, 2016, 04:41:14 PM
Quote
Think of how many PCE HuCard games were released after that, a lot (most?) using their company's own custom sound drivers.
I do not think many companies developed their own sound drivers; I suspect it is more likely they modified the 'stock' system card one.
Quote
...do you believe that the System Card 1.0 Player can recreate ALL of those effects???
No, but I think a new modifed version could. Although I can't swear it would be compatible with all existing games. I would especially like to incorporate the bonk trumpet sound. I think bonknauts Azazel (?) driver could do that.
And just out of curiosity, has any one put the plan all together, yet? We can make a new bios card (right, desh?) with 512K ROM (lots of room for extra code), 512K RAM (for bigger games...or maybe streaming video buffers) that should be backwards compatible with bios 3.1. Just saying.....
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 22, 2016, 04:57:28 PM
You can do the bonk trumpet sound with Squirrel. I made it before. It just requires the right enveloping. Reflectron has a similarish sound going on.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on November 22, 2016, 06:09:21 PM
I do not think many companies developed their own sound drivers; I suspect it is more likely they modified the 'stock' system card one.
Nope, that's just not how the industry worked back then.
And ... how-on-earth would they have gotten the System Card sound player in HuCard games???
Back then good musicians were specialists, and either their company, or they themselves, created custom sound drivers for their own use.
A good sound driver, like a good musician, was a "competitive advantage".
The only reason for putting a damned sound driver into System Card 1.0 was to save folks from needing to spend some of the measly 64KB of program RAM on including their own driver.
A basic music-driver is not a difficult thing for an assembly-language programmer to write, if a musician can describe, in reasonably technical terms, what it is that they want to achieve.
Looking at the CD Development System docs, and the disassembly of bank 2 that was done in 2001 (sorry, it's just easier to read than your version in Squirrel) ... it's not a particularly complicated sound-driver.
It's just another bytestream-per-channel driver, with a set of override-channels for the sound effects ... just like the example that I posted a few messages ago that I wrote for Jon Dunn.
I didn't know WTF I was doing back then (and still mostly don't), but having a good musician describe how things are supposed to work in musical terms made it easy to produce the correct code to interface with the hardware (on a number a different platforms, over a number of years).
It's all pretty-simple stuff in technical terms. The "magic" is all in the mind of the musician that knows how to use those capabilities to create a complex, beautiful, morphing soundscape.
No, but I think a new modifed version could. Although I can't swear it would be compatible with all existing games.
But Arkhan has specifically told people that the code cannot be modified.
Which is is why I rejected it a year-or-so-ago when this all first came up ... back when I thought that it was Aetherbyte's own proprietary code, and not just a disassembly of Hudson's proprietary code.
"Yes", it could be modified ... there are unused bytecodes that could be assigned to implement new features (like a sample-playback channel for decent drums).
But ... you guys have specifically dumped on that idea in your licensing terms ... and even if it were possible, it would still be a "derivative work" under copyright law, and thus "tainted".
Quote
We can make a new bios card (right, desh?) with 512K ROM (lots of room for extra code), 512K RAM (for bigger games...or maybe streaming video buffers) that should be backwards compatible with bios 3.1. Just saying.....
Again, you're going in a totally different direction to me.
You seem to want to make a brand-new System Card that acts as some kind of copy-protection for the homebrew developers that are willing to pay the licensing/manufacturing costs for it.
I'm more interested in just booting off the existing System Card, and then providing an 8KB or 16KB library of fast CD & Music library source-code that lives in the top 2 banks and completely replaces the old System Card routines.
For me ... that's a damned-good use of RAM, and it's 100% customizable on a game-by-game basis!
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: nodtveidt on November 22, 2016, 11:54:49 PM
We can make a new bios card (right, desh?) with 512K ROM (lots of room for extra code), 512K RAM (for bigger games...or maybe streaming video buffers) that should be backwards compatible with bios 3.1. Just saying.....
Again, you're going in a totally different direction to me.
You seem to want to make a brand-new System Card that acts as some kind of copy-protection for the homebrew developers that are willing to pay the licensing/manufacturing costs for it.
I'm more interested in just booting off the existing System Card, and then providing an 8KB or 16KB library of fast CD & Music library source-code that lives in the top 2 banks and completely replaces the old System Card routines.
For me ... that's a damned-good use of RAM, and it's 100% customizable on a game-by-game basis!
Both of these ideas are good. I dunno about the copy protection bit (I don't much care about it myself, copy away) but double the system RAM would be a blessing for those of us who still use HuC... and faster CD routines are always a bonus no matter if you use C or assembly.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on November 23, 2016, 03:49:15 AM
Both of these ideas are good. I dunno about the copy protection bit (I don't much care about it myself, copy away) but double the system RAM would be a blessing for those of us who still use HuC... and faster CD routines are always a bonus no matter if you use C or assembly.
Absolutely, more RAM is always nice! :wink:
BTW, don't forget that the new HuC seems to be generating code that is only 60% of the size of the old HuC (from Catastrophy), and Artemio's bank packing improvements make that even better.
And if 512KB of RAM is nice ... then the 4MB of RAM on the Turbo Everdrive v2 is even nicer!
And that's even not even considering the possibility of reading overlays from its SD-CARD instead of the CD.
But ... and it's a huge "but", I do understand that a lot of folks really want to have a nicely boxed brand new game package to display on the shelf and lovingly plug into the console.
I guess that you could do that with a custom SD-CARD in a CD case, but I suspect that some people wouldn't find that to be an "acceptable" alternative.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 23, 2016, 04:21:38 AM
But Arkhan has specifically told people that the code cannot be modified.
Which is is why I rejected it a year-or-so-ago when this all first came up ... back when I thought that it was Aetherbyte's own proprietary code, and not just a disassembly of Hudson's proprietary code.
"Yes", it could be modified ... there are unused bytecodes that could be assigned to implement new features (like a sample-playback channel for decent drums).
But ... you guys have specifically dumped on that idea in your licensing terms ... and even if it were possible, it would still be a "derivative work" under copyright law, and thus "tainted".
There may have been some kind of miscommunication between the three of us (we're good at that), as Squirrel also implies(d) (I thought) distributing the compiler piece, with the code for that.
I guess, maybe for future reference, we should call the actual player part something else in discussions, lol.
Squirrel = MML compiler SquirrelPlayer = the tainted precious.
I personally don't have any grand aversion to redistributing the player, as long as credit is maintained, and any future fiddle-dicking with it are properly noted and mentioned. Besides, there's really nothing stopping anyone from doing that already, because you are handed the code for it when you download Squirrel.
but, if you go goobering around with it and break compatibility with the compiler it was made to go with, then I don't know what to tell you about that, lol. You're on your own for getting stuff into it.
but again, as we've all now clarified: The HuCard piece that you want to distribute is 80s disassembly copy-pasta from Hudson's stuff, with some fiddling to get it to work right.
It's all a gray area. How IS copyright handled when the company who owns the copyright to this stuff acknowledges, encourages, and asks for copyright infringement? Does that mean they kind of legally admitted "f*ck it". .... , and this stuff is kind of thrown out the window?
Quote
You seem to want to make a brand-new System Card that acts as some kind of copy-protection for the homebrew developers that are willing to pay the licensing/manufacturing costs for it.
I'm more interested in just booting off the existing System Card, and then providing an 8KB or 16KB library of fast CD & Music library source-code that lives in the top 2 banks and completely replaces the old System Card routines.
For me ... that's a damned-good use of RAM, and it's 100% customizable on a game-by-game basis!
One of the driving forces for the HuCard for homebrewery is that it would stop f*ckhead Tobias from being a f*ckhead.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 23, 2016, 04:26:57 AM
I suspect that this was made with MML:
https://www.youtube.com/watch?v=5YjYEJ9WHt4
Even if not, its a good time.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on November 23, 2016, 04:54:55 AM
I'm more interested in just booting off the existing System Card, and then providing an 8KB or 16KB library of fast CD & Music library source-code that lives in the top 2 banks and completely replaces the old System Card routines.
For me ... that's a damned-good use of RAM, and it's 100% customizable on a game-by-game basis!
This is what I already do, with just the regular Sys card 3.0. I really don't like all the system card functions just sitting in MPR7. *IF* I need specific CD access, then I'll map syscard bank $00 back into MPR7 for whatever and then switch right back. I do adhere to the reserved ram requirements of what syscard routines use. So there's no conflicts for me.
I also totally agree about the sys card PSG player and the original 64k of ram. It really did make sense in that context. And sound engines, or rather "music" engines, are super easy to write from scratch. That has never been the problem for PCE. The issue has always been the supporting tools around it.
The Azazel music is Air Zonk reverse engineered; it's not a disassembly. It took me awhile only because I had to figure what all the original code was doing (I traced through it in the debugger, but I never disassembled it) - so what I wrote is 100% source. I could have done that in 1 day, if I were just given the instructions of what was needed. So my point is, Azazel was just for fun. And the whole; "Hey! make music using the Air Zonk sound engine". There's honestly nothing impressive about it, but it has enough features to get stuff done. I even wrote a music compiler for it; human readable music notation - not code or data defines. It's mml-ish too. But definitely not as fancy or advanced as Squirrel. But at the end of it the day, if someone wanted to support a new music engine - Azazel is not it. Just as I think the syscard PSG player is not it. A good solid month would get you something soo much better.
Given my experience with writing about 6 different "music engines" for the PCE, and the ones I've trace code through in PCE games, I've found that nothing out there delivers everything that the PCE is capable sound-wise. But see, I'm not a musician, so I'm always looking at this from a perspective of: how far can we push the PCE sound system and what new and interesting sounds can we get out of it? How can we make the sound more advance. I realize that not everyone shares that perspective. For some people, "it's good enough - let me just make music for it". I also realize that the whole "how far can we push it" mentality is a never ending game. It's a fun game to play, IMO. But that's not the point. The point is, is that quite a bit of techniques are now known about how to do more advance stuff with PCE sound. So why not take that, what we know, and simply make a new open source music engine?
Just to note: A tracker does not have to specifically output "patterned" music, just because that's how the interface layer works form the musician's perspective. The final output can easily be "command string" format. I would argue that it SHOULD be command-string based. Why? Because that supports everything.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 23, 2016, 05:15:38 AM
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, rather than:
A) Waiting for a mystical tracker to appear from the mists, ready to do what we all want B) Wait for whatever that MOD thing was that #utopiasoft's topic line said was coming next week, back in 2008. C) Use that other weird ass music program that was on Zeograd's site that made my face itch.
I got tired of waiting. I said something like "hey oldman, look at this. there's a BIOS PSG player just sitting there ready to be used. What the f*ck are we waiting for?"
Dave had some kind of demo for the PSG player on Zeograd. I once asked for info on it and a document he wrote awhileeeee ago, unfortunately, he blew me off. I don't know why. Playing dumb, legitimately forgot he wrote something, who knows. Who cares.
So after some of our poking, prodding, buying Develo book, looking at "how does MSX do it" complete with conferring with others who did or have done this commercially, and experimenting lead to the various iterations of Squirrel.
I wonder if I still have the one laying around that I wrote. It parsed and played from included MML data, instead of using the compiled one. There might even be a demo floating around of the Frog theme from Chrono Trigger that used it. I one day intended to use it for a live-play MIDI interface, but never got around to it because games.
Quote
I even wrote a music compiler for it; human readable music notation - not code or data defines. It's mml-ish too. But definitely not as fancy or advanced as Squirrel. But at the end of it the day, if someone wanted to support a new music engine - Azazel is not it. Just as I think the syscard PSG player is not it. A good solid month would get you something soo much better.
Oh. I didn't know you finished that compiler. That was awhile ago. Where is it?
Quote
So why not take that, what we know, and simply make a new open source music engine?
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.
Quote
Just to note: A tracker does not have to specifically output "patterned" music, just because that's how the interface layer works form the musician's perspective. The final output can easily be "command string" format. I would argue that it SHOULD be command-string based. Why? Because that supports everything.
This is what my friend's software for MSX is going to do, AFAIK.
*= What I mean by this is not meant to be insulting. I noticed this first when I looked at Dave's documentation he wrote. He had translated stuff about MML and put a ??? next to the translation of Dal Segno, implying he had no clue what the hell the katakana was trying to say, or what it even meant. I was like "shit, I forgot there's people who don't know how to read sheet music."
There is a strong difference between musicians, and programmers. I happen to be both, and had to help bridge the gap with OldMan when we were doing Squirrel to make sure the thing was usable and made sense. Some stuff that makes programmatic sense makes nearly no sense from a musical usability standpoint.
LOL, I remember at one point, I said "if we do that, you can't really do hopping bass lines" and OldMan said "so don't do those", and I was like "agjioagagajiogajioajasdfj34f4f", because yknow, hopping octave-shift bass lines are more or less some of the quintessential stuff from the 80s. We got it all sorted out. lol.
Now, because many (most? all?) of you that code are not musicians/composers, you will likely have issues with getting usable, functional stuff without the direct input and considerations of people who make the music.
I draw a line between musicians and composers, too.
All composers are musicians. Not all musicians are composers.
Musicians may be better to survey for usability (how do I touch this), but composers are probably better for functionality and "is this how it should work."
EDIT: Oh, here it is http://aetherbyte.com/downloadables/pgd.pce
It's still on Aetherbyte, lol. http://aetherbyte.com/downloadables/Defender.wav Oh, a version of Atlantean's level tune from before I changed the leads. http://aetherbyte.com/downloadables/sotb.mp3
SHADOW OF THE BEAST.
yeahhhhhh.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Gredler on November 23, 2016, 05:31:06 AM
It'd be great if that SASS thing from TailChao had a midi--->SASS conversion.
It has one here (http://tailchao.com/Audio/index.php#MID2SASS), which is also under zlib.
I'd like to write a Win32 tracker eventually with export support for the current SASS targets (BupBoop, HuSound, and HandyMusic), and HuSound needs a rewrite but this is all for way later.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on November 23, 2016, 06:15:00 AM
"Yes", it could be modified ... there are unused bytecodes that could be assigned to implement new features (like a sample-playback channel for decent drums).
There may have been some kind of miscommunication between the three of us (we're good at that), as Squirrel also implies(d) (I thought) distributing the compiler piece, with the code for that. ... but, if you go goobering around with it and break compatibility with the compiler it was made to go with, then I don't know what to tell you about that, lol. You're on your own for getting stuff into it.
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.
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.
Quote
It's all a gray area. How IS copyright handled when the company who owns the copyright to this stuff acknowledges, encourages, and asks for copyright infringement? Does that mean they kind of legally admitted "f*ck it". .... , and this stuff is kind of thrown out the window?
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.
Quote
One of the driving forces for the HuCard for homebrewery is that it would stop f*ckhead Tobias from being a f*ckhead.
That's definitely a noble goal ... but has Tobias shown *any* interest in copying people's homebrew?
This is what I already do, with just the regular Sys card 3.0. I really don't like all the system card functions just sitting in MPR7.
Yep, it bugs me, too! :wink:
Quote
But see, I'm not a musician, so I'm always looking at this from a perspective of: how far can we push the PCE sound system and what new and interesting sounds can we get out of it? ... So why not take that, what we know, and simply make a new open source music engine?
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???
Quote
Just to note: A tracker does not have to specifically output "patterned" music, just because that's how the interface layer works form the musician's perspective. The final output can easily be "command string" format. I would argue that it SHOULD be command-string based. Why? Because that supports everything.
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on November 23, 2016, 06:22:00 AM
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.
Quote
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.
Quote
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 23, 2016, 06:29:47 AM
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.
Quote
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.
Quote
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.
Quote
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.
Quote
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
Quote
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on November 23, 2016, 06:44:07 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 23, 2016, 06:46:05 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: TailChao on November 23, 2016, 06:56:19 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on November 23, 2016, 07:01:29 AM
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..
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Necromancer on November 23, 2016, 07:10:45 AM
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Sunray on November 23, 2016, 07:25:17 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on November 23, 2016, 07:28:16 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on November 23, 2016, 08:20:44 AM
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?
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Sunray on November 23, 2016, 08:27:25 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on November 23, 2016, 08:34:20 AM
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?
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on November 28, 2016, 09:36:25 AM
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! #-o
I hope that he downsamples that for his playback, or else musicians will have wildly crazy expectations of what the PCE sounds like! :shock:
Quote
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. :)
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on November 28, 2016, 01:47:35 PM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on November 29, 2016, 04:22:33 AM
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. :shock:
I'll be interested in hearing the results if you choose to go down that path! :wink:
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.
Quote
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on November 29, 2016, 07:28:54 AM
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. :shock:
I'll be interested in hearing the results if you choose to go down that path! :wink:
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).
Quote
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.
Quote
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on November 29, 2016, 12:35:51 PM
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. :oops:
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!
Quote
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! #-o
Quote
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. #-o
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Gredler on November 29, 2016, 12:58:11 PM
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. #-o
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on November 29, 2016, 01:53:14 PM
... 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. #-o
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.
Quote
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://www.youtube.com/watch?v=GIvxiusv1v8
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: DarkKobold on November 29, 2016, 07:01:19 PM
Noroi no Fuuin - Bloody Tears https://www.youtube.com/watch?v=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://www.youtube.com/watch?v=aFeL7kTw2CU
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 02, 2016, 03:28:48 PM
i love this tune made with deflemask : https://www.youtube.com/watch?v=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
i love this tune made with deflemask : https://www.youtube.com/watch?v=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
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).
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 03, 2016, 10:38:44 AM
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"
And sorry ... but 7-or-so 27KB samples is effing horrible IMHO! :shock:
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 03, 2016, 11:54:05 AM
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"
And sorry ... but 7-or-so 27KB samples is effing horrible IMHO! :shock:
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: touko on December 04, 2016, 12:31:30 AM
Quote
I was more impressed with it before I saw the crazy list of samples that it uses ...
:shock:
Effectively,not really the PCE standard .
Quote
And sorry ... but 7-or-so 27KB samples is effing horrible IMHO! :shock:
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 .
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: nodtveidt on December 04, 2016, 01:17:34 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: TailChao on December 04, 2016, 05:31:56 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: touko on December 04, 2016, 05:52:16 AM
Quote
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 ??
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: TailChao on December 04, 2016, 06:20:50 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: touko on December 04, 2016, 07:35:19 AM
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 ??
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: TailChao on December 04, 2016, 08:15:23 AM
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.
Title: MML: What are people's actual complaints with the damn thing
Post by: esteban on December 04, 2016, 11:29:18 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: spenoza on December 04, 2016, 01:07:11 PM
Well, since we're still chatting about Sqirrel and MML.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on December 06, 2016, 05:17:03 PM
LOL
What the f*ck?!
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 07, 2016, 07:16:06 AM
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.
Quote
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). :wink:
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Gredler on December 07, 2016, 08:21:01 AM
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). :wink:
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on December 08, 2016, 12:53:04 PM
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.
https://www.youtube.com/watch?v=bwpSeUnGNvQ
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 08, 2016, 02:06:42 PM
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.
Quote
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://www.youtube.com/watch?v=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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: touko on December 09, 2016, 06:48:31 AM
This one is really good too : https://www.youtube.com/watch?v=mumE3EWRW2w
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: DarkKobold on December 09, 2016, 08:33:20 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Gredler on December 09, 2016, 08:41:09 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: DarkKobold on December 09, 2016, 09:50:39 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: TheOldMan on December 09, 2016, 10:26:19 AM
Quote
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...
Quote
What you're referring to is just simple sample playback.
Quote
...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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Gredler on December 09, 2016, 10:52:04 AM
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 :)
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 09, 2016, 11:10:29 AM
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.
Quote
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?
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 09, 2016, 11:19:00 AM
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)
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Punch on December 09, 2016, 11:19:50 AM
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?
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 09, 2016, 11:21:15 AM
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.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 09, 2016, 12:20:03 PM
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).
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Gredler on December 09, 2016, 01:49:18 PM
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: TheOldMan on December 09, 2016, 01:51:53 PM
Quote
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?
Yeah, i went and looked it up. All 6 channels can do DDA. Would probably be easiest to hack in on channels 5-6, since there's already support in the player to switch modes (ie, noise mode)
Quote
...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.
I can sort of see how that might work. The psg player doesn't really have a 'tick'; each call, from vsync/timer is used to count down values. That's easier to explain (to musicians used to midi) as 'ticks'. Wouldn't you have to run the timer at a high rate (ie, low count) to do that though?
Quote
I'm not sure how much space the ripped player takes up in squirrel package,
~8k for the player. Some more in the library page for the actual driver call. (ie. mapping things in, etc) Same as bios. And yes, iirc, building a cd project changes how the psg setup stuff/driver is done; in a non-cd project, that code is in the library pages, while building a cd project substitutes the appropriate bios calls. Unless you removed it, the player code would still be compiled in, just never used. (My bad).
Quote
Are people really ignorant of PCE audio stuffs??? Nobody reads the PCM threads I post either?
Yes. I read them. Sometimes I even sort of understand them. Once in a while, I even catch a glimpse of how they work. Not all of us are that into the actual audio processing/hardware operations. Or have studied it in that much detail.
Quote
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.
Go for it. I have enough other things to do. (Like getting the player to work with the new Huc. Including timer irq support) If you get it working, pick an unused bytecode to indicate sample playback, and I'll see about putting it in the mml compiler. .......................... I figure if you pump out the sample values on hsync (assuming 262 hsync/frame) you could handle 12KHz at 5-bit resolution. Not exactly cd quality, but probably good enough for recognisable speech/sfx. Also, when you re-sample for pce, are you scaling down and interpolating over time, or what? I've read some about it, but mostly have been using sox to do it...
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: DarkKobold on December 09, 2016, 02:15:36 PM
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.
Honestly, this would be ideal for our project. Right now, cabbage built us some SFX in Squirrel/MML. They sound OK, but just reserving one channel for actual sampled SFX would be great, especially if it could be built into HuC. That said, it sounds like the overhead would be incredibly high, unless it was every vsync, which comes with its own issues, as Bonknuts pointed out.
EDIT: Also, what happens if my code has some library that does "soundplay(1)" and that overlaps "soundplay(2)"? Will the library be able to handle that?
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 09, 2016, 02:52:04 PM
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?
Yeah, i went and looked it up. All 6 channels can do DDA. Would probably be easiest to hack in on channels 5-6, since there's already support in the player to switch modes (ie, noise mode)
Quote
...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.
I can sort of see how that might work. The psg player doesn't really have a 'tick'; each call, from vsync/timer is used to count down values. That's easier to explain (to musicians used to midi) as 'ticks'. Wouldn't you have to run the timer at a high rate (ie, low count) to do that though?
Yup. At full 7khz rate. By tick, I mean the interval of time between calls of the parsing routine (and control routine; envelopes, etc). Since the PSG resolution of a tick, interval, is however many TIMER values are used in the timer divider (written to TIMER interval port), those steps that make up the internal are exactly 1 point at 7khz (6991hz to be exact). When you use the timer unit in this way, you're really just letting hardware do the down counter division for you. But if you set the timer to 0, and do the down counter yourself - the step resolution is exactly the same. The step resolution is always 1024 cpu cycles, whether it's a hardware counter or soft counter at max frequency.
So if you wanted 108hz tempo, set the TIMER to 6991 khz, set the software down counter to 108 (instead of writing it to the TIMER counter port), and on each TIRQ call decrement it. When it reaches 00, pass control to the PSG player. Otherwise, on each call you can now write a sample to any channel you like.
Obvious you don't want the PSG player writing other stuff to it, but if the PSG player is writing frequency control while in DDA mode - it won't affect the output of the sample. If you can get the PSG player to play a "sound effect" on that same channel, and not touch the volume after an initial set (because volume reg is the same used to set DDA mode), then you can basically get the PSG player not to intervene on that channel while the sample is being streamed to it.
You could probably take this one step further, by spying on the PSG player's pointer to a specific channel. And if it can read the byte code for notes, then it can interpret that note as a simple #. Even pull the volume control code value from it.
Basically Air Zonk does all of this.
Quote
Go for it. I have enough other things to do. (Like getting the player to work with the new Huc. Including timer irq support) If you get it working, pick an unused bytecode to indicate sample playback, and I'll see about putting it in the mml compiler. .......................... I figure if you pump out the sample values on hsync (assuming 262 hsync/frame) you could handle 12KHz at 5-bit resolution. Not exactly cd quality, but probably good enough for recognisable speech/sfx. Also, when you re-sample for pce, are you scaling down and interpolating over time, or what? I've read some about it, but mostly have been using sox to do it...
Some PCM demos I posted do this. It's higher than 12khz though. If you output a sample on every scanline per frame (H-int can be called on every scanline), that's 262 samples per frame or 15.73khz. I kept mine at 15.3khz output because 256 samples per frame allowed for alignment optimization (saved cycles in handling/check bank boundary crossings; it doesn't have to be done per instance of the sample fetch, but rather once per frame). I did 262 interrupts, but skipped playing a sample every so many lines (used a down counter).
The downside to this method, is that there's a good amount of overhead just to do 262 h-int calls - nothing else. It's ~20% cpu resource just for the setup of the next line. Not bad if you already need to do a scanline interrupt every active display scanline for sinewave or similar effects, but not so great if you don't.
Here's an example of 7khz vs 14khz: http://www.pcedev.net@ (http://www.pcedev.net@/)ftp.pcedev.net/HuPCMDriver/7khz_vs_14khz.zip The 14khz is just the sample code being called twice inside the TIMER routine. Simple to do, but wasteful. I just wanted to see what the different in frequency would sound like. Apparently at this rare level though, bit depth matters more than sample rate.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 09, 2016, 02:57:46 PM
Honestly, this would be ideal for our project. Right now, cabbage built us some SFX in Squirrel/MML. They sound OK, but just reserving one channel for actual sampled SFX would be great, especially if it could be built into HuC. That said, it sounds like the overhead would be incredibly high, unless it was every vsync, which comes with its own issues, as Bonknuts pointed out.
The overhead isn't that high, it's just amount of work to set this up for someone. It would be something custom for you, if you needed it. As far as cpu overhead, you're looking at like something like 6% cpu resource for a single channel stream. That's not too high.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on December 09, 2016, 03:14:26 PM
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.
Yes, a lot of people are ignorant to a lot of PCE stuff. We aren't exactly a crowded development community. There's also always something to be learned.
Also, not a lot of people read documentation all the way through. Some people read, and then forget due to not practicing what they read, and some of the PCE stuff is just sprawled about in weird places.
I knew all 6 channels could be switched to sample mode, and I'm sure OldMan did at one point, but mostly just mixed it up with the LFO or noise mode, since neither of us have looked at that particular stuff in awhile. It's two modes we don't really use/talk about, mixed up. No biggy.
I don't think either of us has really done anything sound-centric in awhile. I've been busy making games (Atlantean and Inferno), and he's been inhaling plastic fumes, and playing with the CD card stuff.
Also, I don't know about anyone else, but I tend to find your posts hard to read. You don't seem to proofread what you post, and it's often formatted in a way that isn't very conducive to easy-reading.
So, we end up with a wall of text that has broken sentences via fragmentation, tense change, idea change, or straight up grammatical errors. It's kind of effort-y to sit and read sometimes.
I know I've told you this in the past.
If you're trying to document or explain something, proofreading for accuracy and readability is pretty important. Formatting is a skill in and of itself.
Now, to some of the stuff going on in the thread: As OldMan said, you can take a sample, convert it to 5 bit values, and break it into 32 byte chunks, and store these as custom waveforms. I swear I've explained it on here before, and it might be in the manual for Squirrel. I forget, because I've not looked at in a long time.
Then, you can play a note, change the wave, keep playing the note, and basically string the sample back together.
You won't get the same quality as DDA mode, but it's doable. I've played around with it before.
You just make sure to use the same note that you sampled in at.
I am not sure if I still have an example of it. I was doing it for kick drums and ended up liking the completely PSG based kick drum I made more, so I stopped caring for the time being.
What "hack" from OldMan are you talking about that will produce a hum?
I've thought about it a few times about how to make the samples an easy-to-add-to-MML piece.
Notation wise, it should be pretty straight forward, and we'd probably end up writing a converter to produce the text-data that you'd paste into the file for a given sample.
I have to see what symbols are unused in MML, because we'd be basically extending MML and making it a little less standard possibly.
Maybe have samples as %# to indicate which sample data to use, instead of the @# that is in use for waves.
I'll dig around MSXLand and see what they're used to. They often don't bother with samples though, since you can do plenty without.
They've got 3 PSG channels, 9 FM channels, and 5 SCC channels to work with, lol.
Funny thing about MSX is that the SCC is real similar to the PCE, except it uses 8 bit values instead of 5, but doesn't support stereo panning.
I prefer the stereo panning
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 09, 2016, 04:38:52 PM
Yes, a lot of people are ignorant to a lot of PCE stuff. We aren't exactly a crowded development community. There's also always something to be learned.
Also, not a lot of people read documentation all the way through. Some people read, and then forget due to not practicing what they read, and some of the PCE stuff is just sprawled about in weird places.
I knew all 6 channels could be switched to sample mode, and I'm sure OldMan did at one point, but mostly just mixed it up with the LFO or noise mode, since neither of us have looked at that particular stuff in awhile. It's two modes we don't really use/talk about, mixed up. No biggy.
I don't think either of us has really done anything sound-centric in awhile. I've been busy making games (Atlantean and Inferno), and he's been inhaling plastic fumes, and playing with the CD card stuff.
Well, this kinda of stuff gets talked about on other game forums (not centric to PCE). PCE is kinda known for decent samples, sort of how Genesis is known for crappy samples. It was also on wiki, which people love to take as gospel. It's been part of a lot of sound discussions over the years too (all outside this forum). Did I mention it's on wiki? My point being. With all the "experts" out there that don't even write code for these platforms, I would have figured the homebrew community would at least know the basic; samples are easy to do on PCE; can do it on any channel or all channels. Maybe not the exact details, but at least that much.
I'm not knocking anyone. I'm just surprised.
Quote
Also, I don't know about anyone else, but I tend to find your posts hard to read. You don't seem to proofread what you post, and it's often formatted in a way that isn't very conducive to easy-reading.
So, we end up with a wall of text that has broken sentences via fragmentation, tense change, idea change, or straight up grammatical errors. It's kind of effort-y to sit and read sometimes.
Other than some grammatical errors (I don't proof read and I type it out fairly quick - as I'm thinking through it). I don't have time to put things into an easy to read essay format. Ideas and information tends to get packed into paragraphs. It also requires some level knowledge to make the connections I'm presenting (again, I don't have time to explain redundant information).
Quote
Now, to some of the stuff going on in the thread: As OldMan said, you can take a sample, convert it to 5 bit values, and break it into 32 byte chunks, and store these as custom waveforms. I swear I've explained it on here before, and it might be in the manual for Squirrel. I forget, because I've not looked at in a long time.
Then, you can play a note, change the wave, keep playing the note, and basically string the sample back together.
You won't get the same quality as DDA mode, but it's doable. I've played around with it before.
You just make sure to use the same note that you sampled in at.
I am not sure if I still have an example of it. I was doing it for kick drums and ended up liking the completely PSG based kick drum I made more, so I stopped caring for the time being.
What "hack" from OldMan are you talking about that will produce a hum?
I'm pretty sure I've mentioned this like 5 times already ;_;
You can't fill the 32byte buffer unless you turn the channel "off". Turning the channel off, also has the same effect as setting the volume to zero. When you re-enable the channel, it's the same as setting the volume to max (or whatever volume setting you used before). On all PCEs with the original 6280 (the non A revision), large changes in the volume causes an audible 'pop' on the DAC. There's one for turning off the channel, and one for turning on the channel. The direction of the pop, relative to zero line, is directly related to the change in volume (from no volume to max volume creates a positive side "pop" and max to none creates a negative side "pop"). It's not a small "pop" or click; it's pretty loud in relation to the audio. So if you update the waveform buffer 60times a second, you'll get a 60hz hum. The hum asides, 60x32 = 1.9khz. That's pretty crappy of a playback rate to begin with, but the clicks/pops are the worse part. Bump it up to 120hz with every update, then 3.84khz - still crappy and you up the range of the clicks into a higher the buzz frequency.
Drumkit type samples are super forgiving of a lot of things, including bit depth, extreme jitter, and other artifacts. In Genesis games, where the jitter is soo bad that the voices have the distinct "genesis" throaty sound to them - the drumkit samples on the same PCM driver don't exhibit these audible artifacts. So maybe that's why you didn't hear it.
Does that make sense? I used to have pics showing what this looks like (recordings). On any system with an updated 6280A revision cpu, these pops from the volume change are barely there. Only the SuperGrafx, and some models of CoreGrafx I, have this updated revision (later models went back to the original cpu model).
I mean, If you're just updating the waveform to add "timbre" like effects, at lower than 30hz, that's not sample playback - that's something else. I'm not sure if you're confusing the two. And it'll be more "clickity" than a hum or buzz, simply because the rate is slower.
Quote
I've thought about it a few times about how to make the samples an easy-to-add-to-MML piece.
Notation wise, it should be pretty straight forward, and we'd probably end up writing a converter to produce the text-data that you'd paste into the file for a given sample.
I have to see what symbols are unused in MML, because we'd be basically extending MML and making it a little less standard possibly.
Aren't PCE waveforms already none standard for MML? I mean, setting a waveform to a channel? Why not have some sort of "null" type of sample, where all notes for the waveform are interpreted as different samples.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: ccovell on December 09, 2016, 05:15:52 PM
To add to this discussion:
If you're working on a project and need a channel free for sampled sound effects, and your target is (Super) CD, use the ADPCM hardware. It's there, free, high-enough-quality, and costs you no CPU time or CD program RAM space.
I guess some people don't want to read, so try watching the few PCE dev tutorials I have recently put on YouTube, where I cover in breezily low detail the capabilities of the PC-Engine & its sound hardware. (ie: the things reminded above) https://www.youtube.com/user/wwwchrismcovellcom/videos
You can play around with waveforms and test the audible "popping" using my PCMgine waveform tool, as there is a function that swaps samples around at a fixed rate to channel 0. Link: http://www.chrismcovell.com/creations.html
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 09, 2016, 05:39:13 PM
Chris, you should do section on the Pro Wrestling games (three on the PCE) that do waveform corruption. If a channel is playing, and write to the DDA port, the sample will overwrite that playback position in the waveform buffer. These games do this to get a single channel metallic timbre change effect. I always thought it was interesting and underutilized.
About the whole waveform updating thing, 32byte, while the channel is playing - it does make for some interesting sound FX:http://www.pcedev.net/audio/bloodywolf/BW_test1.mp3 http://www.pcedev.net/audio/bloodywolf/BW_test2.mp3 http://www.pcedev.net/audio/bloodywolf/BW_test3.mp3
(the low frequency playback of the channel masks the popping).
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: TheOldMan on December 09, 2016, 07:38:03 PM
Quote
So if you wanted 108hz tempo, set the TIMER to 6991 khz, set the software down counter to 108 (instead of writing it to the TIMER counter port), and on each TIRQ call decrement it. When it reaches 00, pass control to the PSG player. Otherwise, on each call you can now write a sample to any channel you like.
I understand the theory (sort of). Here's the problem I have....
I assume setting the TIMER to 6991Khz is meant to lock in a particular clock for the timer. If I set the down counter to 120 (for 120 beats per minute), I will get timer irqs at the 'clock' frequency. If I decrement the down count, and call the psg driver when the counter hits 0, how do I do 32'nd notes? There are 32 of those per beat, and I only get 1 call.
Now, assume it works (and I think it can, by appropriate choices for the parameters). How do I speed it up? Change the value for the down counter? So i would need a table for the different tempo/downcounts? Okay, and doable. So it should work.
But now I'm effectively duplicating what the hardware does in software. And I would still have to send out a sample, regardless of whether the psg driver runs or not, wouldn't I? Otherwise, I'd end up missing samples.
I can see that it should work, but it's not obvious (to me, anyway) how it would be implemented.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on December 09, 2016, 09:19:35 PM
Well, this kinda of stuff gets talked about on other game forums (not centric to PCE). PCE is kinda known for decent samples, sort of how Genesis is known for crappy samples. It was also on wiki, which people love to take as gospel. It's been part of a lot of sound discussions over the years too (all outside this forum). Did I mention it's on wiki? My point being. With all the "experts" out there that don't even write code for these platforms, I would have figured the homebrew community would at least know the basic; samples are easy to do on PCE; can do it on any channel or all channels. Maybe not the exact details, but at least that much.
I'm not knocking anyone. I'm just surprised.
Yeah, I don't go to other forums because I don't really need that many technobabble places to go to and watch people ramble alot, lol. I got enough of that watching C64 people argue about the dumbest shit for hours on end.
The homebrew community doesn't have to be expected to know how to do samples. Besides, on paper it's always easy. In practice, it may not always be, as other problems (especially with our toolsets) can arise and create issues when trying to do this with a game.
Because it's all hobbyism, and a game platform, the main focus seems to be on the game part. Not the audio engineering.
Quote
Other than some grammatical errors (I don't proof read and I type it out fairly quick - as I'm thinking through it). I don't have time to put things into an easy to read essay format. Ideas and information tends to get packed into paragraphs. It also requires some level knowledge to make the connections I'm presenting (again, I don't have time to explain redundant information).
Yeah, I'm just saying, if you proofread and form better paragraphs/phrasing, you might find that your own points you are trying to make will get across better. I've lost count of how many times I re-read things you've posted and basically have to try and auto-correct it into a sensible sentence. Sometimes I just scroll on by and give up.
Quote
I'm pretty sure I've mentioned this like 5 times already ;_;
If you did, I missed it because ^^^^^^^^^^^
Quote
You can't fill the 32byte buffer unless you turn the channel "off". Turning the channel off, also has the same effect as setting the volume to zero. When you re-enable the channel, it's the same as setting the volume to max (or whatever volume setting you used before). On all PCEs with the original 6280 (the non A revision), large changes in the volume causes an audible 'pop' on the DAC. There's one for turning off the channel, and one for turning on the channel. The direction of the pop, relative to zero line, is directly related to the change in volume (from no volume to max volume creates a positive side "pop" and max to none creates a negative side "pop"). It's not a small "pop" or click; it's pretty loud in relation to the audio. So if you update the waveform buffer 60times a second, you'll get a 60hz hum. The hum asides, 60x32 = 1.9khz. That's pretty crappy of a playback rate to begin with, but the clicks/pops are the worse part. Bump it up to 120hz with every update, then 3.84khz - still crappy and you up the range of the clicks into a higher the buzz frequency.
Drumkit type samples are super forgiving of a lot of things, including bit depth, extreme jitter, and other artifacts. In Genesis games, where the jitter is soo bad that the voices have the distinct "genesis" throaty sound to them - the drumkit samples on the same PCM driver don't exhibit these audible artifacts. So maybe that's why you didn't hear it.
Does that make sense? I used to have pics showing what this looks like (recordings). On any system with an updated 6280A revision cpu, these pops from the volume change are barely there. Only the SuperGrafx, and some models of CoreGrafx I, have this updated revision (later models went back to the original cpu model).
I mean, If you're just updating the waveform to add "timbre" like effects, at lower than 30hz, that's not sample playback - that's something else. I'm not sure if you're confusing the two. And it'll be more "clickity" than a hum or buzz, simply because the rate is slower.
I gave a shit exclusively about drums, so this would likely be why I didn't hear anything. And, as I said, you can achieve a more than great kickdrum without samples, so I stopped screwing around with it for the time being.
Quote
Aren't PCE waveforms already none standard for MML? I mean, setting a waveform to a channel? Why not have some sort of "null" type of sample, where all notes for the waveform are interpreted as different samples.
the waveforms operate as the instrument being used. This is completely normal. This is straight out of PC98/MSX MML usage. You use @# to specify what voice to use for playback.
What your describing is how you might define some sort of sampling drumkit, and I've already considered that, as it would lend itself well to how percussion is already handled with Squirrel.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: DarkKobold on December 09, 2016, 11:53:33 PM
The homebrew community doesn't have to be expected to know how to do samples. Besides, on paper it's always easy. In practice, it may not always be, as other problems (especially with our toolsets) can arise and create issues when trying to do this with a game.
Because it's all hobbyism, and a game platform, the main focus seems to be on the game part. Not the audio engineering.
I have to agree with Arkhan. My goal in creating a homebrew wasn't to learn the deeper details of the PC Engine hardware. Catastrophy isn't going to be stretching the system to its limits. Hopefully, if and when its released, people will think it is a fun, high quality game for a system the love.
I feel like it gets forgotten that I'm not capable of coding in ASM. Sure, there is plenty of info on the psg... that is totally useless from a HuC perspective. Squirrel makes it stupid-easy to integrate music and SFX into a HuC program. Its just damn hard to make decent sounding SFX in squirrel.
It depends on what your goal is, is it to encourage more 'less capable' homebrewers to make games? If you don't keep it simple, its not going to get used by people like me.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 10, 2016, 07:36:43 AM
Here's an extreme example of using the 32byte waveform ram as a "buffer" on the SGX:http://www.pcedev.net/6280a/sgx_dump.wav
5bit audio. The playback is something like 56khz! It uses a 1747hz step TIMER setup, and fills the channel using 32 samples. The cpu resource to drive that is super low. The same file, which I can't find at the moment, on PCE sounds horrible (because of the poping on the DAC - it's a loud constant screech). The above wave was recorded from my SGX.
Such a rate seems unrealistically high. Overkill. But, at such a high rate you could interleave every other sample from a different stream. Now you have two channels of 5bit, playing at 28khz. This is actually how the Genesis mixes channels - instead of mixing them in the digital domain, it just interleaves them at a right fast rate. And because the FM chip in the Genesis is a single 9bit DAC, the accumulation allows higher than 9bit resolution in the analog domain (9bit+9bit = 10bit, etc). So the same on PCE, two channels at 28khz or PMW of two samples for a single channel of 6bit depth at 28khz (driven at 56khz). Given the SGX's filter range, you could probably extend that to four 5bit channels at 14khz, or two 6bit channels at 14khz.
Why am I mentioning this? Who cares about the SGX except SGX devs? Because there is a solution on the PCE. Remember how I said the pop on the DAC is in relation to the direction of the volume change? What if you reserved two channels. When you turn off one channel, you turn on another (at the same volume). The two different directional pops will cancel themselves out (simple rule: amplitudes add together). But there is a slight delay, in nano seconds IIRC, as to when channel volumes are processed. So it's possible there would be a super slight-tiny hum (because the spikes on perfectly overlap in the time domain; but the analog filtering on the PCE should lessen this even further). I tested out the cancellation on a real PCE, but I haven't tested it with streaming on the PCE itself. And at a rate of 56khz, two hardware channels can get back two or more channels with interleaving the streaming data.
This sounds easy, but timing has to be precise. If run off the TIRQ instead of the H-int routine, it's mean super tight code for H-int as not to delay TIRQ by too much. Thankfully, with one channel being off (available for 32byte data update), it's only the turning on of one and off of the other, that actually matters in the time domain. I'd probably even buffer in two extra samples (bytes) - so assume 30 bytes/samples per update (bringing it down to 52khz for the base frequency), and allowing any delay time to be covered by the last two samples (last two of 32).
Does that make sense? tl;dr - wall of text: you should in theory be able to use 32byte buffer method to play high rate samples on the original PCE without pops on the DAC, and have hardware mix multiple sample streams via high rate interleaving, but it requires using two hardware channels. Btw - some Amiga games/demo do this; the faster models can output up to 56khz, so they interleave sample data to extend the 4 channels into 8 channels.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 10, 2016, 11:32:11 AM
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 ;)
On the contrary, I'm really impressed with what you guys have done. :D
You game has a real charm to it that a lot of professional games don't. :clap:
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.
Yes, samples use the same PSG chip as the music on the basic PCE.
So you have to drop out music channels (temporarily) in order to play a sample instead.
It's no different to how sound-effects also use the same PSG chip, and how sound-effects cause music channels to drop out (temporarily).
It's all up to the sound driver (aka music driver/System Card Player/Squirrel Player) to deal with the technical details, and for the musician that creates the tunes, and usually the sound effects too, to keep in mind when they're assigning which hardware voices play which parts of a tune or a sound effect.
The problem with the System Card Player (and therefore Squirrel) is that it doesn't support sample playback, and that it would be an ugly hack to try to get it to do so.
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.
Nope, the PSG already supports sample playback ... but it's entirely CPU-driven, and it costs a noticable amount of CPU time.
My point being. With all the "experts" out there that don't even write code for these platforms, I would have figured the homebrew community would at least know the basic; samples are easy to do on PCE; can do it on any channel or all channels. Maybe not the exact details, but at least that much.
From what I can see, it's just not relevent to most homebrew developers here, both because the toolchain and sample code don't exist, and becaue it's just not been *needed* in the few homebrew games that have been developed.
If you're working on a project and need a channel free for sampled sound effects, and your target is (Super) CD, use the ADPCM hardware. It's there, free, high-enough-quality, and costs you no CPU time or CD program RAM space.
Absolutely! The capability just needs to be integrating into the toolchain and sound driver.
I guess some people don't want to read, so try watching the few PCE dev tutorials I have recently put on YouTube, where I cover in breezily low detail the capabilities of the PC-Engine & its sound hardware. (ie: the things reminded above) https://www.youtube.com/user/wwwchrismcovellcom/videos
I absolutely love your disection of different game's usage of the PSG.
I assume setting the TIMER to 6991Khz is meant to lock in a particular clock for the timer.
Yes, the problem that is being discussed is (AFAIK) how to play samples and music at the same time, and how to be able to define certain "instruments" and "effects" as one that play a 6991Hz sample instead of using the PSG's 32-byte waveform.
So the timer would be locked at 6991Hz (it's maximum rate).
If I set the down counter to 120 (for 120 beats per minute), I will get timer irqs at the 'clock' frequency. If I decrement the down count, and call the psg driver when the counter hits 0, how do I do 32'nd notes? There are 32 of those per beat, and I only get 1 call.
If someone were to implement that kind of scheme, then you'd get as many calls as you like ... it's just a case of defining your tempo as something that's an integer multiple of 1/6991 seconds.
But while you can say that you *need* fine tempo adjustment for some reason ... most of the old games were done without it.
And ... what's the fuss with 1/32 notes (a demi-semi-quaver)?
Doesn't the System Card Player already limit you to 1/16 notes (a semi-quaver)?
From what I can see, it defines time as a multiplier of 60Hz ticks per 1/16 note.
That matches up with the calculations that I did a long time ago ...
I can see that it should work, but it's not obvious (to me, anyway) how it would be implemented.
??? It's easy-enough with counters and branches ... but it slows down every single timer interrupt by 8 cycles for a decrement-zero-page, branch-if-zero.
That's 928 cycles per frame, 2+ scanlines, just to have a finely-adjustable tempo that is rarely (if ever) needed.
It's certainly possible, but it seems like a very high cost to allow both samples and a finely-adjustable tempo, and I really don't see the point.
the waveforms operate as the instrument being used. This is completely normal. This is straight out of PC98/MSX MML usage. You use @# to specify what voice to use for playback.
What your describing is how you might define some sort of sampling drumkit, and I've already considered that, as it would lend itself well to how percussion is already handled with Squirrel.
Sure, aren't instruments normally defined as both a waveform and an associated volume envelope?
Defining 7KHz samples as just an extension to the drum kit makes a lot of sense from a "music production" standpoint.
This sounds easy, but timing has to be precise. If run off the TIRQ instead of the H-int routine, it's mean super tight code for H-int as not to delay TIRQ by too much. Thankfully, with one channel being off (available for 32byte data update), it's only the turning on of one and off of the other, that actually matters in the time domain. I'd probably even buffer in two extra samples (bytes) - so assume 30 bytes/samples per update (bringing it down to 52khz for the base frequency), and allowing any delay time to be covered by the last two samples (last two of 32).
Does that make sense? tl;dr - wall of text: you should in theory be able to use 32byte buffer method to play high rate samples on the original PCE without pops on the DAC, and have hardware mix multiple sample streams via high rate interleaving, but it requires using two hardware channels. Btw - some Amiga games/demo do this; the faster models can output up to 56khz, so they interleave sample data to extend the 4 channels into 8 channels.
It's very clever and nice that that can be done! :clap:
But, practically, I sure wouldn't want to interleave 2 samples together in realtime on the PCE while I'm trying to run a game, and also lose both the individual panning and volume envelopes on each sample.
And "yes" ... I know that you can get the volume envelope capability back with another multiply ... but doing so slows things down again.
Using the technique for a single-channel sample might make some sense, although I'm not sure that a lot of musicians would be happy to lose 2 channels (temporarily) in order to gain the single sample channel. :-k
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 10, 2016, 02:20:01 PM
But, practically, I sure wouldn't want to interleave 2 samples together in realtime on the PCE while I'm trying to run a game, and also lose both the individual panning and volume envelopes on each sample.
And "yes" ... I know that you can get the volume envelope capability back with another multiply ... but doing so slows things down again.
Using the technique for a single-channel sample might make some sense, although I'm not sure that a lot of musicians would be happy to lose 2 channels (temporarily) in order to gain the single sample channel. :-k
Volume can be implemented via a look up table. I would never use multiplication in real time for soft(ware) volume. I mean it's as simple as ldx $0000 and lda vol_table,x. An extra 5 cycles per sample to handle volume over not using it. I usually implement this as self modifying code, and just adjust the table position in the array on a fame basis because it doesn't need to be done on a per sample basis (volume envelope changes happen on a low frequency basis.. like 60hz or lower). If you mixed 4channels at 5bit depth for 14khz output, that's 1% cpu resource per channel to do software volume on. Yeah, nothing's free - but that's pretty good.
Interleaving two or more streams really isn't any harder than handling a stream independently. It's actually really nice because it means no adding of any samples, and no translation tables to convert it into 10bit output for paired channel playback. I think that's pretty good.
From what I've seen of PCE games that do use samples, a good 90% don't even use hardware volume control for DDA playback - they leave it fixed (no envelopes). Things like drumkit samples are usually a fixed volume state, as well as sound FX samples. Some Genesis games mix up to four samples for the DAC, and never use any volume control on the individual streams.
Maybe there's some confusion here in how one would use samples. If you're using it as a musical instrument, with loop points, then I can see the need for volume envelopes. But most of the time, samples are just drumkits, one off sounds such as orchestra hits, and sound FX. Volume rarely plays a role in those types of samples. I mean, it can but it's not needed and isn't a big deal if absent. Yeah, panning goes out the window.. but look at what you gain. You have panning on the rest of the channels anyway, so it's not like you completely lost panning FX. And if you really need volume, eat the 1% overhead per stream. Heh - you'd probably gawk at my 4 channel@8bit 15khz player resource requirement. Everything has trade offs. Just like Arkhan wanting Timer resolution tempo control. If you're willing to accept the performance requirement, then you gain whatever additional ability.
I guess I should of mentioned that my post with the 32byte buffer thing, wasn't meant as something to add to MML or whatever. It's just a technique. And as Arkhan was exploring with it, it can be used to do some things on the PCE that's above and beyond what any devs were doing back in the day. I was just presenting how the concept could work and a relative example of it working. That is, if taken outside of the PSG bios player.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: esteban on December 10, 2016, 04:20:17 PM
Here's an extreme example of using the 32byte waveform ram as a "buffer" on the SGX: http://www.pcedev.net/6280a/sgx_dump.wav
Damn. That sounds great.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: TheOldMan on December 10, 2016, 04:33:34 PM
*** WARNING: Wall of text below. If you're not interested in technical arguements, or have not been avidly following ths thread, you may ignore this post ***
Quote
Quote
Quote from: TheOldMan on Today at 12:38:03 AM
If I set the down counter to 120 (for 120 beats per minute), I will get timer irqs at the 'clock' frequency. If I decrement the down count, and call the psg driver when the counter hits 0, how do I do 32'nd notes? There are 32 of those per beat, and I only get 1 call.
If someone were to implement that kind of scheme, then you'd get as many calls as you like ... it's just a case of defining your tempo as something that's an integer multiple of 1/6991 seconds.
I can't define the tempo. Tempo is how fast the song plays (not how fast the irq tick is). If a song is at 120 BPM ( a popular tempo), that means it plays 120 whole notes in 1 minute. Or 20 in 1 second.
I -can- define how many down counts are used before the psg player is called. So yes, in 1 second I can get as many calls as needed. But I still only get 1 call per group of counts. In order to change the *tempo*, I have to change the counter limit, which the psg player does, by changing the timer interval. I understand it *can* be done, but it's a bit more complicated than just "do this". How would you deal with interrupts in such a situation? (Remember we are getting 6991 of them every second) There's no guarantee that an irq won't occur while the player is updating. Do those interrupts count towards the next psg call? And at 6991 timer irqs / sec, do we even have enough time to handle this? And run a game? At 60 fps?
Those are the things I don't understand about how this would work. (And keep in mind, irq problems are a real thing, as rovers problem shows)
Quote
But while you can say that you *need* fine tempo adjustment for some reason ... most of the old games were done without it.
You never played a game where the boss attacked faster as you did damage? Listen closely; the music usually speeds up, too.
Quote
And ... what's the fuss with 1/32 notes (a demi-semi-quaver)? Doesn't the System Card Player already limit you to 1/16 notes (a semi-quaver)?
I'm not sure if the system card limits you or not, but that wasn't the point of the 1/32 note question. *IF* you are limited to -only- vsync, 1/32nd notes are impossible. They require a fraction of a frame. But, if you use the timer irq, you can update at less than 1 frame. That was the point. So the timer -is- needed. And without using the timer, There's no way to get 1/32 notes.
(And. as an aside, 1/32 notes are possible to play in the player. They just take 1 tick, instead of the 1.5 they should be, causing them to de-sync. Which is probably why they aren't supported. And how we found the trick below, thanks to a bug in squirrel during development.)
However, with the timer, we can use the following trick: Write the 32nd notes as 16th notes. Double all the other note times. And run the song at double the tempo. Sounds exactly the same. And you can do 64th notes by doubling again. Makes for some smoother arepeggios, and doesn't do too bad as a slide. (something the psg player is lacking in)
And before anyone asks, you can change the tempo before a measure, double the note length for just that measure, and then re-set the tempo. Provided you have a fixed tempo (ie, you don't call the psg setTempo() function to speed the whole song up)
Quote
It's certainly possible, but it seems like a very high cost to allow both samples and a finely-adjustable tempo, and I really don't see the point....
Quote
This sounds easy, but timing has to be precise. If run off the TIRQ instead of the H-int routine, it's mean super tight code for H-int as not to delay TIRQ by too much
Which is part of the reason I was asking about running it from HSync. *IF* it can run off of hsync... 1) you could do a quick sample update (lda [samples],x / sta ) 2) it would be at a decent rate (15 Khz, right?) 3) It could be hooked in via the user hsync hook.
I'm not at all sure it would work, and would require a channle just for samples. But it's interesting to think about.... I'll give you one more thing to think about, too. The psg player keeps a bit-mapped byte to indicate which channels are in use. It should be possible (though not necessarily quick) to check the byte and find an available channel :)
Quote
The question is ... is the System Card Player, and the IRQ handling in both the System Card and HuC smart enough to handle not only timer-followed-by-vblank, but also vblank-follow-by-timer???
For the player, it is. Once the player starts processing, it locks itself out from further calls until it is done.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 11, 2016, 04:47:14 AM
Folks, can we all get on the same page with music-theory? :-k
Tempo is the basic timing for a tune, it says how often a "beat" happens per second.
A "note length" is just a way of specifying relative (and not absolute) timings for events, so a note, a 1/2 note, a 1/4 note, or the wonderful British names, a semibreve, a minim and a crotchet.
These are further modified by having "dotted" notes that adds another fraction of the note to the lengths.
See https://en.wikipedia.org/wiki/Note_value See https://en.wikipedia.org/wiki/Tempo
The point is ... the note lengths specify time relative to other note lengths, and NOT in terms of absolute fractions of a second.
It is the time-signature and tempo that define the link between the note length and absolute time in beats-per-minute (BPM).
A "beat" is commonly defined as 1/4 note (especially in videogames), but that isn't an absolute rule.
But I'll use that 1/4 note = 1 beat convention for the rest of this.
Once you realize that note length are just a notation for relative time, you can see that changing the tempo (BPM) is just another way of saying that you're changing how long a 1/4 note is.
Here are the common "conventional" timings for running a music-driver on a console/old-computer ...
NTSC
Base Tempo = 5/60s per 1/16th = 20/60s per 1/4 note = 180.0 bpm (60 * 60/20) Base Tempo = 6/60s per 1/16th = 24/60s per 1/4 note = 150.0 bpm (60 * 60/24) Base Tempo = 7/60s per 1/16th = 28/60s per 1/4 note = 128.6 bpm (60 * 60/28) Base Tempo = 8/60s per 1/16th = 32/60s per 1/4 note = 112.5 bpm (60 * 60/32) Base Tempo = 9/60s per 1/16th = 36/60s per 1/4 note = 100.0 bpm (60 * 60/36)
PAL50
Base Tempo = 4/50s per 1/16th = 16/50s per 1/4 note = 187.5 bpm (60 * 50/16) Base Tempo = 5/50s per 1/16th = 20/50s per 1/4 note = 150.0 bpm (60 * 50/20) Base Tempo = 6/50s per 1/16th = 24/50s per 1/4 note = 125.0 bpm (60 * 50/24) Base Tempo = 7/50s per 1/16th = 28/50s per 1/4 note = 107.1 bpm (60 * 50/28) Base Tempo = 8/50s per 1/16th = 32/50s per 1/4 note = 93.8 bpm (60 * 50/32)
The table above shows that you can achieve a number of different "tempo" settings and still run your music driver in the vsync interrupt.
It also shows that speeding-up a tune (i.e. in a boss-attack) just involves changing the delay-per-quarter-note.
That's how games used to do it ... not by changing the number of times-per-second that the music driver was called!!! :roll:
***************************
Now, practically, in videogame music-drivers, the programmer has to make a decision about how to encode the note-lengths.
The simplest choice is just to use the tune's BPM to calculate the length of a note (in terms of 1/60s aka the number of "calls" to the music-driver) when you build the game.
For example, on an NTSC console (i.e. America/Japan and the PC Engine), if your tune is playing back at 128 BPM (which is your closest approximation for 120 BPM), then you'd store the length of a quarter-note as "28", meaning that you call the music-driver 28 times before the next note (see the table above).
That's the fastest-to-process when playing back the music, but it means that you can't easily change the tempo during playback.
Once the timing is baked into the tune data like that, the only way to change the tempo is to change how often the music-driver itself is called per second.
Now, most games do NOT change the tempo during playback, and so that's a common way to store the note-lengths.
The System Card Player can store tune data in this way, and it calls it the "Direct" length mode.
This appears to be the method that Arkhan and TheOldMan have chosen to use for Squirrel, and it's why they can't change the tempo of a song without changing how often the Squirrel Player is called per second.
It is not the only way to encode tune data, and it is not even the only way that the System Card Player supports.
Another way to store the length of a note is to store it in the original terms, for-example the length as a number 1..16 in terms of 1/16th notes, or the number 1..32 in terms of 1/32nd notes.
If you do things this way, then you can trivially change the tempo during playback by changing the length of 1/16th note from being 7/60s (a delay of 7 calls to the music-driver), to 5/60s or 8/60s.
The System Card Player can also store tune data in this way, and it calls it the "Time Base" length mode.
This is how most games work that change the tempo during playback.
This is also effectively how most trackers work, if they allow the musician to set the delay-time for each row/line in the pattern.
If you consider each row/line as the time of 1/32nd note, then you can get all of those 4, 5, 6, 7, etc 1/60s timings just by changing the delay times of even and odd rows/lines.
Deflemask does this, for example, when you to set the "Speed" to 4 & 3 ticks for the even/odd rows, resulting in 4+3=7 1/60s ticks per 1/16th note ... for 112.5 BPM (close-enough to a nominal 120 BPM).
One issue with using the System Card Player in this way is that it only stores notes in multiples of 1/16th note, which means that it cannot play 1/32nd notes without resorting to doubling the tempo and calling the driver twice-as-often (i.e. 120 times-per-second).
That's a limitation of the System Card Player's encoding of the tune data ... trackers don't have the same issue.
The System Card Player supports one one final way of storing the tune data, and that is to store the note length in terms of multiples of 1/64th of a note, then multiplied by 3. It calls this the "Tempo Method" length data. For this to work, the System Card Player *must* be called from a timer interrupt where the driver changes the length of the timer depending upon what BPM tempo you want to play back the music at.
The downside of this is that the more times you call the music-driver per second, the more CPU-time you're throwing away.
Hopefully that's all reasonably clear. :pray:
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 11, 2016, 05:15:14 AM
So if the BPM is based on down count of 3 (1/60 ticks), when that expires refill the downcount to 3-1, then on expire back to 3 - and repeat. You'd think this would get you 'warbly' sounds, but it doesn't. It gets you a BPM that's in between a 3 tick and a 2 tick. In MOD or XM files, you can set the tick on every pattern line, and a pattern line is read once the tick down count reaches 0. So it's not uncommon to see something like tick defines as 3,2,3,2,3,2,3,2 going all the way down the pattern - etc. Of course, you could do this on the player side too.
OK, that makes sense, for a while I thought that you were talking about changing the timing every "frame" (i.e. 1/60s or 1/30s)!
Changing it on pattern rows/lines make sense.
As I showed above, that 3 & 2 alternation is there to give 5/60s per 1/16th note -> 180.0 BPM.
Also, I recall now (and OldMan reminded me), that Squirrel with vsync doesn't support tempo changing because it was a PITA, and the timer mode was not.
vsync has a fixed tempo, so you must set note durations accordingly. It kind of sucks, and I forgot about it until all of this came up.
Nope, with the System Card Player, vsync does support changing the tempo. You've just got to encode the note length data in the "Time Base" length mode.
Doing so comes with the limitation that you can't specify 1/32nd notes, but that wasn't seen as a show-stopper problem by the programmer that wrote the driver, or by Hudson apparently.
Now, if your Squirrel compiler doesn't support that mode, then that's your choice.
And at 6991 timer irqs / sec, do we even have enough time to handle this? And run a game? At 60 fps?
To play a sample via writing to a single DDA channel, at 6991 calls per second, takes 11% cpu resource. It's 5% if no sample is playing (just down counting).
11% is not a lot when it comes to assembly. It's not exactly free, but unless you're really close to the edge in HuC, it shouldn't break the bank. So 5% no sample playing, 11% while sample playing.
.msb lda <sample+1 inc a and #$1f ora #$80 sta <sample+1 bcc .out inc <sample_bank bra .out
Quote
Those are the things I don't understand about how this would work. (And keep in mind, irq problems are a real thing, as rovers problem shows)
His issue sounds like an edge case scenario. That he needs to move his scroll() handling routines sooner up the chain so handle such delays. If you know what scanline number scroll() routine sorts the data and builds the RCR calls, you can work around this. If it's not doing it on the first active scanline, or a few scanlines right before first displayable line, I would change it so that scroll sort routine does this at this point in time.
That's why I said anchor the TIMER unit with a resync on V-int, and use the timer intervals to make something fixed like 120hz or 240hz system. When you can predict where code is going to happen every time, it's easier to deal with. But would require making some serious modification to the PSG player code or make a new engine. But meh - enough with the broken record of the opposition :P
Quote
However, with the timer, we can use the following trick: Write the 32nd notes as 16th notes. Double all the other note times. And run the song at double the tempo. Sounds exactly the same.
That's an old MOD/tracker trick!
PS: I like the wall of text :D
EDIT: Forgot the CLI in the code ;>_>
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 11, 2016, 05:27:43 AM
Folks, can we all get on the same page with music-theory? :-k
Tempo is the basic timing for a tune, it says how often a "beat" happens per second.
A "note length" is just a way of specifying relative (and not absolute) timings for events, so a note, a 1/2 note, a 1/4 note, or the wonderful British names, a semibreve, a minim and a crotchet.
These are further modified by having "dotted" notes that adds another fraction of the note to the lengths.
See https://en.wikipedia.org/wiki/Note_value See https://en.wikipedia.org/wiki/Tempo
The point is ... the note lengths specify time relative to other note lengths, and NOT in terms of absolute fractions of a second.
It is the time-signature and tempo that define the link between the note length and absolute time in beats-per-minute (BPM).
A "beat" is commonly defined as 1/4 note (especially in videogames), but that isn't an absolute rule.
But I'll use that 1/4 note = 1 beat convention for the rest of this.
Once you realize that note length are just a notation for relative time, you can see that changing the tempo (BPM) is just another way of saying that you're changing how long a 1/4 note is.
Here are the common "conventional" timings for running a music-driver on a console/old-computer ...
NTSC
Base Tempo = 5/60s per 1/16th = 20/60s per 1/4 note = 180.0 bpm (60 * 60/20) Base Tempo = 6/60s per 1/16th = 24/60s per 1/4 note = 150.0 bpm (60 * 60/24) Base Tempo = 7/60s per 1/16th = 28/60s per 1/4 note = 128.6 bpm (60 * 60/28) Base Tempo = 8/60s per 1/16th = 32/60s per 1/4 note = 112.5 bpm (60 * 60/32) Base Tempo = 9/60s per 1/16th = 36/60s per 1/4 note = 100.0 bpm (60 * 60/36)
PAL50
Base Tempo = 4/50s per 1/16th = 16/50s per 1/4 note = 187.5 bpm (60 * 50/16) Base Tempo = 5/50s per 1/16th = 20/50s per 1/4 note = 150.0 bpm (60 * 50/20) Base Tempo = 6/50s per 1/16th = 24/50s per 1/4 note = 125.0 bpm (60 * 50/24) Base Tempo = 7/50s per 1/16th = 28/50s per 1/4 note = 107.1 bpm (60 * 50/28) Base Tempo = 8/50s per 1/16th = 32/50s per 1/4 note = 93.8 bpm (60 * 50/32)
The table above shows that you can achieve a number of different "tempo" settings and still run your music driver in the vsync interrupt.
It also shows that speeding-up a tune (i.e. in a boss-attack) just involves changing the delay-per-quarter-note.
That's how games used to do it ... not by changing the number of times-per-second that the music driver was called!!! :roll:
***************************
Now, practically, in videogame music-drivers, the programmer has to make a decision about how to encode the note-lengths.
The simplest choice is just to use the tune's BPM to calculate the length of a note (in terms of 1/60s aka the number of "calls" to the music-driver) when you build the game.
For example, on an NTSC console (i.e. America/Japan and the PC Engine), if your tune is playing back at 128 BPM (which is your closest approximation for 120 BPM), then you'd store the length of a quarter-note as "28", meaning that you call the music-driver 28 times before the next note (see the table above).
That's the fastest-to-process when playing back the music, but it means that you can't easily change the tempo during playback.
Once the timing is baked into the tune data like that, the only way to change the tempo is to change how often the music-driver itself is called per second.
Now, most games do NOT change the tempo during playback, and so that's a common way to store the note-lengths.
The System Card Player can store tune data in this way, and it calls it the "Direct" length mode.
This appears to be the method that Arkhan and TheOldMan have chosen to use for Squirrel, and it's why they can't change the tempo of a song without changing how often the Squirrel Player is called per second.
It is not the only way to encode tune data, and it is not even the only way that the System Card Player supports.
Another way to store the length of a note is to store it in the original terms, for-example the length as a number 1..16 in terms of 1/16th notes, or the number 1..32 in terms of 1/32nd notes.
If you do things this way, then you can trivially change the tempo during playback by changing the length of 1/16th note from being 7/60s (a delay of 7 calls to the music-driver), to 5/60s or 8/60s.
The System Card Player can also store tune data in this way, and it calls it the "Time Base" length mode.
This is how most games work that change the tempo during playback.
This is also effectively how most trackers work, if they allow the musician to set the delay-time for each row/line in the pattern.
If you consider each row/line as the time of 1/32nd note, then you can get all of those 4, 5, 6, 7, etc 1/60s timings just by changing the delay times of even and odd rows/lines.
Deflemask does this, for example, when you to set the "Speed" to 4 & 3 ticks for the even/odd rows, resulting in 4+3=7 1/60s ticks per 1/16th note ... for 112.5 BPM (close-enough to a nominal 120 BPM).
One issue with using the System Card Player in this way is that it only stores notes in multiples of 1/16th note, which means that it cannot play 1/32nd notes without resorting to doubling the tempo and calling the driver twice-as-often (i.e. 120 times-per-second).
That's a limitation of the System Card Player's encoding of the tune data ... trackers don't have the same issue.
The System Card Player supports one one final way of storing the tune data, and that is to store the note length in terms of multiples of 1/64th of a note, then multiplied by 3. It calls this the "Tempo Method" length data. For this to work, the System Card Player *must* be called from a timer interrupt where the driver changes the length of the timer depending upon what BPM tempo you want to play back the music at.
The downside of this is that the more times you call the music-driver per second, the more CPU-time you're throwing away.
Hopefully that's all reasonably clear. :pray:
Ok. We're on the same page. This is exactly how I know music engines on 60hz to work.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 11, 2016, 06:02:02 AM
I can't define the tempo. Tempo is how fast the song plays (not how fast the irq tick is). If a song is at 120 BPM ( a popular tempo), that means it plays 120 whole notes in 1 minute. Or 20 in 1 second.
I -can- define how many down counts are used before the psg player is called. So yes, in 1 second I can get as many calls as needed. But I still only get 1 call per group of counts. In order to change the *tempo*, I have to change the counter limit, which the psg player does, by changing the timer interval.
See my message above on the basic theory.
Your "problem" as-such is that you're hard-coding the note-length in Squirrel, either as "Direct" mode or as "Tempo" mode (which are basically, from a programming POV, the same thing).
By doing that, then "yes" you need to change the timer interval in order to change the tempo.
That's a design-choice that you guys made with Squirrel ... it's not a limitation of the System Card Player, or a basic limitation of other music-drivers.
So, in "practical" terms, I do see where you're coming from.
How would you deal with interrupts in such a situation? (Remember we are getting 6991 of them every second) There's no guarantee that an irq won't occur while the player is updating. Do those interrupts count towards the next psg call? And at 6991 timer irqs / sec, do we even have enough time to handle this? And run a game? At 60 fps?
Those are the things I don't understand about how this would work. (And keep in mind, irq problems are a real thing, as rovers problem shows)
The whole point of any well-designed interrupt scheme is to keep the interrupt handling predicatable and usually short and fast.
Handling interrupts from within other interrupts just requires a careful design.
Bonknuts gave the basic code for a timer interrupt for handling the 6991Hz sample playback and music-driver calling.
Yes, interrupts need to be counted if you were to run a sound driver from a timer IRQ at the same time as you were outputting samples with the same IRQ.
For example ... take your 120 BPM.
120 BPM, with a beat being 1/4 note, and using the PSG Player's convention of 48 calls per 1/4 note, means that you'd want to call it 96 times per second.
With a 6991Hz timer interrupt, that means that you'd call the PSG Player once every 6991/96 = 73 timer interrupts ... which would give you an actual rate of 119.7 BPM.
*IF* you are limited to -only- vsync, 1/32nd notes are impossible. They require a fraction of a frame. But, if you use the timer irq, you can update at less than 1 frame. That was the point. So the timer -is- needed. And without using the timer, There's no way to get 1/32 notes.
You can do then in the System Card Player by using the Direct length mode of encoding the data stream, and setting the time to 3 or 4 ticks at 1/60th and 128 BPM.
But then you lose the ability to change the Tempo, and you'd have to worry keeping track of the overall time.
That's a limitation of the operation of the System Card Player, deflemask is quite happy to do them, taking either 3 or 4 ticks at 128 BPM using a 60Hz update.
(And. as an aside, 1/32 notes are possible to play in the player. They just take 1 tick, instead of the 1.5 they should be, causing them to de-sync. Which is probably why they aren't supported. And how we found the trick below, thanks to a bug in squirrel during development.)
Sure, call the System Card Player at 120Hz, and suddenly you have a 7/120ths instead of 3.5/60ths.
How would you deal with interrupts in such a situation? (Remember we are getting 6991 of them every second) There's no guarantee that an irq won't occur while the player is updating. Do those interrupts count towards the next psg call? And at 6991 timer irqs / sec, do we even have enough time to handle this? And run a game? At 60 fps?
Of course another interrupt would occur while the sound driver was doing it's slow processing.
That's fairly easy to handle, and "yes", of course you have to keep counting the timer interrupts while the sound driver is processing.
As for whether there would be enough time, Bonknuts has already said that single-channel 7KHz sample playback takes approx 11% of the CPU cycles.
So there's time ... it's just that even trying to do a countdown like that wastes 928 cycles per frame for the dec-zero-page+branch instructions.
Which is part of the reason I was asking about running it from HSync. *IF* it can run off of hsync... 1) you could do a quick sample update (lda [samples],x / sta ) 2) it would be at a decent rate (15 Khz, right?) 3) It could be hooked in via the user hsync hook.
You could do that, but you've just doubled the CPU cost for those samples, and the hsync processing is slower anyway, which costs even more cycles.
The question is ... is the System Card Player, and the IRQ handling in both the System Card and HuC smart enough to handle not only timer-followed-by-vblank, but also vblank-follow-by-timer???
For the player, it is. Once the player starts processing, it locks itself out from further calls until it is done.
Yes, but that's not the problem that I'm worried about. The problem is "what happens if the vsync interrupt triggers, and then the timer interrupt triggers one scanline later on".
Is the entire vblank interrupt processed with interrupts disabled?
If so, then you're delaying interrupts for a long time, and introducing a delay/error in the sample playback.
If not, then a timer interrupt can occur with a complete call to the sound driver, which would delay the time-critical processing that's going on in the vblank.
It all depends upon just how much stuff is being processed in the vblank interrupt.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: TheOldMan on December 11, 2016, 09:57:41 AM
Elmer: Got it. I'm not sure if the mml compiler supports "Time base" mode or not (that's the packed format, iirc). In any case, you would need as assembler call (and knowledge of where the variable is at) to do tempo changes that way from HuC. Something the psg bios doesn't (natively) have, afaik.
So, here's what I think I'm gonna do: I already have the patch in to add the underscore to the register name. I haven't exhaustively checked it yet, but I'm fairly confident it works. I'll 'extend' the MML parser, so that upper-case notes will be direct mode, while lower case notes will be time-base mode (which will have the happy side-effect of allowing for shrinking the output). I'll probably add a simple psg-bios call to change the time base. Then we can start discussing in detail how to alter the timer/hsync irq to get things working right for samples.
One question for you and tom, though. How much worse will mapping alternate pages make the timer stuff? IF we add sample support, I believe it's going to need extra space for the samples; some of them are going to be quite long, and the mml player is currently limited to 2 pages. Sort of. (That's a whole different discussion.)
.......................... Tom: You're the only leftover hardware guru afaik. Do you know when the hsync irq actually occurs? Is it at the end of the active scan-line display (ie, start of the back porch), in the middle of the hblank area, or at the beginning of active display? More specifically for what I'm thinking: How long do I have between an hsync irq triggering and the actual start of active display? The entire hb;ank period, or 0 cycles?
........................... Everyone else: Stay tuned. This could get interesting, and we may actually hash out how to add samples to the psg player.....
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on December 11, 2016, 10:26:25 AM
I would like to think/assume we're all on the same page with music theory, and are maybe misspeaking/typing due to wall-of-text/excited/not proofreading, lol.
Am I the only one here with a real music background, out of curiosity? (I minored in music. I've been doing music theory / lessons / crap since I was a kid).
I'll openly admit I get all jumbled up with regards to implementing these sort of things on goony old machines though, since fractions piss me off.
Nope, with the System Card Player, vsync does support changing the tempo. You've just got to encode the note length data in the "Time Base" length mode.
Doing so comes with the limitation that you can't specify 1/32nd notes, but that wasn't seen as a show-stopper problem by the programmer that wrote the driver, or by Hudson apparently.
Now, if your Squirrel compiler doesn't support that mode, then that's your choice.
IIRC, the CD version will work fine with the vsync stuff. I can't remember though because I haven't touched the CD PSG stuff since Pyramid Plunder.
It's the HUCARD version that for sure won't. That's the pain in the ass I spoke of. We're all aware that the capability does actually exist. Hell, it's in the documentation in Develo, Hu7, and some notepad file IIRC.
but some of that stuff we did could be wrong. As stated, we did this stuff by experimenting and looking around. If we did something wrong, nobody is exactly there to correct it.
It definitely did what was needed to make music in 4 games, though. So it can't be too far off if some of the timing and such isn't implemented "how games used to do it *insert eyeroll here*"
also, those britspeak words for musical things are so dumb. I always hated those in music classes. We all made fun of them, and put on British accents and acted like a$$holes.
Can we agree to not use them anymore in these forums? lolol
I don't know about anyone else but semi quaver cross stitch tea and crumpet demi semi loopdeedoo whatever just sounds like nonsense.
:)
now I just need to convince OldMan to not use case sensitivity in MML. we need a better way to do that.
at least we've got the sample-ideas stirring again. the idea came up awhile ago, there was no time to do it, we got sidetracked, (and it was still barely important), but now would be a good time to worry about it.
EDIT: Oh btw: Squirrel already has things for modifying the timebase, but they might not be right (that's what the ^D# commands do).
So, instead of adding something, we probably just need to look at what is already there. :)
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Gredler on December 11, 2016, 12:41:57 PM
Hell yeah let's make that cat purr with sampled sfx :P
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 11, 2016, 12:57:42 PM
I'll probably add a simple psg-bios call to change the time base.
That would be a "questionable" thing to do unless you make a whole bunch of other underlying changes.
The capability that's in the System Card Player is pretty-obviously to allow for tunes themselves to speed up ... i.e. you bake the command to change the Time Base into the tune data, so that the 2nd repetition of the loop is faster than the 1st, and the 3rd faster than the 2nd, and so on.
If you do it externally, you're going to have problems with channels losing sync because you change the Time Base while some channels are still playing notes with durations calculated using the old Time Base.
You'd have to sync any change to the start of a measure (or whatever the musical folks want to call it) when you retrigger every channel on the same frame.
Everyone else: Stay tuned. This could get interesting, and we may actually hash out how to add samples to the psg player.....
It's a race! :wink:
My sound driver is now re-written in 6280 assembly language, and the next step is to implement some GameBoy emulation features on the PCE (just so that I actually have tune data to test it with).
BTW ... this is a chance to say just how wonderfully *nice* Hu6280 assembly language can be compared to the Z80-ish that the GameBoy uses.
The GameBoy code is hideous in order to deal with some of the limitations of its not-actually-a-Z80 processor, where the Hu6280 code is simple and readable.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on December 11, 2016, 03:33:15 PM
”simple and readable" to an extent, due to 6502isms.
:)
I don't think OldMan intended to do what you think with regards to changing the time base. Maybe he does. I don't know, lol. As I said, we already support time base commands when setting up channels, but the tempo/vsync stuff may not be there, or right. I am thinking we might not be as far off as we think, though, in terms of work.
Now, isn't the reason a tracker avoids this issue because of the fact that the tracker style tends to sort of "lock" things together, so everything is running simultaneously?
I'm not sure on the technical way of explaining that. Things are sort of guaranteed and synced up.
EDIT: Also, should I envy you old goobers and your copious amounts of free time ? I try to slot out free time so I can get Inferno/etc. done, and still PLAY games. My backlogs kind of falling out of a cabinet right now. -_-;
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 11, 2016, 04:15:06 PM
GBz80..wooh.. no good. I haven't written GBz80 in a long time, and I have recently looked back on it - yeah, no. To a lesser extent, real z80 too. When I code on the z80, and GBz80, I feel restricted by the force use of smaller register-register operations (and 90% of them still have to be done through one reg: "A" reg). I miss the direct memory access of the 65x, and the labels you get to use (keeping everything in regs instead of direct memory with labels, made the code harder to read IMO).
Old Man: From what I remember my tests showing me, when the VDC transitions from "hsync" (or more accurately; the period/window where the VDC waits for VCE to trigger it to move onto "back porch" area) to the actual blanking line (blanking level), is when the VDC will generate an interrupt for the cpu. You can test this, because while the VDC is setup for a "waiting window" for the VCE to trigger it, the VCE trigger itself ALWAYS moves the VDC back to "front porch" area - no matter where it is in the scanline (the VDC's front porch, which when unaligned is not always the VCE's front porch). This is how you can get the VDC to show two individual lines of graphic data on the same VCE NTSC line. Does this make sense?
Maybe this pic will help: (https://www.maximintegrated.com/en/images/appnotes/734/DI39Fig05.gif)
The VDC enters a mode where it waits for the VCE to trigger the start of the next scanline. In the pic, that would be the "sync tip" area. And where you see the line going back up to 0 IRE, that would be the position in VDC "world" where the H-interrupt is generated. That "sync tip" is what the VDC manuals refer to as "horizontal sync pulse width". But since the VDC is in subordinate mode (requiring external interrupts to provide the image frame work), this is just a wait delay. It's set in segments of 8 "VDC" pixels wide, but if the VCE trigger in the middle it, then the VCD immedialely transitions into the next phase. So it's not going to actually be 8 pixels long. You could set it to be 24 pixels long; it won't matter. The VDC also immediately reads the X and Y position buffers and works out the logic for how to process the current line (sprites positions, BG positions, etc). I doubt you'd be able to get a fast enough routine to update these regs in time anyway, so that's why changes to regs happen on the following line. That way, if the H-int routine gets delayed then it should be affected. But that all depends on how close the reg updates happen relative to the start of the H-int routine.
tl;dr: H-int happens at the very start of the back porch, when sync level goes to 0 IRE (right before the color burst in the pic). And if I remember correctly, the VCE adds a 8 pixel delay from what the VDC is displaying to what you actually see on screen. But that probably shouldn't effect what you're doing unless you're trying to change VCE regs per scanline.
It's a little bit confusing in understanding the VDC in relation to the VCE. The VDC on the PCE doesn't generate hsync pulse or the color burst area, because it's in subordinate mode, but the regs will always be setup as if you're defining a real line. So I used the term "back porch" to keep things relative in talking about where in the line stuff happens on the VDC.
So, I didn't really follow along of what you're trying to solve. What timing issue are you trying to work out?
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: TheOldMan on December 11, 2016, 05:06:31 PM
Quote
So, I didn't really follow along of what you're trying to solve.
Not a timing issue, yet. I'm trying to get a feel for how quick and hsync routine would have to be to avoid the active display area.
So, if I'm understanding it correctly, I have about 5us after hsync before color burst and active display....That's gonna be tight. ...................................... Edit: My bad. I misunderstood. I had to go read it about 3 more times before what was where on the diagram clicked.
Hsync is gonna be triggered after the color burst, and very shortly before active display starts. That actually explains some of the color tearing i've seen.
Thx.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 11, 2016, 05:24:11 PM
Now, isn't the reason a tracker avoids this issue because of the fact that the tracker style tends to sort of "lock" things together, so everything is running simultaneously?
I'm not sure on the technical way of explaining that. Things are sort of guaranteed and synced up.
The whole "pattern" abstraction with its even and odd 1/32nd-note rows does make it visibly-clear exactly how each of the channels are synced up to each other, and forces the musician into placing notes in such a way that the "patterns" that run on different channels never go out-of-sync (which *can* be a problem with MIDI-to-MML).
But ... IMHO, at the end-of-the-day, it's really just a case of when the "note length" values get converted into ticks (i.e. the number of 1/60s music-driver calls before the next note).
The standard music-driver convention (which I believe that the System Card Player follows), is that you calculate the length of a note as-soon-as you see that note on the stream of data (i.e. what the MML gets converted into so that the System Card Player can understand it).
That means that if you change the Base Time, i.e. the number of music-driver calls per 1/16 note, then the next note that you process on a different channel will see a different multiplier, and calculate a perfectly-correct delay count for it's own channel, but the other channel with the old note will drift out of sync by a few frames.
Repeat that enough times and it's all going to sound like cr*p.
The "tracker" model gets around this by redefining a note length as a certain number of rows/lines.
That way, the number of 1/60th ticks delay that each row/line takes up can change at any time.
From a programming POV, it's using 2 counters per note (1 for Base Time, and 1 for # rows) instead of a single counter in the traditional model.
That has its cost in processing terms ... but it's a tiny cost, and the flexibility that you gain from it is well-worth-it (IMHO).
Of course ... as a programmer, you'll realize that you can do exactly the same thing with MIDI or MML data that's converted into a command-string format and fed into some music driver, just like you do with the System Card Player ... but the actual System Card Player itself doesn't support that particular abstraction.
It's another thing on the (long) list of reasons why the System Card Player (and therefore the Squirrel Player) need to be taken out back behind the wood shed and put out of their misery.
I have no vested-interest in what data-format my music-driver plays (except for absolute-efficency).
Converting Deflemask files is no easier (or more difficult) than converting MIDI or MML files.
A "sane" music-driver uses some form of "processed" version of the tune data that is totally-optimized for it's own capabilities and the target platform.
EDIT: Also, should I envy you old goobers and your copious amounts of free time ? I try to slot out free time so I can get Inferno/etc. done, and still PLAY games. My backlogs kind of falling out of a cabinet right now. -_-;
Being as-old-as-the-hills has to come with some (pitifully-few) advantages! :wink:
I miss the direct memory access of the 65x, and the labels you get to use (keeping everything in regs instead of direct memory with labels, made the code harder to read IMO).
That's the issue, exactly! :)
It's the difference between sta mz_volume,x, where "X" is the channel number, and the GBZ80 code that's full of ld hl,sp+VOLUME and ld (hli),a instructions, with very, very, very careful ordering of the variables in order to keep on using the (hld) or (hli) addressing modes for speed.
It's practically undecipherable except for the idiot that wrote the mess in the first place! ](*,)
The Amiga and ST versions are much clearer (with the ST version supporting sample-playback), but I chose to work from the GameBoy version because that was the final version of the code.
Strange to be revisiting such old code and re-targeting it to a new platform!
So, I didn't really follow along of what you're trying to solve. What timing issue are you trying to work out?
Hahaha! :lol:
That's one brilliantly OCD post full of wonderful information, before finally getting around to the "what was your question, again?" :wink:
I *think* that the information that TheOldMan is looking for is that the hsync timing doesn't really matter very much.
The VDC chip make copies of the scroll-registers that it will use for the next line of video at the start of an hsync, and doesn't read them again until the start of the next hsync.
So you actually set the hync interrupt to trigger on the line *above* where you want to change the scroll value, and then you have an entire scanline (433 cycles) to set the new scroll values before the VDC reads them again to set them for the next line that it's going to display (and where you want the actual scroll region to change).
The PCE is not like a lot of the old home-computers where you absolutely-must change the scroll-register values *during* the few microseconds of the hblank.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on December 12, 2016, 05:39:57 AM
Some MML playing engines (I think Squirrel might. if it doesn't, it should.) also support a different tempo for each channel.
I seem to recall messing around with it once. It's not a common thing to want to do and really is for when you do SFX on a channel, or when you want to do arps or weird effects on a channel.
You can crank the tempo through the tits and get stranger sounds while the rest of the song plays at a tempo that is conducive to coherent music.
I'll have to see if it was Squirrel that was also doing that, or if that was around when I started Inferno and was doing this on MSX.
I think though, that with a little bit of fiddling around, Squirrel will be able to do some new things.
It hasn't exactly been touched or updated since before Atlantean. The last time it was updated was for Pyramid Plunder.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 12, 2016, 05:50:28 AM
That's one brilliantly OCD post full of wonderful information, before finally getting around to the "what was your question, again?" :wink:
In my defense, I had a 14 page ethnographic paper I was trying to get done in order to turn it in by mid-night on Sunday. So I had a number of glasses of alcohol to get things.. flowing. :-"
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 12, 2016, 06:12:27 AM
To play a sample via writing to a single DDA channel, at 6991 calls per second, takes 11% cpu resource. It's 5% if no sample is playing (just down counting).
I take it that you have a timing setup in place.
Are you able to run a simple 6991Hz timer IRQ and tell us what the CPU cost (in cycles-per-frame) of the basic IRQ overhead?
That's on a HuCard, with a direct hardware vector (at $FFFA) to this IRQ routine ...
tirq_null: stz $1403 ; 5 rti ; 14
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on December 12, 2016, 06:41:11 AM
Why do you have ; 14 for the cycle count of RTI?
I thought it was like 6.
6502.org says 6. ArchaicPixels says 7.
Where did 14 come from?
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 12, 2016, 07:01:31 AM
Is it slower on 6280 vs. 6502? 6502.org lists it as 6.
Lots of stuff is a cycle slower on the 6280 ... but lots of stuff is the same.
I have no idea why there's an extra cycle on an RTI, but it's documented.
The timings in the cribsheets that can be downloaded from bonknut's blog are accurate.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 12, 2016, 08:01:47 AM
14 was the return total (pla, tam, and rti) The int call is 8 cycles, the RTI is 7 cycles. That's the minimum you can possibly have on the PCE.
Anyway, look over this: (http://www.pcedev.net/HuPCMDriver/TIRQ_playnice.png)
I changed a few things around. "in_progress" can be used as both temporary bypass (sample currently being fetch/played), or to complete stop sample playback (because it can't undo itself if the condition is set outside the IRQ routine).
I also decided to wrap the timer decrement inside a protect area (interrupts disabled). Just in case some wild edge case scenario showed its ugly head. You don't want a second call (overlapping TIRQ) to decement the counter while the previous call was in the middle of updating (resetting it back). The question is, would that be a bad thing if it did happen?
So for stalling H-int, the longest is 44 cycles, mid is 30 cycles, and minimum is 22 cycles. The code is a little difficult to follow at first, because I'm trying to optimize for few case cycles per delay. You might notice that if a sample is going to be played, interrupts are enabled during that process, but disabled for the counter. If a sample isn't played, the branch that skips it - leaves interrupts disabled until the counter decrement can finish its process.
Actually, worse case scenario of H-int delay would be 45 cycles; no sample to play, decrement counter but no psg player call, exit routine.
So, you want overhead? Just the overhead of the decrement counter and no sample playing or player call? 45 cycles per call (a call being TIMER set to max speed). If you re-sync TIMER on internal vsync interrupt, you get a nice integer of 116 calls per frame (and no drift of the psg player relative to the frame - async.. eww). 116*45 = 5220 cycles or 4.38% cpu resource overhead.
Note: I think you stated something like 433 cpu cycles per scanline. I'm not sure if you were talking absolute or relative to overhead: VDC scanline is 455 cpu cycles long (the frame rate of 262 mode is something like ~60.1hz).
Quote
Is it slower on 6280 vs. 6502? 6502.org lists it as 6.
Some things are +1 cycle longer on the PCE (but unlike the 65x, there are no page boundary penalties.) http://www.pcedev.net/blog/files/Otaku_no_PCE_cribsheet_page2_0_1_4.png
EDIT Opps. I forgot to update ".EOF". It should read like this: pla tam #$04 jmp .TIMER_sampledisable
Where .TIMER_sampledisable is a label point right after stz <in_progress.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: ccovell on December 12, 2016, 11:25:03 AM
Slightly apropos of this topic, MML, case-sensitivity, and Z80 stuff, etc., did you hear about the MML driver that's in Alpha's Neo-Geo games? I did a dissection, explanation, videos, etc. here: http://www.chrismcovell.com/ADKMML.html
Who knows, maybe the overloaded MML syntax might give some ideas for customization for the PCE hardware.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 12, 2016, 01:32:08 PM
The int call is 8 cycles, the RTI is 7 cycles. That's the minimum you can possibly have on the PCE.
Quote
Note: I think you stated something like 433 cpu cycles per scanline. I'm not sure if you were talking absolute or relative to overhead: VDC scanline is 455 cpu cycles long (the frame rate of 262 mode is something like ~60.1hz).
Thanks, those are both really useful information! :D
So you're basing your percentages on 119210 cycles-per-frame?
I'd be tempted to do things a *little* differently if I were going to try to implement the permanent-timer and music-driver-running-from-the-timer, especially in the case of HuC.
From what I've seen, HuC maps the main library bank to both MPR6 and MPR7, probably in order to maintain a consistent memory layout between HuCard and CD-ROM, and have the the library code at $C000.
In that case (and in whatever case if I were writing purely in assembly), I'd probably prefer to map RAM into MPR7 so that I could change the interrupt vectors at runtime.
If you do that, then your timer routine depends upon how many channels you want to play, and your idle-case for the driver gets a lot faster, something like this ...
tirq_none: ;;; ; 8 (cycles for the INT) stz $1403 ; 5 Acknowledge TIMER IRQ. dec <driver_cnt ; 6 beq .driver_s ; 2 rti ; 7
That's just 28 cycles-per-irq, and 3248 cycles-per-frame, for just a 2.7% CPU overhead.
There is one thing ... I don't think that your sample-playback code is safe from something in a vsync or hsync handler changing the value of sample_bank or sample_ptr.
If you run the music-driver from the timer interrupt, then you'll probably get away with that, but you're may start getting problems if the music-driver runs in the vsync.
Of course ... the big thing here is that we're both still messing-around and trying to come up with solutions that work when the music-driver is called more-often that 60Hz.
I'd really rather not do that. :-k
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 12, 2016, 02:30:00 PM
That's just 28 cycles-per-irq, and 3248 cycles-per-frame, for just a 2.7% CPU overhead.
It's just a template to work with. Nice optimization though ;) If you're going to be playing samples for music, and SFX, personally I'd rather optimize for worse case scenario. If the max is 11% cpu resource, that's what I'm going to figure in when I'm allocating cpu resource per frame. Anything that fluctuates below that, such as idle cost, isn't going to help me. You have something else in mind?
Quote
There is one thing ... I don't think that your sample-playback code is safe from something in a vsync or hsync handler changing the value of sample_bank or sample_ptr.
If you run the music-driver from the timer interrupt, then you'll probably get away with that, but you're may start getting problems if the music-driver runs in the vsync.
You're totally on your game :D I didn't put it in the code because we hadn't talked that far yet: There are some questions that need to be answered first: is the PSG player going to issue/handle SFX? I.e. SFX is handled through the PSG player or outside of it. I'd assume sampled instruments would be handled inside of it.
I ran into this exact problem with my 4 channel PCM driver and how to change samples without overriding something that's in the middle of the TIRQ routine. I came up with a processing system. You send requests for driver updates (sample stuff), and the TIMER routine itself called this little "processing routine" to safely update sample regs - every 116 down count (another reason to re-sync TIMER immediately in vsync int).
But yeah, there needs to be window provided to safely update sample reg stuff of the TIMER routine. If it's done through the PSG player (or whatever music "engine" is called in its place), then that would solve a lot of problems. And likewise, SFX should probably go through it. But you can do a buffer/processor system with a hook in vsync to safely update it too (as long as TIMER isn't async).
I attached the "processor update" code to the TIMER itself with a downcount of 116, only because my 4 channel PCM driver is software frequency scaling each channel in realtime (and can stream samples to all 6 channels: 4 with frequency scaling, two fixed frequency for SFX). So it came dangerously close to not finishing in time for worse case scenario on vsync interrupt. Being this is just a simple sample stream routine, you could easily and safely put the "processor update" code in the vsync int routine. As in - directly inside the vsync handler, not a manual call in HuC itself after a vsync().
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 12, 2016, 02:35:39 PM
Also, I vote we call this "sample player" addition code as... "Muthaf*cking Juan Carlos". Because this shit's gonna rule!
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 12, 2016, 02:51:20 PM
To play a sample via writing to a single DDA channel, at 6991 calls per second, takes 11% cpu resource. It's 5% if no sample is playing (just down counting).
Here are the versions that I've come up with for running the music-driver in the vblank interrupt, and then allowing for either a one-channel-only, or a two-channel-capable timer IRQ handler.
But sensibly, if you were updating the music-driver in the vsync, and weren't actually playing any samples, then you'd just disable the timer interrupt completely and have a 0-cycyle, 0% cost.
It's such a minimal extra-cost to go for the two-channel-capable driver that it seems like it would be well worth-it.
13.18% worst-case cost for two channels of samples isn't stunningly great, but it doesn't seem too bad, either. :-k
Here's the code, and please let me know if anyone sees any problems/mistakes ...
13.18% worst-case cost for two channels of samples isn't stunningly great, but it doesn't seem too bad, either. :-k
Well, compare that to Air Zonk. Air Zonk is almost 30% cpu resource max (and it hits that max every time a sample is playing)! Sure, it's decompressing samples - but.. 30%! Pfft. ~13% is fine.
Yeah, once you have the overhead of everything, adding additional channels for sample streaming doesn't increase it a whole lot.
Just some thoughts: On your 2nd channel one. I would add a cli, nop, sei right after .channel4. Your worst case scenario for each channel is 68 cycle delay for H-int, which would probably be fine, but I wouldn't push it with twice that in a worse case scenario.
Also, by not having a busy flag system (have interrupts open for the whole thing)- you're setup is going to be little less friendly with code using small Txx in 32byte segments during active display - and worse case scenarios in all settings (H-int and TIRQ). Just something to note. Might want to recommend or write block transfers with 16byte or 8byte segments with Txx.
These following ideas might not be popular for HuC, but I'll mention them anyway:
It won't save a whole lot, but if you pad sample with some 0's (assume all samples are made of 116 byte segments). You can run a segment length counter in vsync, and remove the BMI to .EOF check, it only saves 2 cycles per channel though.
Likewise, you can speed up if you're using two or more channels - if you store 116 samples as 128 byte segments (bytes 117 to 127 are null - do nothing). And then align them to 128byte boundary in rom/memory. A little bit a growth (the size of 7.68khz but the playback of 7khz), but now you don't need to check bank boundary crossing in the TIRQ routine itself - AND.. all samples regardless of their memory address can all use one Y index reg value. Incrementing to the next 128 segment would be done during vsync or on the last 116th call. Stick the TIRQ routine inside of ram, and you save some more cycles with self-modifying code. What's the thing take up now? 200 bytes?
Something I'm curious about: Why channel's 3 and 4? Why not channels 0 and 1? Channel 0 saves you 2 cycles. And leaving channels 4 and 5 free allow noise mode for both of those while samples are playing. 7khz is pretty good for almost all drumkit samples, but not so great at short/closed hi-hats. Noise channel is good for those. Just some thoughts.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on December 12, 2016, 04:30:04 PM
Also, I vote we call this "sample player" addition code as... "Muthaf*cking Juan Carlos". Because this shit's gonna rule!
I vote we move the assembly sample playing bromance all out of the MML thread to somewhere else because it's probably scaring people away from MML and basically has dickall to do with MML, thus clogging the thread up with something else.
Slightly apropos of this topic, MML, case-sensitivity, and Z80 stuff, etc., did you hear about the MML driver that's in Alpha's Neo-Geo games? I did a dissection, explanation, videos, etc. here: http://www.chrismcovell.com/ADKMML.html
Who knows, maybe the overloaded MML syntax might give some ideas for customization for the PCE hardware.
Lol, that damn Magician Lord sample. It's so goofy.
I'd be curious what they composed with back then. I wonder if they just typed the music in after composing it elsewhere, or what
It's good for the most part that they stayed fairly standard, but I do not see why they went with > and < meaning backwards things.
I wonder if it was on accident?
I would personally like to avoid introducing the concept of case sensitivity because that will be a recipe for disaster and annoyance, but we have definitely already added some PCE specific things to Squirrel.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 12, 2016, 04:40:14 PM
Slightly apropos of this topic, MML, case-sensitivity, and Z80 stuff, etc., did you hear about the MML driver that's in Alpha's Neo-Geo games? I did a dissection, explanation, videos, etc. here: http://www.chrismcovell.com/ADKMML.html
That's so darned amazingly cool, I wasn't aware of that at all. Thanks for posting that! :dance:
There are some questions that need to be answered first: is the PSG player going to issue/handle SFX? I.e. SFX is handled through the PSG player or outside of it. I'd assume sampled instruments would be handled inside of it.
Any sane music-driver for a console also needs to handle sound-effects.
I have no idea what modifications it would take to hack the System Card Player to play samples as either drums, or as SFX.
Honestly ... I just don't care.
I'd much-rather have an open-source replacement (with a clean copyright status) that could play samples.
From the POV of my driver that I'm converting at the moment ... "yes", both sound effect and sample support are handled.
I do not currently, and probably won't-ever, handle the case of restarting/continuing a music-channel sample that gets cut-off by a sound-effect sample.
Fixed-rate samples in music-channels are normally limited to drums and short things like that where you don't object to dropping-out a single hit/note.
But if someone cares-enough about the capability ... that's why stuff like this should be open-source these days ... so that they can go and add it themselves.
Quote
I ran into this exact problem with my 4 channel PCM driver and how to change samples without overriding something that's in the middle of the TIRQ routine. I came up with a processing system. ... But yeah, there needs to be window provided to safely update sample reg stuff of the TIMER routine.
I think/hope that you'll see that the code that I posted above is immune to this problem, and needs no special handling. You just disable the sample playback (or interrupts) before changing the pointer to the sample. Trivial.
It should also be completely safe for use around hsync interrupts, and 32-byte Txx transfer instructions. :)
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: elmer on December 12, 2016, 05:04:58 PM
Well, compare that to Air Zonk. Air Zonk is almost 30% cpu resource max (and it hits that max every time a sample is playing)! Sure, it's decompressing samples - but.. 30%! Pfft. ~13% is fine.
Reply move to the PCM thread to stop thread-bombing Arkhan! :lol:
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Bonknuts on December 12, 2016, 05:13:13 PM
Well, compare that to Air Zonk. Air Zonk is almost 30% cpu resource max (and it hits that max every time a sample is playing)! Sure, it's decompressing samples - but.. 30%! Pfft. ~13% is fine.
Reply move to the PCM thread to stop thread-bombing Arkhan! :lol:
Since you're doing your own engine/driver/whatever.. make a new thread! I got something I wanted to share with you, now that you have a TIRQ routine.
Title: Re: MML: What are people's actual complaints with the damn thing
Post by: Arkhan on January 05, 2017, 05:58:42 PM
https://www.youtube.com/watch?v=ewD7aC4OIm8
LOL.
This sandbox MMO called Archeage apparently uses MML, and even has a little tutorial in it.