Since I updated to OS X El Capitan a few weeks ago, I’ve only had one significant software issue.

My advisor from the University of Michigan, Professor Jason Corey, wrote a book about Technical Ear Training a few years back. The book is great, and it also includes a fantastic software package he put together for training your ears.

I set aside some time each week at work to use this tool, and it’s really helped me keep my ears focused over the years. I fired it up the first week after updating to El Cap, and the icon just bounced around in my dock forever.

Jason built the tool in Max/MSP as a standalone application. I’m not sure what changed in El Capitan that impacted Max, but he was able to fix the issue just by rebuilding the tools (on Yosemite, I believe).

He posted version 1.02 as an update on his website. According to the license, the software is available for noncommercial education and research use, and I highly recommend it. Download it, and if you enjoy it, buy his book!

For better or worse, I started rewatching Lost. When I watched it live, one of my favorite aspects was the official weekly podcast ABC released. Unfortunately, that original feed isn’t available any longer. Lostpedia has done a great job archiving the content, but the information isn’t available in a proper RSS feed.

I’ve started building a feed, and I’ve put it up on Github. I’ve tested the raw feed with Overcast and the Apple Podcast app.

I’ve included all of the episodes from Season 2 so far, and I’ll add the rest eventually. I’d also happily accept pull requests, if anyone else is interested!

At some point after migrating this site to WordPress, the admin panel notified me of an available update. When I attempted to install the update, I was prompted for FTP credentials. I don’t have an FTP server configured, so I had to dig into the problem. A quick search turned up a lot of people with similar problems, though most report also having trouble installing and updating plugins. That’s working just fine for me.

One option I came across is to hard-code the FTP credentials in your wp-config.php file. That doesn’t seem like a great idea to me, and it would also involve setting up an FTP server.

It appears that the root of the issue is a file permissions (or ownership) problem. I need to learn more about the ownership model in Linux, and what it should look like for a WordPress install.

In the meantime, the simplest fix seems to be to add a single line to your wp-config.php file: define(‘FS_METHOD’,’direct’);

I wasn’t entirely sure what that did, which made me a little uneasy — so I removed that line again after I completed the update. There’s a pretty good explanation of how this works on Stack Overflow. It seems like the crux of the issue is that the test for the direct method is failing, but the direct method actual works just fine. By directly specifying that update method I’m just bypassing that test.

Since I haven’t resolved the underlying permissions issue, I’m sure I’ll be diving into this again at the next major version release. This document details the permissions scheme in WordPress; hopefully it will help me sort this out.

Update March 16, 2016: I looked into the permissions issue a little more, and found that the group assigned to all of the subfolders in /var/www/jeffvautin.com/ did not match the groups in /var/www/analogbias.com/, the other WordPress site I have installed on this server. I ended up making a call to chgrp to set all of the folder groups to www-data. This did the trick.

I just recently wrote about the modifications I made to the Clean My Archives plugin to remove the comment count from the archive list. As of last week, Clean My Archives has been updated from version 0.2.0 to version 1.0.0. With the change, I’ve had to update my modification as well.

From a clean installation of Clean My Archives, I changed line 167 of the plugin from:

sprintf( '</a> %s</li>', $comments ),

To:

sprintf( '</a> </li>'),

With that, I’ve once again removed the comment count from the page:

In the course of migrating this site over to WordPress, I remembered an old, abandoned music-focus blog I had been hosting on WordPress.com. I figured that I might as well consolidate all of those posts onto this site as well.

The first step was to export the old posts from WordPress; that’s straightforward. There’s a built-in export function administration page, hiding under Tools. I chose to export all of the site content.

Once I had that archive stored locally, the next step was to import the content onto this site. The Import function is also under the Tools menu, and it will prompt you to install the WordPress Importer plugin. I completed the installation and activated the plugin.

Almost immediately, I hit an error message:

Is its parent directory writable by the server?

Some searching led me to the conclusion that the /wp-content/uploads/ folder had to be made world-writable, though I don’t fully understand why:

1. First, I verified the current folder permissions:

   cd /var/www/jeffvautin.com/wp-content/
   ls -l
   

   The permissions were 755.

2. Then I changed the permissions to world-writable:

   sudo chmod 777 /var/www/jeffvautin.com/wp-content/uploads/
   

3. At this point I could import the old site.

4. I changed the permissions back to where they had been:

   sudo chmod 755 /var/www/jeffvautin.com/wp-content/uploads/
   

After importing the content, I wanted to add it to my local Markdown file archive — in case I needed to modify it or move it anywhere else. To do this, I used Dr. Drang’s WP-MD scripts that I had previously set up. On my local machine, I first moved into the directory with the scripts:

cd /Users/jeffvautin/Dropbox/Application\ Support/BBEdit/Packages/WP-MD.bbpackage/Contents/Resources

Then I used this command to get a list of the post IDs, as a text file in BBEdit:

./recent-posts 40 | BBEdit

And finally, I imported the posts individually into BBEdit:

./get-post <post_ID> | BBEdit

Now they’re both on this site and a part of my local archive, which is a big improvement over the old arrangement, where they only lived on WordPress.com. The content isn’t as bad as I feared it was; you can see these old posts here.

My first patent, number 8,913,777, was issued late last year. I know there’s a lot of controversy surrounding the utility of patents — and I agree with a lot of the criticism — but I was also proud of the external recognition of my work.

Providing speakers in a vehicle seat

A speaker system for use in a seat includes a speaker enclosure including a speaker having a sound-radiating element with a first side and a second side, and an at least partially enclosed volume of space larger than a volume of space occupied by the speaker and acoustically coupled to the second side of the sound-radiating element of the speaker, the enclosure sized to fit within a first vertically-oriented cavity in a seat back, open at the top of the seat back. A motor moves the first speaker enclosure between a first position in which the first speaker enclosure is fully contained within the first cavity and a second position in which the first speaker enclosure protrudes from the top of the seat back such that the first side of the sound-radiating element is coupled to free space at the top of the seat back.

Here’s a link to Google’s cached version, too.

One of the reasons I was previously hosting this site on Scriptogr.am was due to the native Markdown support. While WordPress.com offers native Markdown support, it’s not a feature of the WordPress.org project.

Once again, I followed Dr. Drang’s lead:

I figured I had to have the Markdown plugin installed before importing, so I went to Michel Fortin’s site and got both PHP-Markdown-Extra and PHP-SmartyPants. After unzipping the downloaded files, I copied them into the wp-content/plugins directory of my blog and activated them from the WordPress plugins administration page. Then I did the import, which seemed to go quickly and flawlessly; there were no error messages.

In the years since Dr. Drang’s original post, PHP-Markdown-Extra is no longer actively developed as a WordPress plugin. Version 1.2.8, from November 29, 2013, is the last ‘Classic’ release with WordPress plugin support. This is what I’m running for now, but I may try to figure out how to run the latest ‘Library’ version when I have some time.

To do the installation, I downloaded and unzipped the classic release. I used scp to copy the plugin over to the server, and then copied it from my home directory into /var/www/jeffvautin.com/wp-content/plugins. With that, the Markdown-formatted content I imported from Scriptogr.am is rendering properly.

One of the reasons I had been running this site on Scriptogr.am was due to the way plain text files were handled. I had a single folder in Dropbox that contained all of my posts as MultiMarkdown files, and Scriptogr.am monitored that folder for changes, which were immediately reflected on the site. In moving to WordPress, I wanted to find a way to maintain a canonical local folder of posts.

I started out looking for a WordPress plugin that could help me. The Post via Dropbox plugin looked interesting, but it had a few quirks that I knew I wouldn’t be able to live with:

1. I didn’t like the way revisions were handled. Since the plugin doesn’t provide a method for getting the post ID, this seems like a very inelegant solution. I would have to go off to the admin panel to track down the ID of the post before being able to revise the document:

   You need to specify the ID of the post, there’re two ways: 1) using [id] tag or 2) prepend to filename the ID (example: 500-filename.txt). The quickest way to edit an existing post, already posted via Dropbox, is to move the file from the subfolder ‘posted’ to the principal folder.

2. I didn’t like that the format for the post metadata isn’t MultiMarkdown compatible. Instead of the key and value structure of MultiMarkdown metadata, Post via Dropbox uses a HTML-style tags:

   Why WordPress is able to read informations in proper manner, you must use some tags like [title] [/title] and [content] [/content].

I didn’t find any other plugins that looked like they were going to operate the way that I wanted, so I started to look into how I might be able to leverage the metaWeblog XML-RPC API. That’s when I remembered that Dr. Drang had written a bunch of posts about his scripts for blogging from BBEdit.

Dr. Drang’s WP-MD BBEdit package contains a lot of tools, but there were three scripts in particular that made me feel like I’d be able to get along with WordPress:

1. Publish Post.py takes a MultiMarkdown file with incomplete metadata, publishes it to WordPress, and fills in metadata in the file (including the post ID). Repeated calls leverage the existence of the post ID to update the proper post.
2. recent-posts returns the titles and post IDs of, you guessed it, recent posts. So, if I end up posting something from the admin panel of the site, this script provides an easy way to grab the post ID when I get back to my computer.
3. get-post returns the metadata and content associated with a post ID. This, paired with recent-posts, allows for the generation of a canonical local file for posts that originate somewhere else.

Armed with these tools, I felt like I would be able to properly maintain a complete, canonical, local copy of all of my posts as MultiMarkdown files. The next challenge was to get them up and running.

Dr. Drang provides great documentation for these tools in a pair of posts. This post details Publish Post.py, and this post goes into the other tools. Additionally, the Github Repo contains thorough notes on which scripts require modifications. His writing assumes some knowledge of Python, but since I’ve never really worked with Python before, I figured I’d try the detailed steps I used to get started¹.

1. I installed Python (and pip) via Homebrew (I used the GUI tool Cake Brew). I don’t think pip is part of the standard OS X Python installation, which is why I opted to follow the Python Guide installation steps.

2. With pip installed, I was able to use it to install the keyring and pytz libraries required for the scripts:

   pip install keyring
   pip install pytz
   

3. I ran the interactive session detailed here, to create a Keychain entry for the credentials for this site:

   import keyring
   keyring.set_password('http://jeffvautin.com/xmlrpc.php', 'myname', 'mypassword')
   

4. I installed the WP-MD package. Dr. Drang details this process here. I put the package in Dropbox, so that it would stay in sync between my laptop and iMac.

5. I customized the scripts for my site:

   • All three scripts needed to be pointed at the Homebrew Python installation, by changing the first line from #!/usr/bin/python to #!/usr/local/bin/python.
   • All three scripts needed the url and user variables to be customized. I set url to http://jeffvautin.com/xmlrpc.php, and user to myname.
   • get-post and Publish Post.py both require specifying a timezone. This Stack Overflow post provides a complete list of available timezone specifications.

With this setup, I was able to make a few minor (manual) modifications to my Scriptogr.am files and publish them to WordPress.

I’ve been working through my Instapaper queue, and I just read this tremendous analysis of the production of ‘When The Levee Breaks’ — I’m only three years out of date!

The author used a free tool I had never heard of for the spectral and temporal analysis of the song: Sonic Visualiser. It looks like it could be very useful, but the download links are broken (as of August 10, 2015).

The paper is full of great details about the recording of the song —- things I never realized:

According to Andy Fyfe, the drum sound on WtLB was the result of Jimmy Page’s ‘master plan for the track, which he set out to make sound as ominous as possible’ (2003, 85). The antagonistic quality perceived by listeners appears to have been an intended aspect of their identity. In addition, the instrumental tracks were originally recorded at a slightly faster speed, then slowed down, lending the song a sluggish, eerie quality (Eddy: 1997, 74).

This song really is a masterpiece, and this analysis is well worth a read.

Since I can never remember how to do this without looking it up, I thought I’d make a note here. When I need to shutdown the VPS this site runs on to make a snapshot, the command is:

sudo poweroff