To the outside world, it might seem like I’ve not done a thing with the product in years! Fortunately for my users, that is certainly not the case.

I have been working on a major update to FuzzMeasure for quite some time now. The work has been slow, but I assure you that significant progress has been made. I certainly bit off more than I could chew with this one, so it’s going to be a little while still.

Unfortunately for my users, that just means more waiting. Few people like to wait, no matter how much greater the reward will be.

During all this development, I have identified and corrected some issues in the code that I’m unhappy with. Many of those bug fixes required large engineering efforts that cannot be integrated into the FuzzMeasure 3.2 code base. Fortunately for my users, that’s not true for all the fixes!

So today’s release includes a little fix that actually makes a big difference to FuzzMeasure’s operation. When checking for an adequate recording level, FuzzMeasure will now analyze the recorded audio, and not the calculated impulse response.

When I first implemented this check, it made perfect sense because it was working to ensure adequate SNR in the impulse response. In reality, it was too often filtering out impulses that had legitimate reasons for being “too quiet”. For instance, a subwoofer with adequate recording level would result in an impulse response with a very small magnitude.

In addition to the above fix, I managed to get the FuzzMeasure application bundle signed using my Developer ID, which makes downloading the application on newer Macs go much more smoothly.

I hope to have more to share soon regarding FuzzMeasure. Stay tuned, and go download FuzzMeasure 3.2.5 now!.

Capo 2.1.10 addresses a few major issues that were found in the 2.1.9 update, as well as some longer-standing ones. For instance, the default keyboard shortcuts failed to operate properly and displayed the additional fn modifier key in the Control menu.

It turns out that either Lion or Mountain Lion started to render the fn key as a modifier key, and I had inadvertantly stored a set of modifier flags with the default keystrokes that had that flag set. Oops.

Also, I wasn’t hooking the user-defined key equivalents to the menu items until the menu was shown (in the validateMenuItem: call), because I was catching those keystrokes using other means. However, that other method isn’t foolproof and I needed to forcefully (rather than lazily) set those menu key equivalents at launch time.

For existing users to benefit from this fix, run the following command at the terminal:

defaults delete com.supermegaultragroovy.capo CapoPlaybackCommands

If you purchased using the Mac App Store, use this one instead:

defaults delete com.supermegaultragroovy.capo.macappstore CapoPlaybackCommands

I also found an OpenGL-related race condition that stumped me for some time. It turns out that a Core Animation-backed NSOpenGLView cannot make any assumptions about owning its context. I was creating textures (i.e. calling glGenTexture()) at the same time that CoreAnimation was disposing them on another thread (i.e. calling glDeleteTexture()). Locking the CGLContextObj fixed that issue up good.

TapeDeck 1.5.2 was a much quicker update to put together. When I rewrote the tape box view to use a view-based NSTableView, I didn’t carry over the ability to drag .m4a (MPEG-4 audio) files into the list. It was partially a copy/paste job from my old tape box view class, but I ended up rewriting much of that code using new (and much nicer!) APIs for drag and drop.

Other than the above, I’ve been crunching on a whole lot of new development lately. I’ve split my time between reading papers, writing up tests using MATLAB, and coding up prototypes for the past few months. It’s been busy, but I hope to have something to share soon.

But I digress!

Capo 2.1.9 is a major bugfix release that primarily addresses the slow scrolling in Capo. This performance issue was on my mind since 2.0, and I’ve had a desire to rewrite “everything” in the spectrogram for a long time now. Capo 2.1.8 forced my hand to jump on that project early, because it was pushing 2x as many pixels through the pipe on Retina display Macs.

The bottleneck was in the rendering of the spectrogram. I do a fair bit of compositing there, and Quartz / CoreAnimation just weren’t able to push pixels quickly enough. OpenGL is great at the sort of things I wanted to do, so that seemed to be the obvious solution to my problem.

Capo generates its spectrogram as a black-and-white “intensity map” which I would use as a mask to draw its colour atop the background grid (which is also composited.) I also use a multiplier on the intensity map to adjust the display intensity so that users can bring out the details in their songs.

Any of you with OpenGL chops can see that this stuff is perfect for shaders. The multiplications can be done with a uniform intensity value that is used as a multiplier on the spectrogram intensity map. Hell, I could even work in the HSL colour space if I wanted to (and I do, though that will be more likely to show up in FuzzMeasure first.)

To accomplish all this, I had to perform a major reorganization of the code that draws everything between the metadata/HUD (left side of the window) and the effects (right side of the window.) The “meat and potatoes” of the UI, if you will.

I also decided to adopt the system-supplied scroll view (and its fantastic disappearing scrollers) to power all this nonsense. I actually have seven NSScrollViews (that overlap!) synchronized with one another to pull this off!

Oh, and while I was in there, I enabled ARC and got tighter memory footprint in the process. Why not, right?!

Coming out at the other end of this, I’m really happy with the improved code base. I feel a huge weight lifted off my shoulders, and I feel much better about moving forward with the features that users have been clamouring for.

If you haven’t already, go get the Capo 2.1.9 update, and see the improvements for yourself. And, as always, stay tuned for more…

In this release, I added a much-requested feature. That is, you can now import MP3, WAV, AIFF, and MPEG-4 audio files from other applications such as Mail and Dropbox.

I also did a ton of work under the hood to help improve stability, performance, and maintainability. One of the major efforts there was in enabling ARC on the project. This doesn’t really matter much to the end user (outside of some small performance gains and a few less crashes,) but it was an important milestone for me.

Now that Capo 1.3 is all cleaned up on the inside, I hope to make some more interesting changes very soon.

So instead of continuing to put this off, I need to attack this problem head-on. I want to find someone that I can work with on the fun and exciting things that I am building. Hopefully you are the one I am looking for.

In a perfect world, I would like to find a skilled iOS and Mac developer that is an expert in the following fields:

• Graphic, and/or User Interaction Design
• Music Theory
• Digital Signal Processing
• Acoustics, and the Physics of Sound
• Music Information Retrieval

Pretty crazy, right? I mean, nobody can be an expert in all that stuff. However, I hope you read the list above and got somewhat excited because you are great at some of it, and wish to learn more about the rest.

So, send me an email and let’s talk about how you can help me to continue making some of the best software on the Mac, iPhones, and iPads. Please include any relevant information about your background, and some examples of code you’ve shipped.

Note that this is a full-time contract-to-hire position. Telecommuting is a necessity.