Stackoverflow.com is great but … always RTFM

Back in the good (?!?) old days of C++ and WinAPI … I was reviewing this bit of code. There was a Windows API call to some registry manipulation function. The next line was an identical call to the exact same function with the exact same parameters and a comment /*this must be here*/. Whaaat?

A quick peek to the MSDN documentation and it was immediately obvious: “oh, he’s disregarding the out-parameter and the return value”. The developer had not read the documentation and therefore did not understand how the API worked.

This was the day I realized not all developers read the documentation of the libraries and tools they use. Sometimes people just fiddle with it until it works… or at least seems to work. Since then I’ve encountered lots of examples of hack-it-until-it-obeys gone wrong. Sometimes you see very strange and unnecessarily complex log4j or log4net configuration files due to the writer not understanding the logger hierarchy and how appenders relate to it.

When I use a tool that is new to me, I like to try to get my mental model aligned with the tool developers. Usually you can get the big picture by reading just the introductory chapters of the manual.

Libraries can also hide nasty surprises buried deep in the documentation. Like this bit from the jQuery css()-method:

“When a number is passed as the value, jQuery will convert it to a string and add px to the end of that string.”

Except, it is not really buried very deep. It is the third paragraph in the method description. I do not tend to read API documentation front to back like a book but anytime I use a method I have not used before, I like to see what the API developers had to say about it.

Browsing the documentation can also give you positive surprises. Fast forward to the land of C# in 2015. I was reviewing some ASP.NET MVC code together with the team member who wrote it. It looked alright to me. The code was using System.Web.Mvc.OutputCacheAttribute.

[HttpGet]
[OutputCache(Duration = 8*3600)] /* 8 hours */
public ActionResult GetCoolStuff() { … }

I said: “Looks OK to me… … … BTW, have you used this cache thing before? Have you read the API docs?”
“err… no.”
“Well, let’s go see if we find anything useful.”

No need to wade through all the methods & properties, ‘remarks’ is where the important stuff is. In this case we found this sentence: “To avoid code duplication, you can set a cache profile in the Web.config file instead of setting cache values individually in pages.” Hey, if we use that we can change the cache invalidation time on the fly.

[HttpGet]
[OutputCache(CacheProfile = "CoolStuffOutputCache")]
public ActionResult GetCoolStuff() { … }

It took us all of 2 minutes to browse to MSDN and read the remarks section of the OutputCache class. We gained the ability to change the cache settings on the fly. The original version would have needed a recompile if we wanted to change the cache invalidation time.

Known your tools. Stackoverflow is awesome but to really know your way around you must Read The Fine Manual.

rdnzl UltraRes Bass cabs – part II

bass-cabs-1

Here is a bunch of bass cabinet impulse responses (IR) I created. An impulse response is a measurement that can capture the response of an audio device. You run a stimulus signal through the device, record the output and give the stimulus plus the recording to a program that calculates the impulse response. The impulse response can then be loaded to a DSP processor (an audio plugin or a hardware device) and it will emulate the behavior of the original device. An impulse response does not capture everything, it is limited to the linear time-invariant behavior. In practice this works very well for emulating speaker cabinets.

This package contains WAV files for use in any IR software plus *.ir and *.syx files for use with the Axe FX II hardware processor.

Download here:  rdnzl Bass cabs April 2014.zip

This cab pack extends the previous pack from February with the Mesa 2×10 cab and has more mic positions. Every cab & mic that was in the previous pack should be included here. There may be slight differences because the IR:s were shot with different AD-converters and software.

AD/DA

  • Antelope Orion

Mic preamps

  • Avedis MA5
  • Grace Design M501

IR capture

  • Voxengo Deconvolver

Poweramp

  • Matrix GT1000FX 1U

Mics

  • C414 = AKG C414ULS, cardioid pattern
  • M88 = Beyerdynamic M88TG
  • D112 = AKG D112
  • MM1 = Beyerdynamic MM1 flat measurement mic

Cab naming

  • “EBS 4×10” = EBS ProLine 410
  • “MB 2×10″ = Mesa/Boogie 2×10” RoadReady EV
  • “MB 2×15″ = Mesa/Boogie 2×15” RoadReady EV
  • “+tweeter” = tweeter on
  • “tweeter” = tweeter only

Mic distance

  • <not specified> = as close as the D112 will go without touching the grill of the Mesa cab. This gives a speaker cone->mic capsule distance of about 8cm.
  • “+1ft” = roughly one foot

File folders

  • ir/ raw *.ir files for cab mixing in Fractal Audio CabLab >=2.0
  • ultrares/ *.syx files for Axe Fx II
  • ultrares XL/ *.syx files for Axe Fx II XL
  • wav/ full length WAV files for DAW use etc.

 

 

UltraRes Bass cabs for Axe FX II

Image

Here is a bunch of bass cabinet impulse responses (IR) that I created. An impulse response is a measurement that can capture the response of an audio device. You run a stimulus signal through the device, record the output and give the stimulus plus the recording to a program that calculates the impulse response. The impulse response can then be loaded to a DSP processor (an audio plugin or a hardware device) and it will emulate the behavior of the original device. An impulse response does not capture everything, it is limited to the linear time-invariant behavior. In practice this works very well for emulating speaker cabinets.

These IRs are for use in the Axe FX II hardware processor. There is an updated pack that also contains WAV files for use in any software that handles IRs.

Download zip file here: rdnzl-bass-cabs-20140209.zip

IR capture / AD / DA: Axe FX II
Poweramp: Matrix GT1000FX 1U
Mics:

  • C414 = AKG C414ULS, cardioid pattern
  • M88 = Beyerdynamic M88TG
  • D112 = AKG D112
  • MM1 = Beyerdynamic MM1 measurement mic

Batch 1: Mics at center of the cone
Mic distance: as close as the D112 will go without touching the grill of the Mesa cab. This gives a speaker cone->mic capsule distance of about 8cm.
All mics phase-aligned by ear using noise.

Mesa/Boogie 2×15″ RoadReady EV
C414 MA5 #22 rdnzl MB2x15 C414
M88 MA5 #23 rdnzl MB2x15 M88
D112 Grace #28 rdnzl MB2x15 D112
MM1 Grace #29 rdnzl MB2x15 MM1

EBS ProLine 410
D112 Grace #24 rdnzl EBS4x10 D112
MM1 Grace #25 rdnzl EBS4x10 MM1
C414 MA5 #26 rdnzl EBS4x10 C414
M88 MA5 #27 rdnzl EBS4x10 M88

Edit: Zip file updated 9 Feb 2014: “rdnzl EBS4x10 C414 fixed” replaces the earlier version “rdnzl EBS4x10 C414”. On the original IR the mic highpass filter was accidentally left in the 150Hz position. Oops. Not good for bass 🙂