Ah, the long list of things I just don't have time to do.... This diary is, without a doubt, one of them.

Project update:

• Novel: first content-complete draft done. Revising.
• Movie: made a DVD of The Music Box, almost finished
• pitch correction: still low priority
• NetBSD-mac68k driver architecture redesign: maybe soon

That last one is scary. I'm trying to come up with a real software fix for the whole clock drift issue by moving all the real work for I/O from the hardware interrupt context into a high priority kernel thread context. I'm not sure if I'll end up making any scheduler changes or not. That depends on whether there's a neat interface for making a kernel thread schedulable from within the hardware interrupt context.

I created a prototype of part of that rework about a year ago, but I kept getting kernel panics when trying to create the kernel thread, and nobody had any suggestions. At the time, I didn't have time to try to debug it further.

Meanwhile, I'm trying to finish recording a song from which we used just a short snippet in the movie, since I never actually bothered to record it for real....

Wow, I haven't posted a diary entry in over a month. Must say something....

I basically dropped the pitch correction project on the floor in favor of more pressing matters. In the past few weeks, I've fixed about a dozen bugs in HeaderDoc, and am working on some other doc-related code. I've also written a lot more text for my novel.

As if things weren't sufficiently insane, my Airport base station flaked out over the weekend. Wednesday night, Louis Gerbarg and I managed to get the two defective capacitors removed from the board. This afternoon, one of my co-workers in Tech Pubs helped me get the new parts into the board. Since they have to pass through vias, it isn't easy getting the parts into the board, i.e. you pretty much have to heat the via while you shove on the part. Blech.

This weekend, I'm planning on really going at the novel hard. My goal is to write at least 5000 words this weekend. Ahem, yeah, right. We'll see what happens. I'm betting on more like 3000.... Not that I care that much about the word count, but it makes a good metric for the progress through the story. I also recently realized that I brushed through many weeks of story line way too quickly, and so I'm going to go back and fill in a few bits that I skipped. Ah, well, must get back to file system hacking. Cheers.

After a few dozen bug fixes, the code appears to be successfully doing pitch correction. I'm still working on improving the smoothing code to make the quality acceptable at the FFT block boundaries. So the automatic retuning code isn't finished, but with a few more tweaks this thing should be shippable.

I have to stop working on this to draw tomorrow's Tech Magazine strip. I hope to finish this tomorrow night.

Phase 2 of the pitch correction software is complete. The correction table appears to be being built correctly. I have a few more corrections to make in my pitch shift code, in that I need to move the data into a separate buffer to avoid overwriting data that needs to be read when shifting the pitch upwards, or else I need to make it go the opposite direction in that case. I'll decide which is more efficient tonight and go with it.

Also, I still need to write or borrow code to rip AIFF headers off the input file and write then to the output file.

Once those two things are fixed, this thing will be ready for its first test. I expect it to sound like crap, since this is a first cut, and the bulk of it was hacked together in a single evening... but it should be entertaining, anyway.

Future improvements:

1. Better handling of boundaries between transform blocks,
2. During the shift, a weighted average of the two nearest array elements should be used to generate the new value, instead of simply truncating the double to an integer index.
3. Make the transform block narrower to minimize aliasing and latency.
4. Rewrite main() to take arguments for the various parameters instead of passing hard-coded values to the subroutines.
5. Experiment with different FFT implementations to try to minimize latency.
6. Once it works suitably, rewrite as a VST plugin.

I've taken a break from kernel hacking to do something more pressing. I got annoyed with the cost of software for automatic vocal pitch correction (on the order of $350-$700). It's simple enough that there's no reason for it to be so expensive that only people who do this stuff professionally can afford it.

Don't get me wrong, I have no problem with paying for well-written software that's complex in nature. I'd pay $350 for an audio editing program. But paying $350 for a mere audio filter? I can buy a stand-alone hardware solution for $500, and unlike software, if it doesn't work, I have the right to send it back or sue. There's no way I'd pay that kind of money for a piece of filtering software, even if I -had- that much to spend on it (which I don't -- I'm doing audio recording entirely for fun in my spare time as a hobby).

To make matters worse, none of the companies appeared to have a Mac OS X version, making their software completely useless to me. I contacted one of them, and they suggested they might have one by the end of the year. Thanks, but no thanks. If I'm going to pay that kind of money for something that does so little, it darn well better have been Mac OS X native three months ago.

So, in desperation, last night, I pulled together FFT routines and fundamental frequency detection code, and I wrote a lot of glue code, including a first cut at an arbitrary frequency shifter. With the exception of generating the frequency table and actually doing the file I/O, I essentially have a first cut at the software in a little over three hours of coding, assuming my reasoning was sound and I didn't make any stupid mistakes in the math.

The basic idea is this:

1. Take a chunk of size 2^k for some k.
2. Detect the fundamental frequency.
3. Look in a table to determine the frequency of the nearest note.
4. Apply a FFT to the chunk.
5. For each frequency-domain array slot, multiply the array index by the new frequency and divide by the old to get the new index.
6. For each slot, copy the value stored at the new index in the input array into the slot specified by the old index in the output array.
7. Apply a reverse FFT to the chunk.

I'm also working on some clever tricks to avoid glitches at the FFT chunk boundaries with as little aliasing as possible, if my theories hold. The real trick is to build up the table. There are three parameters:

1. Base frequency (i.e. A = 440),
2. Temperament (equal tempered, C major, D minor, whatever), and
3. Compression ratio.

I'll probably only do equal temperament in the first cut to save time. The third option is perhaps the most interesting. The idea is to assume that the singer is pretty close to on-pitch, i.e. not a tone-deaf singer. Instead of hard-locking the voice to an exact pitch, it would instead move it "closer" to the right pitch.

Within a certain range, it will lock it to the right pitch, but beyond that, it will slowly move away, becoming faster as it gets closer to a semitone away, with the semitone being unaltered, and the exact opposite as it gets closer to the next note up or down.

The implications of this are that a slide, glissando, etc. will end up sounding more rapid, but should otherwise sound reasonable, despite the modifications. Similarly, intentional vibrato will be reduced, but generally not eliminated. The idea is to end up with a voice that doesn't sound like it has been artificially "forced" to pitch, i.e. with a certain amount of pitch variation, but that still sounds basically in tune.

Barring any nasty bugs, I expect to have a first cut (equal temperament only) finished this weekend at the latest. Wish me luck.