Jump to content
  • entries
    10
  • comments
    53
  • views
    12,572

Atarimusicology


Guest

894 views

I thought some of you might be interested in this, as it pertains to the 2600 (but mostly to music). I figured this was the best place to post it. This will undoubtedly be my longest (and maybe only) weblog entry (it's not a blog!).So, whilst I was working on some Metroid music for my brother, I began to get more familiar with the 2600's musical limitations. Stuff like frequencies, cents, and that kind of stuff. That boring stuff has always kind of intrigued me, so naturally, it piqued my interest. A little while ago, I did some calculating, and came up with a function that could represent any note, at any octave by a number; specifically, it's frequency. Here's the function I came up with:f(x) = 440(2)^x/12where x is the "pitch number" of the note. For example, A4 (440Hz) occurs when x=0. A5 (880Hz) occurs when x = 12 (yes, I'm a math major). Every 12 notes is an octave. You can prove that with a keyboard and approximately 12 fingers. You can determine the frequency of any note by figuring out its relative interval (distance) from A4 (the A below middle C).After I discovered this (which, honestly, should've occurred to me earlier when I was studying this for fun), I took a few months off so that I wouldn't become a complete nerd. Then, when my bro asked me to hook him up with some sweet Metroid action, I once more familiarized myself with the 2600's frequency charts (compiled by Paul Slocum? I don't know the link, sorry...). After doing a few tunes, I realized that relying completely on those charts was not getting me what I needed. Specifically, I had no freaking F#, and everyone knows you can't write the Metroid theme without an F#. So, I did some hunting, and discovered that the "setups" (as Paul Slocum called them), were insufficient for my needs. Basically, what he did was compile a list of pitches (that could be produced by the Atari) that were reasonably in tune with each other (I think about plus or minus 10 cents were his boundaries). So the setup that I was referring to was essentially a C major scale about 10 cents flat (from 440Hz, perfect pitch). However, what I discovered was that there were other notes that were in tune (within 10 cents of 440Hz) that weren't listed. So, I went through all 174 (or however many) notes that are within the hearing range of humans and that are producable by the 2600, and found some key pitches that were close enough to be in tune with the others (G#5, for instance).However, nothing is ever that simple, since any frequency can be within 50 cents of perfect pitch (100 cents is a half step, so if C5 is 50 cents sharp, it is halfway between C5 and C#5), and the 2600 has at least one pitch for each cent (-50 to +50 from 440Hz). So, by only making use of the pitches that are around -10, I was alienating more than half of what is possible on the 2600. That's no good. And that leads to the crux of this novel.Do it! My first attempt at sorting the pitches capable on the 2600 (based on Slocum's guide).This was quite functional (and very helpful when trying to write stuff), but it didn't capture the essence of what I wanted to know. At the time, I was only looking at the relative in-tune-ness of pitches at or around -10 cents. So, any note that was within -40 to +20 was in consideration for use in Metroid. What I really wanted to determine was the relative in-tune-ness at or around any frequency (and not just 440Hz). And this is what happened one weekend: Do it again!This (cr)applet will give you the relative in-tune-ness of all the pitches in the 2600 library around [almost] any frequency (assuming frequency is discrete and not continuous). In case that's confusing (as if anyone's still reading this), here's how to work it:1) Choose a frequency with the scrollbar. I call this the "base frequency" because it is used to calculate the percent off (cent) of each pitch. It's what everything else (cents off, note name) is based on.2) Choose a range. Choosing a range of 50 cents will return every pitch in the 2600 library, because every note is within plus or minus 50 cents of any given frequency. Choosing a range of 25 will return all the pitches which are within 25 cents (plus or minus) of the given frequency.3) Choose PAL or NTSC4) Choose to sort by note name or by percent off.Here's what it looks like:pitchsorter.JPGHere's some more math (the fun and interesting stuff, in my opinion):I needed to fiddle with the above function so that instead of giving it an integer and returning a frequency, it needed to take a frequency and return an integer. So the new function used to calculate the percent off and to evaluate the note name (I won't go into how the code does that) wasf(x) = 12*log2(x/bf)where log2 is logarithm base 2, x is the frequency of the pitch you're evaluating, and bf is the base frequency (determined by the user). So, for example, suppose you want to determine the note name of the pitch with frequency 100, and wanted to determine its percent off from 440Hz. Note that 440Hz and 13.75Hz are identical for my purposes, since 440Hz is A4 at perfect pitch and 13.75Hz is A-1 (two octaves below the lowest note on a piano) at perfect pitch. I used 13.75 so that the lowest note that the 2600 could produce would return a 0 when its frequnecy was evaluated by the function (the previous function would have returned -72, or something like that). It's a little more complicated than that, but I won't go into it. So, plug the values into the function, and you get12*log2(100/13.75) = 12*log2(7.2727) = 12*2.8625 = 34.35So, to determine the note name of the pitch (relative to the base frequency) with a frequency of 100Hz, you round off to the nearest integer, which would be 34. Then, you count up 34 notes from C-1 (which is the note when the rounded integer is 0), and you get G2. To calculate the cent, simply subtract the decimal (34.35) from the rounded integer (34). 34.35-34=.35. So your pitch with frequency 100Hz is a G2, 35 cents sharp from perfect pitch (440Hz). Anyway, the stuff directly above is what I was really interested in; the fact that I used Atari 2600 frequencies is only because they happened to be conveniently on hand. Also, notice that the PAL frequencies are much more accurate than the NTSC frequencies. That's because the program calculates the PAL frequencies based on the NTSC frequencies (specifically, it takes the NTSC frequency and divides it by 1.007788836 to get the PAL frequency. Consequently, my PAL frequency/percent off values are slightly more accurate than Paul Slocum's (mainly because I round to three significant digits, and he only did to one). I did find one mistake in his charts, though: pitches 16 and 17 in distortion 14&15 (Bass/Pitfall) have their cents flipped: D#0 should be +40 and D0 should be +42. That was the only mistake I noticed, although I didn't look real hard at anything else: I just happened to notice those two.So, if you didn't understand anything of what I just wrote, basically the applet I created lets you pick a frequency (or a percent off from perfect pitch), and calculates the relative in-tune-ness of every other possible pitch. So, if you wanted to know in-tune-ness of note around a frequency that is +40 cents from 440Hz, this applet will tell you. Also, -10 cents is the best frequency to compose at, because you have 40 (usable) pitches that are within 15 cents of that frequency, which is more than any other frequency. What was really annoying about writing the applet is that you can't compute anything without log base 2, which, conveniently, Java doesn't support (Java can only compute natural logs, base e [2.71...]). So I had to write an additional program that would calculate the log base 2 given the value of the natural log (multiply by 1.442695, if anyone's curious). Then, since that would output some hideous decimal, I needed to round it to the nearest thousandth (or hundredth, at least, to be more precise than the existing guide). Unfortunately, while Java has many rounding commands, all of them round to the nearest integer, and none of them (that I found, anyway) round to a decimal place. So I also had to write a rounding program, which sucked, due to Java's unfortunate use of scientific notation. Anyway, I did it, and I find it quite fascinating. I played with it for about an hour after I finished it. :)Got that?

5 Comments


Recommended Comments

Nice applet. I saw that the other day; I think before it was finished (it looked a little different). I was going to ask you about it but I forgot.

Link to comment

Back in 1994, I wrote a little Pascal program that would take a list of notes and 'priorities' and try to find the key in which the specified notes would be most in tune with each other. It worked decently, but was not without limitations. It only used the two lead voices, and it couldn't really judge what things would 'sound' out of tune. In some cases, a note will sound bad if it's even a tiny bit sharp, but it can be considerably flat and still sound okay; in other cases, the reverse is true. Some notes can be way off and sound fine; others will sound bad if they're not almost perfect. The only way to really judge what works is to listen and see.

 

BTW, I do sometimes wish I could go back in time and sneak a few transistors into the TIA to kill half the audio clocks for certain AUDCx values (especially since many values are "duplicates" anyway). Too bad I don't think anyone even considered the possibility of doing music while the thing was being designed.

Link to comment
Have any unused and original music just laying around?

Of course! :)

 

 

Nice applet.  I saw that the other day; I think before it was finished (it looked a little different).  I was going to ask you about it but I forgot.

Yup. The main difference between this and the first applet I showed you is that I didn't want to work hard enough to make the first one cool. Then when I started looking at the charts in greater depth, I realized that it could be much better (i.e. more useful) than it was. As it is, the new applet isn't real helpful to anyone who doesn't understand music, but I really only wrote it for myself, as an experiment.

 

That's very cool. Although I don't understand music (or programming) well enough to use it, I get the concept.

Thanks, although I don't know anything about 2600 programming. And honestly, it's not really meant for other people to use; it was more of a diversion for me (I didn't really make it very user friendly, so it's probably a little cryptic to anyone who's not me).

 

Back in 1994, I wrote a little Pascal program that would take a list of notes and 'priorities' and try to find the key in which the specified notes would be most in tune with each other.  It worked decently, but was not without limitations.  It only used the two lead voices, and it couldn't really judge what things would 'sound' out of tune.  In some cases, a note will sound bad if it's even a tiny bit sharp, but it can be considerably flat and still sound okay; in other cases, the reverse is true.  Some notes can be way off and sound fine; others will sound bad if they're not almost perfect.  The only way to really judge what works is to listen and see.

 

That's kind of what I was trying to accomplish, but it's more of a general solution. This won't give you the key you should compose in, you have to figure that out for yourself (which is why it's not very user friendly). I suppose I could actually implement key-recognition, but only if someone really wanted me to.

 

That bit about "sounding" out of tune is kind of what interested me in the music of the 2600 in the first place. The sporadic frequencies of the pitches force you to be creative. It's hard to visualize what may or may not sound good. That's what this applet helps do.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...