nesdev.com

Sorry for the bump, but there's good discussion here and I'd rather not clutter up the board with a closely-related topic.

I was wondering if someone can answer this question:
I'm curious about the gaps in the scale when downtuning. Know of any reasons it was designed that way?

How would you explain to a layperson what a "timer system" is, and why there are larger gaps up at the higher pitches? Is there a reason it starts off with a major scale and then eventually starts taking bigger leaps?

Well, there are some decisions in the 2A03 design that are extremely arbitrary. Take a look at the possible length counter values, for instance: http://wiki.nesdev.com/w/index.php/APU_Length_Counter.

I don't think there's really a good explanation for the DPCM frequencies. I think they're just frequencies somebody at Nintendo thought might be useful.

My wild guess about the larger gaps at the higher pitches is that there is less precision in the sample periods once it goes that high.

Tepples' totally right.

Here my GNU Octave code (can work in Matlab with few modifications):


Output:


As you can see, they didn't get the most tuned possible values, but they're very close to it. And if you change the 'round' by 'floor' (simple truncation) it outputs:


which shows that it is even closer to that algorithm.

Notice that all the values in dmcperiods are even. This means the counter is probably triggered by the APU clock, which is half the CPU clock. (Quietust traced the circuit, and it turned out that pulse, noise, and DMC period dividers are clocked by the APU clock.) So what happens when you round most_tuned_dmcperiods to the nearest even period? I don't know Octave, so I have no idea whether the following is working syntax:

And there's an exact formula for nesfreq: 315000000/176

You know Tepples, Octave is really like Matlab, with just less restrictions on the language and of course, Octave is not backed with powerful toolboxes; nevertheless, you should apt-get installthat, and also some useful packages like octave-control and octave-signal.

And yeah, you're right again:



Output:


So now it's apparent that it really correlate with notes, no doubts. That wasn't random at all.

So what about the "gaps" after the first several chromatic pitches? How many cents off are they? (Would the best case for the skipped pitches be really bad?)

Data is posted on the (old) 2A03.org forums, but since it has proved instable, I'll post the results here, and recalc them to be sure, posting at the same time my GNU Octave code to get that data, so anyone can verify how the result was obtained.


Results:

I don't have octave, but I wrote a similar python program to answer the question I was asking. What I wanted to know was what are the best-fit values that could have been used for any given note.

http://rainwarrior.ca/projects/nes/dpcm_freqs.py



Does it shed any light on why they picked the particular notes they did? I dunno, by this the choices still look kinda arbitrary to me.

Musically the note choice makes a fair amount of sense-

The entire Ionian octave at the bottom.
Most of the next octave, missing the 3rd and 7th scale degrees
The major triad of the next octave up
The root scale degree at top.

Because any desired detune and transposition can be encoded when the sample is made, this allows any song to play notes over most of two octaves in Ionian or Dorian modes.

Is it be as good as a fully programmable divisor as on the triangle and pulse wave channels? Obviously not. Would other decisions that only used 4 bits for specifying period make more sense? Yes; I think including one octave of a full chromatic scale at plus a few higher notes would probably have been a better design. But I think this is far more explicable than the restrictions on noise frequency or the duplicate pulse duty (1/4 and 3/4 have the same sound).

You can build large samples at any frequency, at whichever samplerate from the table is good for you, but interestingly it doesn't seem to be based around doing that kind of thing. In that sort of situation it would be more useful to keep your samplerates in tune with each other, rather than trying to keep them in tune with an arbitrary standard like A440 (which is clearly in use here). Note that only the lowest two Cs are exactly an octave apart; the rest are jittered up and down trying to match to A440 rather than matching each other.

It's not particularly good for short looped samples either, since the sample length is 16n+1 bytes. A 1 byte sample would be too quiet to be useful. If it was an even 16, with 16 bytes you could make a decent DPCM triangle 3-7 octaves down from the frequencies mentioned, and play it all over that major scale. However, it's 17 bytes, which detunes it by 16/17... which kind of makes the scale mostly pointless (unless you want to tune your square/triangle at A=414hz). Kinda seems like it's not intended for that either. The only place I've seen this tried was in Rob Hubbard's The Immortal, which used a 17 byte bass, but doesn't really bother to compensate for the 16/17 detune, just kinda uses it sparingly, and accompanies it with vibrato generally. 16/17 is most of a semitone off, so it's still close enough to be usable. (So for example, in track 2 he uses DPCM pitch 2, an E frequency, to play a tone close enough to E-flat to be acceptable.)

Honestly I think they're rather poorly chosen for any purpose. Sunsoft tried to make do with them, and they do an okay job, but you'll notice their basslines jump in octaves all the time and they bottom and top of the octave really never sound in tune with each other. They just live with the approximation. Note that they for the most part don't use the low samplerates where that pre-fab major scale resides, because they'd sound too muddy at such a low samplerate anyway. They're forced to use the more poorly tuned higher ones, and do the tuning via multiple samples.


If you ask what my guess is, the designer originally presumed sample lengths wouldn't have the +1, and designed the scale for short looped samples in an A440 tuning. After the first octave, just chose arbitrary pitches; F and G are good because they're in the middle but also an important scale note, I guess trying to space out the higher frequencies so there are more to work with? Other ones are just haphazardly chosen, in my opinion. Maybe they were chosen early on, intended for a different purpose, and then as a feature it was de-emphasized later on in the design process and it didn't ever get a rework.

Sure; they evidently knew just enough to make decisions for the audio hardware that are correct at first glimpse and inadequate when a person who knows more about the situation looks at it. See also: the looped noise mode's interactions with the restrictions on noise rate.

At least on the Game Boy, looped noise makes acceptable C, D, F, and G# in each octave, which allows for passable covers of the Super Mario Bros. 2 and the end of "Wish" by Nine Inch Nails (which uses a D, C, G#, F descending scale).

On a whim I decided I would try to make an in-tune 17-byte looped DPCM sample. Or, well, at least as in tune as is possible on the NES.

http://rainwarrior.ca/projects/nes/lately_tuned.nsf

So, this is a short tune with a 17-byte looped DPCM sample. It makes sure to use all 16 possible pitches. The pitch tables used for the other channels have been custom built with A-flat = 440hz * 16 / 17, to compensate for the detune due to sample length.

As you can hear, for the high notes especially, the DPCM really doesn't have a lot of resolution to get pitches accurate anyway. I'm bent over as far as I can to try and sound in-tune with the DPCM's chosen scale, and even with this the results aren't particularly magical.

The NES has never really been an instrument for precision tuning anyway, I suppose, but if I did this correctly, this is a best-case example for DPCM tuning.

Just to point out how bad this tuning scheme actually is, check out the four Cs:



Note that 0x036 and 0x06A are a total of 31 cents apart, because one rounds up and the other down! This is almost comic. You cannot use the DPCM's pitches to play an in-tune octave, except between the lowest two (which are the least likely to be used since the samplerate is so low down there).

It would have been much better to just forget about trying to hit the A440 scale and make these power of 2 multiples of each other. Sunsoft games could have had much nicer tuning in their basslines.


Also, Tepples, I'd be interested in hearing that GB Wish cover, if you have a link.