Today marks the 4th anniversary of FuzzMeasure first going on sale. Of course, I started working on FuzzMeasure is a few months earlier (mid-June 2004), but folks typically don’t celebrate the date of their conception…

FuzzMeasure really has come a long way from when I first released it in 2004. It started out as a measurement tool for calculating the impedance curve of loudspeakers. Now it’s a very powerful general-purpose audio measurement tool used by professionals in acoustics, loudspeaker, computer, and live sound industries, to name a few.

On the business side, FuzzMeasure started as a part-time hobby. It made me some extra spending money, which I would promptly put back into the hobby. I would start out spending on small things like audio hardware for testing purposes. Over time, the income grew so that I could fund new Macs to develop my software on.

In February 2008, FuzzMeasure’s monthly revenue was at a level that allowed me to leave my full-time job. I took a pay cut to do it, but the understanding that the extra time would allow me to focus on new products (e.g. TapeDeck), and improve FuzzMeasure even further.

Since I’ve taken FuzzMeasure on full-time, I decided to focus on polishing FuzzMeasure up and ensuring that it continues to grow into the absolute best acoustics measurement package, on any platform. I have run the 3.1 beta completely in the open, so that I could keep customers engaged early in the process.

FuzzMeasure 3.1 will represent the latest milestone in the ongoing conversation with my customers. Many of the features and fixes were added in direct response to the requests of the users. The few features that were dreamed up by me got further refined by the feedback from the people who depend on FuzzMeasure regularly.

So, this post is a great, big Thank-You to all my customers, the readers of my blog, and anyone else directly or indirectly involved in the success that is FuzzMeasure. Without all of you, none of this would be possible.

There was an annoying slip-up with my implementation of the log axis “pixel width detection” code in the last beta, which I fixed in this release. You probably wouldn’t notice it unless you were on a higher resolution display and like to make your FuzzMeasure windows large—it’d manifest as a far-too-dense clumping of lines on the graph. I didn’t catch the problem when I first wrote the code from my laptop, but shortly after the release I noticed it on the 30″ LCD on my desktop. :P

Also, I checked in an improvement to the way I display distortion. I based my display style on that of older printed out B&W distortion graphs, which indicate the fundamental as a thick line, the 2nd harmonic as a normal width line, and the 3rd harmonic as a dashed line. I think it looks pretty good both on-screen and printed. It’s also much easier to distinguish between distortion harmonics than in previous releases.

I contemplated a handful of alternative solutions to this, including overlaying a legend for the graph, or splitting out the signal into separate harmonics in the measurement list, but this seems to work pretty well for now. Also, from a few published documents I’ve looked through (see image on left in comparison, FuzzMeasure graph on right), this appears to be a very well-understood style of graph.

This distortion fix is the last of the major problems I planned to solve in 3.1, so from now on I’ll consider the code frozen. I’ll only fix showstoppers from this point forward.

The next beta(s) I put out will focus on updating the supporting materials (documentation, links to the discussion groups, etc.) as well as any localization fixes that are required to match the new feature set.

So, go over to the latest build page and give FuzzMeasure 3.1b6 a try.

I put FuzzMeasure 3.1b5 online at the latest builds page, so get over there to check it out.

The additions might not seem too big, but they took quite a bit of thought/effort to get fixed. Also, both of these new items have annoyed me for years now.

First I decided to solve a problem with the labeling of the frequency axis. I had a very simple algorithm which went through the logarithmic ‘major’ and ‘minor’ values, labeling and drawing major lines, and only drawing minor lines. (So, the end result was you’d see dark gray lines labeled 10, 100, 1000, 10000, and the gray lines representing 20, 30, … 200, 300, … in between).

Unfortunately, this simple algorithm falls apart if you’re zoomed into a particular range. Let’s take 80 to 180 Hz for example. The old algorithm would draw light gray lines for 80, 90, 110, 120, … to 180. However, only a label was shown for ’100′—which is useless for reading a graph.

With the new algorithm, you’d actually see labels for all the values listed above, because the number of labels falls below a threshold, causing the minor labels to be printed. As always, overlapping labels are thrown away, with preference given to major labels.

Furthermore, I added pixel-width detection and will drop the major/minor threshold provided the minor lines aren’t too dense on the screen. So, if you’re looking at the values between 3 and 5, you’d now see 3, 4, and 5 show up as major (dark gray) lines with labels, and values 3.1, 3.2, … will be drawn in light gray on the graph. Of course, this is provided the window is sized such that the spacing between those lines doesn’t fall below 4 pixels apart.

So, that fix was quite a beast. “Graphing is hard…”

The other fix I put in was to solve a long-standing gripe I had with my 3D waterfall plot’s mouse control. In the past, I’ve used some Apple sample code (trackball.{c,h} for all you developers in the audience) to provide mouse-based control to the 3D scene. In a nutshell, it acts like a giant sphere is mapped to the display, and your mouse clicks control the positioning of that sphere.

Anyway, the problem that’d show up was the graph could end up tilted in an awkward position quite easily. The control scheme was terrible!

So, now, I’ve set up the control as follows. To manipulate the rotation about the Y axis, you move the mouse along the X axis on the display. To manipulate the rotation about the X axis, you move the mouse along the Y axis on the display. If you wish to slide the graph along the X axis, hold down the shift key and move the mouse around. This is obviously much more clear if you play around with it yourself rather than talking about it…

In addition to improved controls, I’ve also added limits internally so that you can’t shoot yourself in the foot and end up looking at the backside or underside of the waterfall by accident, requiring you to select one of the preset cameras to get things back to normal again.

Wow, this turned out to be quite a mouthful in the end. :)

So, what are you waiting for? Get over to the latest builds page and download a copy to try out!

I just posted FuzzMeasure 3.1b4 on the latest builds page. Go ahead and download it now—I’ll wait.

The most notable change is that I (re-?)added the duration setting to the waterfall plugin, and added a new offset setting. These values allow you to effectively ‘zoom’ into a range of the impulse response, unlike the ‘old’ (old to the 3.1 beta testers, not to the folks using 3.0) method which required you to muck with the impulse window to tune your results.

For example, if you’re trying to characterize loudspeaker ringing at higher frequencies, you may only want to view the first 20ms of the waterfall. So, you leave the offset at 0, and set the duration to 20ms. Simple as that.

In previous betas, doing this would require you to set the impulse window to only 20ms, which would cause the waterfall results to lose data in lower frequencies. This is because ‘slices’ of the waterfall would have less and less data to process, and less of the spectral content would be valid. Now you can leave your impulse windows nice and long, and continue to enjoy higher-precision FFTs even for short-duration waterfalls.

I also took the time to perform some much-needed cleanup in the waterfall code, and eliminate a few performance problems in there. Please be sure to spend a lot of time testing the waterfall if you can.

I’m getting closer and closer to a release-worthy build, which is exciting. However, I’m not looking forward to is all the administrative work that’s going to follow. For example, updating the manual, organizing the website changes, setting up the press releases, etc. :)

I pushed through a lot of outstanding bugs and issues last week—many of which I was working really hard to avoid for a long time. Some issues really seemed larger than they turned out to be, so I was very happy with the speed at which I was able to get these annoying issues dealt with.

I am almost ready to lock down 3.1 for release preparation, though I want to try a few more experiments with the distortion feature before I ship. It’s a real sore point for a lot of customers (graphs aren’t the easiest to read, color choices can make the three lines difficult to distinguish, etc), so I would like to ensure I get the UI sorted out soon.

Check out the latest build page for release notes, and a link to download 3.1b3.