I was lucky enough to pick up a Behringer Ultracurve Pro DSP8024 for a mere £50 on eBay recently. It turned out to have a buggy OS version (1.2), and Behringer very kindly sent me a replacement EPROM with a new 1.3 OS on it, which works just fine. I now have it installed between my Soundcraft mixer and my Wharfedale active monitors. I used its “Auto-Q” calibration routine and put up with some quite loud pink noise to calculate a room correction curve. Because it knows the spectrum it’s generating, it assumes that what it gets back has been altered by the combination of speakers, room and microphone, so it can calculate an eq map to compensate for it. It’s quite fun to watch as it has a nice big LCD screen to display the 31 1/3 octave bands – the initial spectrum is fairly peaky, but as it iteratively applies corrections you see (and hear) it flattening out. It’s also very obvious that my monitors don’t put out much below 50Hz (it analyses down to 20Hz), but that’s to be expected from a moderately sized box with a 6.5″ driver. The results are really pretty good, sounds lovely and smooth, but the real surprise is when you’ve been listening to it for a while and you switch out the EQ – it’s really quite a shock to hear the uncorrected version. Lots of purists don’t like room correction by EQ, saying it’s better to fix the room in the first place, and also that EQ calculated like this is highly dependent on the listening position (which it is). I have a lots of bookshelves facing my speakers; they make fantastic diffusers, and I have some Universal Acoustics absorber tiles on the sloping ceiling above my listening position. The longest room mode will be fairly undamped (I’m not about to start hanging duvets around the walls!), but the resulting EQ is below 6db in either direction across the whole range – I’ve heard of rooms with 24db peaks! Anyway, after all that, it sounds lovely, and I’m happy!
The web developer’s holy vhost trinity
When you’re developing web stuff, working with projects in path names (i.e. not at the top level of a domain) can be difficult (gets in the way of absolute links, rewrite rules etc), so you often need to set up a local apache virtual host, stick an entry in DNS and create an SSL certificate before you can get on with the serious business of doing some real work. This can get to be a drag when you do it a lot, but there is an extremely elegant solution that means you’ll never have to do it again…
Continue reading “The web developer’s holy vhost trinity”
Changing MacBook Bezel
I recently had cause to change the bezel on my rev A 13″ MacBook. If you follow the guide on MacFixit, it is a long and complicated procedure, involving dismantling nearly everything. Luckily, most of it is unnecessary – it’s really quite easy to simply remove the bezel without dismantling anything; just jump straight to step 35 and carry on from there.
Web Hooks, Callbacks and Distributed Observers
Someone at AMEE pointed out to me that there’s been a flurry of activity around so-called “Web Hooks” when I referred to the concept. This is quite heartening as I thought of this a couple of years ago and implemented this in Smartmessages early last year! I call them callbacks, but the idea is the same – it’s essentially a distributed observer pattern. I couldn’t figure out why nobody seemed to understand what I was on about… When I get some interesting event (e.g. a message open, mailshot completion, clickthrough etc), I ping a user-supplied URL with the appropriate event data, pretty much the one-liner that Jeff alludes to. The reason we do it is that sync with external systems (usually CRM) is something that were always running into, and there seems to be no sensible, generic way of dealing with it other than this, so I’m surprised it has not been discussed in this context before.
There’s one downside as far as I can see – it is highly dependent on the receiver to be able to handle the event in a timely fashion. This isn’t an issue if you’re connecting say, Yahoo! to Google, but it could be a big problem if you connect Google to your WordPress blog… My experience of CRM systems is that they are simply too slow to cope with the high rates of traffic that we are likely to generate, for example, if we point a stream of ~200 events per second at a CRM system, it will probably just bog down and fail (I’m thinking of the SalesForce API here which typically takes 1-2 sec to deal with a single SOAP API call). Retrying will only make this worse. I have two solutions for this: limit events to those that don’t happen so often (kind of lame!), or alternatively, use an outbound message queue to rate-limit the sending (Amazon SQS and Memcacheq spring to mind). Queueing works, but you lose some of the real-time aspect. Ideally clients would implement their own incoming queue in order to allow them to process events at their leisure, but this is mostly beyond the vast majority of web authors (or at least those that host the CRM systems that we hear from!).
Anyway, it’s nice to know that I’m not completely barking…