Making Prosoft Hear work again with iTunes 12.6

The only reason why I stick with iTunes is that I have been suckered into it from the start when it still was a pretty good application for managing an offline collection of music files. Lately, the app has shifted towards cloud-based stuff and artificial stupidity algorithms that try to suck all the joy out of being your own virtual DJ. It is still usable for its original intent however so I haven't tried to move to an alternative… yet.

Lately, Apple has done two more stabs at endlessly annoying me and making me regret that even my alarm clock is tightly coupled to iTunes by means of Koingo's Alarm Clock Pro. The first thing they did was break the visualizer plug-ins, in the typical Apple fashion that has since many years made me shy away from developing anything specific for OS X. This fashion is of course doing it in total silence, without warning anyone or even mentioning it in the release notes. Starting with iTunes 12.6 the visualizer menu simply only shows the two built-in visualisers, ignoring any installed plugins. I am pretty glad I never took the effort to polish up my now obsolete Spectrograph plug-in. Maybe I unconsciously saw it coming.

The second thing they did, and what this post really is about, is that they also broke the Hear audio enhancer from Prosoft. I heavily rely on Hear to make listening with headphones more enjoyable. When properly set up, Hear can make even the cheapest headphones sound like expensive Sennheisers. Or in my case, make mid-priced Sennheisers sound like an explosion of aural bliss. It can also squeeze extra fidelity out of simple Bluetooth speakers or other sound systems. Great was my frustration when I noticed the controls had no effect anymore after iTunes had sneakily upgraded itself to 12.6.1, and it was even greater when I saw on the Hear product page that Prosoft officially does not support iTunes anymore. That's right, they admit that their product primarily geared towards enhancing your music experience, does not work with the de facto standard for music playback in Mac OS. I commend them for that, but it doesn't make the fact less annoying.

My guess is that iTunes has become yet another application in the row of ‘sandboxed’ apps like Safari, which are nailed shut to avoid exploits from malware and the like. After all, iTunes is linked to a store and the store is linked to credit card details. Why this also has to break the ability to manipulate the audio stream, beats me. I contacted Prosoft and they are looking if the problem can be fixed, but I'm not sure if they'll be able to circumvent the sandbox restriction.

However, I noticed that applications like Nicecast still work fine with iTunes. This made me pretty confident that I can still make the audio go through Hear after all, albeit by means of a pretty clumsy roundabout. And indeed, after the necessary cursing and kludging I made it work as follows.

Making it work

The strategy is quite simple: re-route iTunes' audio output through another non-sandboxed program that plays the stream on standard output. We can do this by means of two different free, open source projects: SoundFlower and Audacity.

1. First install SoundFlower, the current 2.0b2 release from mattingalls' GitHub seems to work fine, at least in El Capitan. Don't bother with trying to get the Soundflowerbed application to work, you don't need it.
2. In your Sound system preferences, set the ‘Soundflower (2ch)’ device as output device.
3. Open Audacity and select the ‘Soundflower (2ch)’ device as the microphone device. Select the ‘Built-in Output’ as your output device.
   
4. In Audacity's preferences, Recording, enable ‘Software Playthrough’.
   
5. Drag both the input and output volume sliders in the top-right corner of Audacity's main window to maximum. Now press ‘Click to Start Monitoring’ and start playing some music. You should see Audacity's VU meter start to move, and hear the sound as usual. You may need to give the Hear control panel a kick by toggling the on/off button or nudging a slider to make it hook itself to the audio output, but it should work.
   

Of course this has some disadvantages, like needing to keep Audacity open, and a noticeable extra delay on the audio as well. You will have no sound at all if you break any component in the whole chain. This can be pretty annoying if like me, you use your Mac as an alarm clock (it will be trying to wake you with silence which results in you being late for work). Moreover, when you switch back to direct playback through internal speakers, two things require attention. First, your volume will be at 100%, which can lead to unpleasant surprises if you forget to turn it down. Next, when you have switched back to internal speakers in the Sound control panel and plug or unplug something from the headphone jack, OS X will once more switch back to Soundflower output, and you must again select internal speakers.
In other words, not only do you need a whole ritual to set up this workaround, you also need to do a little dance to tear it down. For all these reasons I hope Prosoft manages to find a solution. I wouldn't mind if it would simply implement this workaround under the hood and have some extra delay, if only it is reliable.

This hack does have some extra advantages however, for instance Hear will also work with Safari or any other sandboxed application's audio. And, if at any time you would want to record what's playing, all you have to do is hit the record button in Audacity.

Dark Sky / Forecast.io: avoid using the temperature, humidity, or pressure values of the first hourly block

Here is yet another post about something highly specific that is totally unrelated to everything else on this blog. Enjoy!

If you rely on Forecast.io to obtain weather prediction data, you may also have implemented fancy things like a graph of how the temperature will evolve over the next few hours. Or maybe just a rising/falling trend indicator. This seems very easy to do: just take the “hourly” data block and take the “temperature” values of each entry, and either plot them or compare them. This will work, but you may notice that as the time gets nearer to the next hour change (eg. 09:57), the first point in your graph starts wobbling around wildly every time you refresh the data. Why is this?

A plot made at 16:55, current reported temperature was 0.1°C.

The first hourly data block represents the current ongoing hour. For instance if you retrieve predictions at 09:57, the first block will represent 09:00. One would expect that the folks at Dark Sky would rely on their historical data to fill in the values for that block, given that it represents a moment in the past. For some reason however they merely take the current observations, in this example from 09:57, and extrapolate them into the past using the data for the next predicted hourly block. For instance if it is currently 15.12 degrees and the temperature for 10:00 is predicted to be 15.79 degrees, then the value for 09:00 will be calculated as (15.12-15.79*57/60)/(1-57/60) = 2.39 degrees.

Extrapolation works fine for data that is known to be relatively stable if the extrapolated point is near the interval of known data. In this case only one point is an actual observation though, the other one is a prediction: also an extrapolation in its own right. This makes it doubly dangerous to extrapolate another value out of it, especially if it lies so far away from the two given points.

The morale of the story is: do not rely on the temperature, humidity, or pressure values from the very first hourly data point, unless the hour has only just started. If you want to make a temperature graph, it makes more sense anyway to start the plot at the current time and not at the start of the current hour. Even if at some point the people at Forecast.io update their system to really put historical data in that block, if you would merely dump the values from all blocks in a graph, visitors would still be seeing a curve that starts almost an hour ago when they load your page 09:57, which is not very intuitive.

The same plot as above, but now starting at the actual observation.

After figuring this out, I now start my plot with the current observation and I calculate the trends by comparing the current observation to a linear interpolation at the current time plus one hour. Interpolating also is not ideal but a lot more defendable here than a wild extrapolation.