MML Debate (split from "It's MML time." topic)

[Tom]

Since Squirrel is compiling for the system card PSG player, I think the player itself needs to be more documented on the hardware side. Especially if people are going to start using crazy macros for exploiting cool/unique sounds (btw OPL3 with hard core macros is pretty impressive). And an explanation of the period based system, volume levels in decibels, etc and how it relates to the parameters of the envelopes, slides, vibrato, detune, etc of the PSG engine. I've been spending the last week or so modeling instruments on something similar, and you really need to know this stuff (like hardcore MOD aficionados know all the timing quirks and exploit them) - so this would very much apply to this PSG engine. Just my two cents. (I do plan to trace though the system card player code and document all timing related things and exploits).

[Arkhan]

Since Squirrel is compiling for the system card PSG player, I think the player itself needs to be more documented on the hardware side. Especially if people are going to start using crazy macros for exploiting cool/unique sounds (btw OPL3 with hard core macros is pretty impressive).

Good to see you using the term macro in this situation.  .   What exactly do you mean by hardcore macros though?   Macros are just patterns in the tracker sense, only alot more flexible...  They wont offer anything you cant get by just smearing a chunk of MML together, other than saving space, and cleaning up the file.

And an explanation of the period based system, volume levels in decibels, etc and how it relates to the parameters of the envelopes, slides, vibrato, detune, etc of the PSG engine. I've been spending the last week or so modeling instruments on something similar, and you really need to know this stuff (like hardcore MOD aficionados know all the timing quirks and exploit them) - so this would very much apply to this PSG engine. Just my two cents. (I do plan to trace though the system card player code and document all timing related things and exploits).

Having a full on hardware instruction/timing documentation on the player outside of a usage explanation of each of the functions like hcf asked for seems like it may be a bit of overkill.  The manual already explains how to use everything, and what's available command wise, so through basic experimenting, most tricks/unique sounds/possible exploits will probably be discovered in no time.   

This is just my opinion, but I don't think anyone currently using Squirrel outside of like me, the old man, you, and say Chrlymac, really give a damn about the detailed technical details.    That was the point of doing this.  People who just want to make music, now can, without having to sweat the details.

but if enough people actually ARE interested in it, I suppose it could be arranged, though the majority, if not all of it, is already explained in two different books..

[TheOldMan]

Tom:

First of all, you have to remember all of squirrel was written *without EVER* looking at a dump of the system card bios. All the information we used is publicly available, or is a direct result of what is called "black-box" testing: Twiddle a single knob, see what comes out, then figure out what had to happen to do that.
 So in the interest of allowing everyone to see how the parameters effect things, here's what we have been doing:

1) Create a simple test mml file. We tend to use the standard c-scale. Get it to work with squirrel, so you know how to compile songs and make them work.
2) Add a single command to the file (ie, @e001), before the mml. Compile it and play it, so you can hear that it works.
3) Now that you know your command is right, start tweaking that value; It really helps if you run in ootake, since it has a write-to-wave option. You can then open the wave in an editor (we use a very old, free copy of cool-edit) and SEE what effect it has.
4) Repeat until you understand what the parameter is actually changing. I will warn you that the pitch/frequency stuff is hard to understand. A variation of 1 cycle isn't real noticeable, so try something bigger, like 50 or so.

Keep repeating until you have checked out all the parameters.

...Any particular parameters you want to check out ? We'd love to here what they do, so we don't have to repeat your experiments.

[Tom]

What exactly do you mean by hardcore macros though? 

 A macro is a substitute for a series of registers/parameter updates called by a name. A macro in the music world would be build a specific type of sound from specific combination types of volume, note, cuts, frequency, modulation, delays, etc. You create an whole new unique instrument sound, but most often it doesn't scale because of the hardware or software engine (cpu isn't going to waste computational time implementing X feature). A series of macros for different octaves to "correct" for this, or even on a note for note basis (like scaling FX with notes). Those are hardcore macros.

 Learning how a period system works and what the real volume levels are, etc - the true hardware not the pseudo stuff this system card and other engines give you - are key for creating these types of macros. Even for something as simple as detune. -1 to note in octave 7 is a huge difference than that of just 2 octaves lower. Because of the non-linear steps, but also because the resolution between notes you loose as you go up in frequency/octave/note scale. Detune of -8 at octave 1 might be equivalent to detune of -1 at octave 7 (and even at that, might be with a range error). And the steps in between would have to be scaled accordingly.

 Vibrato (fm on PSG player) is also related to the period based system. Those values mean something. They scale differently, positive numbers have a different weight than negative numbers, etc. You might want only a negative to zero waveform, or positive to zero waveform. LFO might be slow, but it still has an effect on notes relative tune to frequency.

Code: [Select]

                Note frequency->      ____________________________________________________
                                       \    /\    /\
                vibrato waveform ->     \  /  \  /  \  /  etc
                                         \/    \/    \/

 VS something like

                                       \    /\    /\
                vibrato waveform ->     \  /  \  /  \  /  etc
                                         \/    \/    \/
                Note frequency->      ----------------------------------------------------


 There's also compare logic styles on the code side that might be exploited to do a function that original wasn't intended (facilitating an FX you might be doing by hand). Like decrementing logic. Does it decrement before comparing to 00 or does it check for 00 first (there's a reason for having both types of decrement systems)? Stuff like that. I was able to use vibrato on another engine as a delay+portamento function because I exploited this compare logic (it would have required extra work and timing other wise).

 And volume. Pan or channel (envelope). PCE doesn't have 30,000 values for volume, so that's obviously a fixed point system. But there's no explanation of what the real values are. How do they relate to the real volume table shown below?

Code: [Select]

                   max volume
                   -1.5db
                   -3.0db
                   -4.5db
                   -6.0db
                   -7.5db
                   -9.0db
                   -10.5db
                   -12.0db
                   -13.5db
                   -15.0db
                   -16.6db
                   -18.0db
                   -19.5db
                   -21.0db
                   -22.5db
                   -24.0db
                   -25.5db
                   -27.0db
                   -28.5db
                   -30.0db
                   -31.5db
                   -33.0db
                   -34.5db
                   -36.0db
                   -37.5db
                   -39.0db
                   -40.5db
                   -42.0db
                   -43.5db
                   -45.0db
                    -infinity


 Is there any specific reason why only -$7c00 and +$7c00 can be used? Why are they limited to the full scale of the 16bit signed number? What happens when you use an value out side that range. Etc.

 Knowing the system underlying hardware and the software engine that runs it, allows for exploits and such. It's also good that you don't have to sit there blind and go through like 200 combination's until you got what you're looking for, for that tempo, tick rate, note range, etc. Even knowing what I know about the audio hardware and my engine, I still have to use a PC audio capture and analyze specific points of the envelope to tweak the sound I wanted (and the difference was small because I'm using a simple 3bit float. The sys card PSG driver has a huge float part in comparison).

 Anyway, I'm interested in getting as much unused potential out of the audio chip that's possible - and giving that knowledge to people who'll take advantage of it. Exploits, crazy ass macros, etc. Macros are similar to patches, other people can use them too. Someone might create that perfect pluck bass guitar sound that still eludes the PCE music lib (with the exclusion of wave samples) or perfect drop bass (SOR style), more synth style trumpet sounds with hardcoded tremolo ontop of volume envelope, etc.

Having a full on hardware instruction/timing documentation on the player outside of a usage explanation of each of the functions like hcf asked for seems like it may be a bit of overkill. 

 For the average composer, maybe. But it's been my experience that there are a lot of technical minded chiptuners out there that love to push a systems audio setup.

This is just my opinion, but I don't think anyone currently using Squirrel outside of like me, the old man, you, and say Chrlymac, really give a damn about the detailed technical details.    That was the point of doing this.  People who just want to make music, now can, without having to sweat the details.

 But you could attract "those" type of composers.

 This just doesn't extend to music, but to sound FX. Because face it, if someone where to create a game on the CD target platform - more often than not they'll be using CDDA. There exists no hucard version of this PSG player (yet). Dave only implement some of it and has yet to be thoroughly tests to see if it outputs 100% same sounds. Anyway, this information would also prove useful for people creating FX and not using the music part.

 Anyway, those are my explanations. In all likelihood, there's going to be barely any completed dev on the PCE outside of a few demos and such. I just want to hear some awesome tunes pushing the PCE's chip. Doesn't have to be from a game, for me to enjoy it. And the likelihood of that happening is far greater than any game that might come out (or even demo).

[Tom]

Tom:

First of all, you have to remember all of squirrel was written *without EVER* looking at a dump of the system card bios. All the information we used is publicly available, or is a direct result of what is called "black-box" testing: Twiddle a single knob, see what comes out, then figure out what had to happen to do that.
 So in the interest of allowing everyone to see how the parameters effect things, here's what we have been doing:

 Develo's info and the (somewhat recently released Hu7CD manual). Yes, I know. That's why I stated my original point. Learn more about the original software player to understand it better. No harm can come from that. And it's not impossible. And there are benefits, including replicating it on a hucard project.

 I don't know about you, I don't like having to relay on shooting blind. Yeah, this is new and it'll take a while for people to get "patches" out there (patches in the comparative sense of FM instrument defines). And there's always trial and error. But trial and error + underlying understanding goes a lot further IMO. I didn't come from the music script world. I came from the tracker world where composers hardcoded many of the FX they wanted and with brilliant results. Many amazing/clever examples. I'm sure some of it was trial and error, but the advance users knew where to start to begin with and what was going on for any type of anomaly/side effect (tick lengths, special case 1 tick delay, sync channels, note delays, etc). More info doesn't hurt and if anything almost always helps somewhat. Music scripting for a command string based engine is much more powerful than.. I'd probably say almost any tracker. But I think both can barrow from each other.

...Any particular parameters you want to check out ? We'd love to here what they do, so we don't have to repeat your experiments.

 All the function compare logic and just the logic itself Having already RE'd two game sound engines and built both (well, ones public. Actually, three engines if you count the custom MOD player), I'm talking from experience. Because having to replicate everything 100% meant anything that was slightly off could make noticeable differences. Not only that, but I saw ways to exploit the logic to get the functions to perform in ways they weren't designed to (without changing the code). E.T.C

 I know Arkhan wrote the compiler for game developers, but his compiler assembles everything into a PSG player binary compatible song. There's nothing stop someone from make a generic free range setup to inject the binary into the HES of the same player, so chiptuners could use this too and not have to worry about emulation, C, etc. Instant HES file is desirable in the chiptune community (although so is have something that'll run on a real hardware - but that can also be done via inject and without involving HuC. Just using a prebuilt ISO).

[Arkhan]

A macro is a substitute for a series of registers/parameter updates called by a name. A macro in the music world would be build a specific type of sound from specific combination types of volume, note, cuts, frequency, modulation, delays, etc. You create an whole new unique instrument sound, but most often it doesn't scale because of the hardware or software engine (cpu isn't going to waste computational time implementing X feature). A series of macros for different octaves to "correct" for this, or even on a note for note basis (like scaling FX with notes). Those are hardcore macros.

Those kind of macros can be done with squirrel also, as the macro definition can be ANYTHING syntactically correct. 
They don't just apply to just being a patch.  It could be a quick parameter changes, a series of notes, both, .. whatever you want.   If its legal MML, it can be a macro.

Learning how a period system works and what the real volume levels are, etc - the true hardware not the pseudo stuff this system card and other engines give you - are key for creating these types of macros. Even for something as simple as detune....
.. etc. etc. etc...
ed potential out of the audio chip that's possible - and giving that knowledge to people who'll take advantage of it. Exploits, crazy ass macros, etc. Macros are similar to patches, other people can use them too. Someone might create that perfect pluck bass guitar sound that still eludes the PCE music lib (with the exclusion of wave samples) or perfect drop bass (SOR style), more synth style trumpet sounds with hardcoded tremolo ontop of volume envelope, etc.

Maybe, but the average musician really doesn't care, and would most likely rather experiment to find the sound they want.  Having technical details only takes you so far and you still have to use your ears.  Manuals don't make any sound.   Most synth fanatics don't know the underlying details of how it works, but know how to use it and get the desired effects out of it.  Take DEVO for example.  Mark just abuses the synthesizer and figures out what knobs give what he wants.   Squirrel is no different.  A little experience, and experimenting goes a long way in getting the desired effect.    Once you get the basics down, moving past that is cake.  No giant ass manual required.

For the average composer, maybe. But it's been my experience that there are a lot of technical minded chiptuners out there that love to push a systems audio setup.

The technical minded people who really want to dig in, should have no problem DIYing things.  If they really are technically minded, and experienced with chiptuning, they will know where to look and what to do to abuse the chip.

Its all laid out in the manual so far, and if you know the gritty details, you'll know what to do for over the top things.  If not, don't sweat the details, because you'll still be able to make nice music, and will end up discovering neat tricks the more you play around.     Or someone else will post up their MML and you can borrow their envelopes and effects.   No problem.

But you could attract "those" type of composers.

I don't think a lengthy, TL;DR manual rife with diagrams and explanations is going to attract anyone looking to make music.   Actual chiptunes demonstrating what can be done are going to attract them.  The ones looking for that extra oomph, will find it on their own.  I am sure of it.   getting wild sounds out is not too difficult, and some of it happens on accident while seeing what something does.

This just doesn't extend to music, but to sound FX. Because face it, if someone where to create a game on the CD target platform - more often than not they'll be using CDDA. There exists no hucard version of this PSG player (yet). Dave only implement some of it and has yet to be thoroughly tests to see if it outputs 100% same sounds. Anyway, this information would also prove useful for people creating FX and not using the music part.

You can get tons of SFX quite quickly with the provided manual, and about an hours worth of experimentation.  A big old manual of all the nitty gritty nonsense isn't going to tell you exactly how to get that space-blaster noise anyways.

Youd be surprised how many games on the MSX use basic MML to get the SFX heard in game.   Easy peasy.

Anyway, those are my explanations. In all likelihood, there's going to be barely any completed dev on the PCE outside of a few demos and such. I just want to hear some awesome tunes pushing the PCE's chip. Doesn't have to be from a game, for me to enjoy it. And the likelihood of that happening is far greater than any game that might come out (or even demo).

I've got a good handful of chiptunes that aren't from Insanity that sound pretty good.  I myself am not writing songs to push the chip to the brink, I'm doing it because I like writing tunes, and I like the way the PCE sounds. 


as for barely any dev on the PCE, as far as Aetherbyte is concerned, that is debatable.    

I know Arkhan wrote the compiler for game developers, but his compiler assembles everything into a PSG player binary compatible song.

You know you are talking to the other programmer for the compiler right?    If you run the compiler, my name sure ain't the name that pops up in front of Aetherbyte.....me and him have been bouncing MML/PSG code and experimentation around for awhile now!  It all started with the putzy MML parser written in C that turned into that PCE Girl Demo.

see: "The Old Man" + "The Old dude at hurgle" in Insanity's credits.......   theres a connection here! 

Aetherbyte is growing   More brains = more code = <33333

[TheOldMan]

"All the function compare logic and just the logic itself"
I see. In that case, just disassemble the bios. It's all right there.

[Tom]

I see. In that case, just disassemble the bios. It's all right there.

 You miss understood my point. I know how to "disassemble", trace though code, RE data formats and compression, etc and even replicating it from scratch. And I know where to look for the PSG player code. I wasn't asking someone to do it for me. I was making a point that you didn't write the music engine, so don't you think you (or whoever) should take the time and trace through the code to get a better understanding of it (if you wrote the PSG player yourself, then you'd already be familiar with it)? Discover bugs, exploits in logic, more specific limitations, maybe some under discovered functions/features, etc. I mean, someone (arkhan - I thought you soly wrote this compiler?) took the time to figure out the system out enough from the manuals (and probably lots of real tests too) and to make a compiler for it. I don't particularly like writing compilers, so maybe I'm making this out to be bigger than it is. Anyway - If you have the info, why not share it. If you haven't, why not do it (get it).. and then share it. People that don't want look at the part of your doc, can skip it. Or maybe come back to it later. That's my point. But it's cool

Maybe, but the average musician really doesn't care

 Most likely, but I'm not interested in the average musician. I'm interested in the people that know their shit. It's like MODs back in the day. Sample based synthesis isn't as easy as it first appears to be. Waveforms can be of a different "note" regardless if it loops at interval of a different frequency (the simple frequency / num samples = note hz). This is why finetune was invented to begin with, not to just do a phase effect between two channels. PSG chips (not to get into another argument over what the terms means to who, this context PSG means simplistic fixed waveforms - square, triangle) don't have to really deal with this because they have fixed simple waveforms. PCE waveforms for the channel instruments have a specific tune to them depending on that frequency response range of that specific waveform data. A simple 50% square cycle fits nicely into the Hu7's (the hucard one) frequency to note scale. More complex ones need to be "tuned". I would think any musician or composer would like to know what their current instrument is tune to. And to do so, you need to know the underlaying frequency system. Period base differs big time that linear, and the resolution of the period base system also has huge effect on this (another reason why I think the SMS PSG is sucky, regardless of its "other" problems).

 Good MOD composers BITD knew this and took the time to analyze the frequency of the waveforms, and finetune accordingly (even loops parts needed to be specific to stay in tune). On the other hand, you had good composers that had no technical knowledge/understanding and their compositions tended to sound like nails on a chalk board (to me, anyway. Relative to those guys that knew their stuff). And instrument might sound fine by itself, but if it's out of tune and you play it accompanied with other instruments in tune - you hear the relative difference (at least I do). Regardless if it's tracker or a scripting language, sample based synth also requires this working knowledge IMO, along with what a period base system is and how it effects functions differently than a linear scale system, and how logarithmic volume differs from linear volume (even if the fixed point system helps a little bit in this department). See the point I'm trying to make there? Explaining the under laying hardware and it's relative to the sound output, and even more importantly how it's relative to this software sound engine. (*If this is tl:dr material, just skip to the end part for me Arkhan I gotsa quescion tere. *)


 If the average musician isn't interested in knowing how the under laying hardware/system works let alone some important characteristics, then I guess I'm not interested in catering to the average musician. It's like giving a good guitar to someone that doesn't really know much about them. Just fools around with until they get the sound they're looking for (I knew plenty of people like this in my teenage years). You need to know how to accurately tune your guitar, what octave range you're tuned in, what scale you're tuned to, etc, just for starters. That's not the best analogy. Because when you're tracking or writing this music, you're more than just some musician. You're the composer *and* you're `thee technical guy (I can't remember the job title of this person, technical guy works I guess technical producer would be close) that's balancing/mixings/etc all these instruments/sound/levels. You're all three. I would think a solid understanding of the sound hardware at some level would be good for that type of person. I think this attributes to why we see large differences in sound efficiency between composers on the PCE. Some limit the sound to PSG type music/sound. It's simple and it works. So you concentrate on the composition side instead. Others know the hardware and take advantage of it. Same can easily be said of FM. PC is a prime example. OPL2 and especially OPL3 sounded bad on the PC, but was capable of just so much more if the composers would have taken the time to learn the hardware and not just some generic midi interface that wrapped FM chip with generic defined instruments. Even examples on the Genesis (US developers).

 On the topic of waveforms, neither Air Zonk or Bonk don't finetune in real time - they have compile time detune but not realtime finetune (Bonk does relative note/octave scaling. Has a function for this). But, this could have been easily handled on the script compiler side - as long as you don't have portamento to note or are able to somehow tie a new detune to that command (slide to note command in any type of engine) i.e. destination is note+new detune value. I didn't see this on the Hu7CD manual listing of functions. Does detune take a literal value for the period system or a relative value that's corrected per note/octave on the player side(I saw that the LFO/vibrato function has an option for octave correction - strange that detune wouldn't)? If not, do you plan on adding a runtime compiler function to support this? (would be nice to port some chiptune MODs/XMs/S3Ms/etc over to the PCE. Some parts would require this).

[Arkhan]

You miss understood my point. I know how to "disassemble", trace though code, RE data formats and compression, etc and even replicating it from scratch. And I know where to look for the PSG player code. I wasn't asking someone to do it for me. I was making a point that you didn't write the music engine, so don't you think you (or whoever) should take the time and trace through the code to get a better understanding of it (if you wrote the PSG player yourself, then you'd already be familiar with it)? Discover bugs, exploits in logic, more specific limitations, maybe some under discovered functions/features, etc. I mean, someone (arkhan - I thought you soly wrote this compiler?) took the time to figure out the system out enough from the manuals (and probably lots of real tests too) and to make a compiler for it. I don't particularly like writing compilers, so maybe I'm making this out to be bigger than it is. Anyway - If you have the info, why not share it. If you haven't, why not do it (get it).. and then share it. People that don't want look at the part of your doc, can skip it. Or maybe come back to it later. That's my point. But it's cool

I never said I solely wrote anything, and said numerous times that I had assistance (in squirrel manual, in Insanity credits....)  I've had assistance for a long time now!  Since the Insanity days.  One man coding crews are rough.

Why not trace through and document the entire player? Because, The player works.  Just like the Hu7 and Develo books say.  Enough experimentation to make sure Squirrel did it right occurred.   Past that, there is no real point to a hardcore manual from tracing through it.  The manual with Squirrel right now is enough to know EVERY command possible, and there are usage examples.  More will come in time.  People are already producing tunes for it and enjoying it.   I expect sharing of ideas, and mml files to occur. 

and to take a page from your own book, if someone wants to have that deep explanatory manual, they can do it themselves.  A technically minded person can sit and explore the hardware in depth if they really, absolutely have to have it to make music.  There currently doesn't seem to be much interest in the details to warrant investing time into a perfectly working solution for PCE music, just to have some big ol' manual of explanation.   The current manual is plenty fine to make music.  Plenty fine.

why not try it out and make a song or two?  Sounds like you have experience with making music, so why not give it a whirl!

Most likely, but I'm not interested in the average musician. I'm interested in the people that know their shit.

   the average musician DOES know their shit.  This is about MUSIC, not technical specs and flailing around.  Also, the average musician is what Squirrel targets.  Music is top priority.   If you want to target something else, then YOU do it. 

See the point I'm trying to make there? Explaining the under laying hardware and it's relative to the sound output, and even more importantly how it's relative to this software sound engine.

No, I don't see the point in detailing out the hardware side of a perfectly functional music tool.  Given that it can play full classical pieces, and Amiga MOD files converted over to MML and "PCE-o-fied", No, there is no point.  If you happen to stumble upon a waveform implementation that seems out of tune, thats what your ears are for.  Tune it with the detune command and get it situated.   Any musician who is worth a damn knows how to tune by ear.

It's like giving a good guitar to someone that doesn't really know much about them. Just fools around with until they get the sound they're looking for (I knew plenty of people like this in my teenage years). You need to know how to accurately tune your guitar, what octave range you're tuned in, what scale you're tuned to, etc, just for starters. That's not the best analogy.

You're right, its a terrible analogy, since a guitar by nature has multiple octaves no matter what key you are tuned to.    Not sure what was meant by "octave range", since changing the scale/key/mode (its all the same thing, and is semantics), CHANGES the octave range..    Generally, you tune to EBGDAE, and the rest doesn't matter.  It's standard.   Using alternate, "open" tunings isn't required for most guitar endeavors.

Now, assuming your analogy is OK, giving someone a book on how to BUILD a guitar, a book on how to USE a guitar, a neck, a body, strings, and tools to assemble it, isn't going to allow them to easily find that better sound.   Handing them a guitar and letting them run with it however, will.   Practical experience often is alot more effective than studying a book on how to do it..   Do you think EVH sat down with a buncha manuals to figure out what he does?  No.  He picked it up and went *bewnenwenwenewnw* and rocked the balls off of everyone.   

If not, do you plan on adding a runtime compiler function to support this? (would be nice to port some chiptune MODs/XMs/S3Ms/etc over to the PCE. Some parts would require this).

Not at this time, or any time in the foreseeable future.  I already ported a MOD over to a PCE version.  Shadow of the Beast sounds pretty cool through Squirrel.

see: http://www.aetherbyte.com/downloadables/sotb.mp3


I'll post the mml file when I'm back at that computer.

Now if you'll excuse me, I'm going to go make another song with Squirrel now because it's fun, and I enjoy it.

[Tom]

Why not trace through and document the entire player?

 What is it with you guys? Do you not understand what I'm talking about? Did I say the entire damn thing? No. I think clearly stated the COMPARE logic of the functions. You know, the envelope functions and such. ANY type of command that takes a delay, speed, increment, etc. IT's all based on a tick base system and it has compare logic. That means timing is involved and edge case situations are involved. THAT's what I'm referring to. Jesus... is it that hard to understand?

You're right, its a terrible analogy

 Regardless of the poor analogy, you know exactly what my point is. Why only respond to the analogy with another stupid analogy and not address my point not what followed it? I mean, even if the analogy is recognized as terrible, the point following it was pretty damn clear. That's petty. You're gonna ignore the rest of that paragraph? You're not stupid, so the only thing I can take from that, is that your response for no other reason than to avoid what I said. Because if that analogy was to address what I said in the second part, that's pathetic...

and to take a page from your own book

 My own book? Note sure what you mean. I don't remember turning away anyone's request for info or for them to figure it out on their own or some such thing.

I never said I solely wrote anything, and said numerous times that I had assistance (in squirrel manual, in Insanity credits....)  I've had assistance for a long time now!  Since the Insanity days.  One man coding crews are rough.

 Heh. My memory must be pretty shitty then. 'Cause I don't remember the term "we" being used at all on IRC dev channel in that context. And never once did I hear you mention "Old man" or whatever his name is, or working with any person or giving any sort of indication of such. I don't own Insanity, nor would I guess the reference (knowing you, it'd be taken as some sort of joke or something).

  the average musician DOES know their shit.  This is about MUSIC, not technical specs and flailing around.  Also, the average musician is what Squirrel targets.  Music is top priority.   

 Guess we'll have to disagree then. And please excuse me for giving a shit about your work and trying to making some suggestions that appeal to other people - the more technical minded kind. Cause I'm sure writing this converter and REing the engine wasn't a walk in the park (And if it was, hats off to you). The more people that use it, the better. Anyway, I'll try not to make that mistake again 

If you want to target something else, then YOU do it.

 Exactly what I've been doing, sir. But thank you for your direction anyway.

No, I don't see the point in detailing out the hardware side of a perfectly functional music tool.  Given that it can play full classical pieces, and Amiga MOD files converted over to MML and "PCE-o-fied", No, there is no point.  If you happen to stumble upon a waveform implementation that seems out of tune, thats what your ears are for.  Tune it with the detune command and get it situated.   Any musician who is worth a damn knows how to tune by ear.

 If detune doesn't scale internally (as in what finetune does), then I guess they'll just have fun re-define a new detune value every different note and octave (love them macros). And screw showing anyone the period system, let them figure it out on their own... by ear, for every note That, or restricting your waveforms to meet that need.

 I just don't see why you're so against the idea of giving the explanation of the hardware. You're a bit hard headed (to say the least). Is it because you don't feel comfortable talking about it or don't have a solid understanding of it or something? I just don't see the point. I just don't get your negative attitude and reaction to this. Well, whatever. They were merely suggestions for people that aren't exactly like yourself. I posted my opinions - take 'em for what there worth, if they're worth anything at all. But you know what's best. Guess I hang around the NES musician/coders scene too much (complete opposite of this, that's for damn sure).

 I've got nothing more to say on this topic. So... someone else post some their music or something.

[Arkhan]

What is it with you guys? Do you not understand what I'm talking about? Did I say the entire damn thing? No. I think clearly stated the COMPARE logic of the functions. You know, the envelope functions and such. ANY type of command that takes a delay, speed, increment, etc. IT's all based on a tick base system and it has compare logic. That means timing is involved and edge case situations are involved. THAT's what I'm referring to. Jesus... is it that hard to understand?

No need to.  Works fine without having to document the innards for the world to see. The usage examples in the manual and the example songs give the same end result.  On a less complicated level.  It's not hard to understand:  Documenting the inner workings requires time and effort where it isn't currently needed.  Time and effort better spent elsewhere.  If someone comes along and goes "hey man, this is all out of tune and isn't coming together right when I do these certain things, whats up!?", then yes, it is finally time for explanations on these details.. 

Until then: This is everyone using squirrel:    Making music and enjoying themselves!

Regardless of the poor analogy, you know exactly what my point is. Why only respond to the analogy with another stupid analogy and not address my point not what followed it? I mean, even if the analogy is recognized as terrible, the point following it was pretty damn clear. That's petty. You're gonna ignore the rest of that paragraph? You're not stupid, so the only thing I can take from that, is that your response for no other reason than to avoid what I said. Because if that analogy was to address what I said in the second part, that's pathetic...

My analogy isn't stupid.  It is in response to your analogy! It makes perfect sense.   All the technical details in the world aren't going to instantly allow you to spew out the perfect, chip-pushing chiptune.  Using the program and practicing will. And, no, your point wasn't clear.  It's a bunch of technical "in my experience" dick waving nonsense.  This isn't mods, this isn't sampling, this isn't Amiga music.  This is MML for a WSG.  Its made so anyone can hear some music without having to sweat the BS.  Also how do you know what Mod composers BITD were doing?  Were you one of them? 

David Whittaker, and the crew from say, Agony (including Jeroen Tel), produced some pretty amazing music and it's really not pushing Paula to the limits.  What is it with "pushing it to the limit"?  It doesn't have to be some over the top, technical circus to be a good musical piece.     If I can replay Shadow of the Beast, or recreate a pretty-spot-on R-Type tune with no dilemmas, I'd say we are pretty good to go here.     This is , as close as possible, recreating the stuff actual developers could have been using.   Nowhere in the Hu7 and develo books are explanations of this stuff.  Why?  Because it isn't needed!  Really!  Your ears will explain it all.
 
Also, sidenote,  it's hard kinda hard sometimes to respond to your paragraphs without skipping/ignoring parts because they are often structured in a way that doesn't make sense.
ie:"so the only thing I can take from that, is that your response for no other reason than to avoid what I said" <<< Try proof reading things so you make sense.  You'll get better replies.   I tried not to point this out since it occurs in mostly every post of yours, but, this time it need to be said, since you asked why.   

 My own book? Note sure what you mean. I don't remember turning away anyone's request for info or for them to figure it out on their own or some such thing.

[19:15] <Arkhan> where in asazel do I use that at [standard MML syntax]
[19:16] <@tomaitheo> you don't, you either use the equates method I came up with - or you write you own MML to binary converter

Is what I was referring to.     But, I believe you have decided to actually write a converter for azasel now, so people can make proper use of things.

Heh. My memory must be pretty shitty then. 'Cause I don't remember the term "we" being used at all on IRC dev channel in that context. And never once did I hear you mention "Old man" or whatever his name is, or working with any person or giving any sort of indication of such. I don't own Insanity, nor would I guess the reference (knowing you, it'd be taken as some sort of joke or something).

*shrug* You must not have been present for all of it.   Or, I mean, on Aetherbyte.com, you see the main page has "we" and "our" and "is a small team of programmers.." etc.  Its old news.  Its been like that since the site was put up over a year ago. 

I may not have mentioned the old man explicitly as "old man" but I have referenced "my friend" and "my help" and "person who is helping" alot.  Either it was in PM with someone else I was talking to, or you weren't present.  No biggy.  It's been out there for a long time now.  Even on the title screen of Insanity!

Guess we'll have to disagree then. And please excuse me for giving a shit about your work and trying to making some suggestions that appeal to other people - the more technical minded kind. Cause I'm sure writing this converter and REing the engine wasn't a walk in the park (And if it was, hats off to you). The more people that use it, the better. Anyway, I'll try not to make that mistake again 

You should try it out and make a few tunes before you suggest things that it could use.  Just sayin', cause a bunch of over the top technical suggestions seems more like a trolly jab implying that the toolkit isnt good enough, rather than a friendly, supportive suggestion.

I think having music is going to attract users more than saying "Hey guys! We got this big ass .txt here you can read, with all this nonsense in it that is only relevant if you want to push the PSG to the edge!"

also, alot of the "reverse engineering", was mostly more like "follow the instruction booklet". 

Exactly what I've been doing, sir. But thank you for your direction anyway.

Well if you are doing it, then we here with Squirrel needn't bother, right ?   if you write a nice document explaining all of this stuff, it's all good.  Everyone wins.

I just don't see why you're so against the idea of giving the explanation of the hardware. You're a bit hard headed (to say the least). Is it because you don't feel comfortable talking about it or don't have a solid understanding of it or something? I just don't see the point. I just don't get your negative attitude and reaction to this. Well, whatever. They were merely suggestions for people that aren't exactly like yourself. I posted my opinions - take 'em for what there worth, if they're worth anything at all. But you know what's best. Guess I hang around the NES musician/coders scene too much (complete opposite of this, that's for damn sure).

Again, This is for MUSIC, not for technical dickwaving.  It's meant to be simple, and for the average musician.   I don't want to write a giant txt explaining the hardware, and period systems in great detail.   It isn't because I don't understand the hardware, or the period system, or because Im uncomfortable talking about it. 

Im against the idea because quite honestly, I don't feel like it.  Until it is apparent that those technical "NES" musicians, or other chip pushers need it, I'm not wasting the time.  Noone right now seems to need it.  We've got a nice agony tune, axel foley, I believe Ninja Spirit is working on stuff... some other people are giving it a shot.   Then theres the stuff I have done. 

We are getting along just peachy without having to invest the time into a gigantic document with all kinds of stuff you're going to end up forgetting after you read it anyway until that one specific time occurs (if it even does), when you need to know why your song falls out of tune when you do a few specific things.

So what you are reading as negativity is more like an "eh, maybe later.  Not important atm" kinda thing. 

I've got nothing more to say on this topic. So... someone else post some their music or something.

Why don't YOU post a song? Have you even TRIED it out yet?  Its pretty fun and easy.  Thats the beauty of the whole thing.

[TheOldMan]

I think this has gotten out of hand, so this will be my last response to this subject. I would
much rather spend my time working on getting the HuC player portion of squirrel working correctly.
For those who are interested in that, I currently have all the regular MML command supported by
squirrel functional (but not perfect), excluding Tempo which requires I delve into using the
timer irq; something I have been avoiding, since irq handling is NOT my strong point. I also
have the volume envelopes working, and am trying to re-create the pitch envelope adjustments.
FM envelopes are very similar, however I have not even started looking at how they operate.
I am assuming they will be fairly easy, however, I have been wrong before. Drums will,
unfortunately have to be last. It -looks- like they can be done with various sub-routine calls,
but We Will have to see how it shakes out.
And, if you have been reading this for a while, I will say I took the time out from fixing the
pitch envelope functions to play with the "back-burner" project. It is in fact possible to take
a sampled wave, convert it down to 5-bits, generate waveforms from it, and play them sequentially
via the drums. My sample sounded lousy; I don't believe 5-bit waveforms are going to give great
fidelity. More importantly, however, it worked. I don't see any reason that someone couldn't take
a sampled drum set, convert it, and set up a functional drum kit for the pce. IF someone would like
to take on that project, and shows actual progress on it (not just a "hey, I'll do it" and nothing
else) THEN I will add the MML drum notation to squirrel.

And now, we return you to the argument.....
------------------------------------------------------------------------------------------------

" "I see. In that case, just disassemble the bios. It's all right there."
 You miss understood my point....don't you think you (or whoever) should take the time and trace through the code to get a better understanding of it?"

I guess I did misunderstand your point. I assumed you had already done the disassembly and
knew how the logic and compare stuff worked. If you do, there's no problem. If you don't, its
not *our* problem. And actually, no, I don't need to trace the player code to understand it,
no more than I need to disassemble a printf() function in C. Either it works, or it doesn't.
And since it's in ROM, I can either work around problems, or scrap it and write my own.
Tracing and disassembling the code only wastes my time, and I'm not going to document a
disassembly for everyone to see; my assembler skills are good, but not good enough to catch
all the subtle nuances.

"how logarithmic volume differs from linear volume (even if the fixed point system helps a little bit in this department). See the point I'm trying to make there?"

No, not really. From math class I remember that with the proper choice of axes most exponential
functions can be graphed and explored as linear functions. Even sin and cos can be graphed this way.
It's a matter of transforming the input, figuring out how it operates, and then inverting the
transformation. Not my cup of tea, but it can be understood that way.

"Does detune take a literal value for the period system or a relative value that's corrected per note/octave on the player side ?"
That's easy. Detune takes a constant value; tell it -1 and it subtracts 1 from the value fed to
the psg to get a frequency. Fine control over exact cycles is possible, though you probably
do have to correct for different octaves if you are looking for percent adjustments or such.
Remember, we're working on an 8 bit processor here - there's nothing time-consuming or math
intensive in the player. It only has 1/60th of a second to manage 12 channels, and over 90%
of that time needs to be available for the actual game. It's short and fast.

"(Bonk does relative note/octave scaling. Has a function for this). But, this could have been easily handled on the script compiler side - as long as you don't have... "

Are you sure Bonk isn't doing transpositions? That's relatively easy and not math intensive.
Yes, those things probably -could- have been in the compiler; but then it would be a lot larger,
a lot slower, a lot harder to debug, and you wouldn't have it yet to play with. Arkhan and I had
a similar arguement over very short notes; is it really the compilers job to test the music and
make adjustments to it? No; Humans are smarter than computers, and adjustments like that are better
left to them. Otherwise, you run the risk of making an adjustment that the computer thinks is right,
but isn't. Like you said, "as long as you don't have...". That list could be endless, and you could
never be sure there wasn't something you missed. We stuck with very basic MML for a reason; adding
things to it is why it's such a pain to move songs from one system to another.

"(I saw that the LFO/vibrato function has an option for octave correction - strange that detune wouldn't)?"
Where did you see that? If you're talking about the FM Correction stuff, it doesn't correct for the
octave; it moves the LFO frequency into a new octave before using it. Not the same thing.

" I just don't see why you're so against the idea of giving the explanation of the hardware"
...Because it's already documented. See psg.txt that comes with huc. And no, how the player
operates is not hardware. We're working on documenting the player, but it's never going to go
into the level of detail you're asking for, because it's not needed for understanding how it
works.

[Arkhan]

I think this has gotten out of hand, so this will be my last response to this subject. I would
much rather spend my time working on getting the HuC player portion of squirrel working correctly.
For those who are interested in that, I currently have all the regular MML command supported by
squirrel functional (but not perfect), excluding Tempo which requires I delve into using the
timer irq; something I have been avoiding, since irq handling is NOT my strong point. I also
have the volume envelopes working, and am trying to re-create the pitch envelope adjustments.
FM envelopes are very similar, however I have not even started looking at how they operate.
I am assuming they will be fairly easy, however, I have been wrong before. Drums will,
unfortunately have to be last. It -looks- like they can be done with various sub-routine calls,
but We Will have to see how it shakes out.

Yeah, well, drums ARE the hardest part of the develo stuff.   

And, if you have been reading this for a while, I will say I took the time out from fixing the
pitch envelope functions to play with the "back-burner" project.

speaking of pitch envelopes, I gotta show you something when I remember to. .   Its that deep kick you've been searching for.  Was easier to do than we thought, lol.

It is in fact possible to take
a sampled wave, convert it down to 5-bits, generate waveforms from it, and play them sequentially
via the drums. My sample sounded lousy; I don't believe 5-bit waveforms are going to give great
fidelity. More importantly, however, it worked. I don't see any reason that someone couldn't take
a sampled drum set, convert it, and set up a functional drum kit for the pce. IF someone would like
to take on that project, and shows actual progress on it (not just a "hey, I'll do it" and nothing
else) THEN I will add the MML drum notation to squirrel.

Hmm, this goes hand in hand with the somethin I gotta show you, and as far your samples being lousy and needing a drumkit, pfsht.   I got that covered no problem.

The MML drum notation of "S, H, etc" would be nice but we/users don't exactly need it.  We will see what happens when we sample in this 80s drumkit though.   It's probably just the ticket for what we need.



And tom, something I still find funny is that not more than a month ago, you wigged out about the term "macro" in this context, and are now using it in a context you were against at that time, as if you've been hip to it all along....

and are suddenly trying to help and make suggestions with a project that you said had implementations that were "stupid" at a time when it wasn't even released yet, so you hadn't actually used it.  It's possible you still haven't used it!

That may be another part of the reason that your comments are met with a touch of negativity.   In the recent past, you haven't exactly been upbeat about any of this. 

Just sayin.