Mac - when your disk is really, really full

My wife's 2012 (OSX Catalina, 10.15) MacBook Air has been struggling recently with a hard disk that seems to have no hesitation in filling itself to the absolute brim (like `78kb space remaining`). The problem is that APFS, being a journaling file system, wants to write a record of your attempt to call `rm ~/Downloads/stupid-big-file.mp4`, but doesn't have the space to do so - preventing the `rm` from running, and so escaping this situation is far harder than it should be. This has happened a number of times now, and after various attempts to use ["Target Disk Mode"](https://support.apple.com/en-au/guide/mac-help/mchlp1443/mac) via a daisy-chain of Thunderbolt-to-FireWire adapters, Apple Disk Utility in Recovery Mode, and a [GParted LiveCD](https://gparted.org/livecd.php) to mount the drive, this typically-unassuming but excellent [Stack Exchange answer](https://apple.stackexchange.com/a/371323/117415) has ended up being my saviour. It always takes me ages to re-stumble upon it because my Googling is typically for phrases like "resize APFS partition" which leads you to [articles like this one](https://www.macobserver.com/tips/resize-your-apfs-container/) which is totally overkill for the situation. The **TL;DR** is - you can safely use the `diskutil` utility to `remove` the volume that is named `VM`, and APFS will then automatically resize the overfull "Macintosh HD" volume to get that space back. Just be aware that the Mac will always prefer to have *some* VM, so the long-term solution is probably to keep several tens of Gb free so that the two volumes can coexist in harmony. While I'm linking to useful Apple-disaster-recovery-related Stack answers, while you're in Recovery Mode and trying to figure out what files to nuke, Apple helpfully removes the link to `du`. [This answer gives the full path](https://superuser.com/a/1279144/386135) (which on the aforementioned 2012 Mac is actually `/Volumes/Macintosh\ HD/usr/bin/du` as per one of the comments).

My Apps, 2024

Following a bit of a blogger-trend, here's the stuff I use on the daily. I've omitted things I simply don't use, like custom launchers, podcast listeners, RSS, tracking and/or Mastodon clients; - Mail service: __GMail__ - Tasks: __Drafts in GMail__ - Cloud storage: __Dropbox__ - Web browser: __Chrome__ - Calendar: __Google Calendar__ - Weather: __BOM__ (Melbourne, Australia) app - Video: __Netflix, Disney Plus, Amazon Prime Video__ - Music (Listening): __Spotify__, Spotify via Google Home and/or Chromecast - Music (Creation): __GarageBand__ - Passwords: __1Password__ - Notes: __Drafts in GMail__ - Code: __Visual Studio Code__ - Terminal: __Terminal.app__ - Search: __Google__ This list has shown me how much I depend on Google a) not being evil; and b) not just giving up on a product because they're bored of it ... which concerns me a little. While it still exists though 😉, I *do* highly recommend the use of __Drafts in GMail__ as your general-purpose, cross-platform notes/todo app. You can attach files of arbitrary size, they sync to everything/everywhere *fast* (faster than Dropbox) and it's free (free-r than Dropbox... hmmm 🤔)

Sneaking through the Analog Hole

I perhaps-foolishly recently agreed to perform a media-archiving task. A series of books-on-tape (yes, on physical audio cassettes), almost unplayable at this point in the century, needed to be moved onto a playable media. For this particular client, that meant onto Audio CDs (OK so we're moving forward, but not _too_ far!). I myself didn't have a suitable playback device, but quickly located a bargain-priced solution, second-hand on eBay (of course) - an **AWA _E-F34U_** that appears to be exclusively distributed by the [Big W](https://www.bigw.com.au) retail chain here in Australia:

This device purports to be a one-USB-cable solution to digitising the contents of analogue cassettes. Unfortunately, the example I just purchased had extremely severe issues with its USB implementation. The audio coming straight off the USB cable would jump between perfectly fine for a few seconds, to glitchy, stuttering and repeating short sections, to half-speed slooooow with the attendant drop in pitch. Unusable. I only hope that the problem is isolated to my unit (which was _cheap_ and described as "sold untested" so I have no-one to blame but myself) - if not, someone's done a really bad job at their USB Audio implementation. Luckily, the USB Power works absolutely fine, so I had to resort to the old "Analog Hole" solution via my existing (rather nice) USB Audio Interface, a **Native Instruments _Komplete Audio 1_** which I picked up after my previous interface, a [**TASCAM _FireOne_**, finally kicked the bucket](https://blog.themillhousegroup.com/2020/07/tascam-fireone-on-macos-high-sierra.html).

In the following picture, you can see my digitising solution. AWA tape transport (powered by USB) to 3.5mm headphone socket, through a 1/4" adaptor to a short guitar lead and into the _Komplete Audio 1_'s Line In. From there, it goes in via the _KA1_'s (fully-working!) USB connection to GarageBand on the Mac. A noise gate and a little compression are applied, and once each side of each tape has been captured, it gets exported directly to an MP3 file. I intend to present the client with not only the Audio CDs but also a data CD containing these MP3s so that future media formats can hopefully be more easily accommodated.

What if I _didn't_ already have a USB audio interface? Would the client have given up, with their media stuck in the analog era, never to be heard again? It amused me that analog technology was both the **cause of** this work - in that this medium and the ability to play it has gone from ubiquitous in the 1980s to virtually extinct - **and its solution**, using an analog interface to get around a deficient digital one.

Importing/capturing digital video (DV) for FREE on a Mac in 2021

Like many others, I have a giant box of Mini DV video cassettes from 10+ years ago that I fairly-urgently need to get onto a more long-term-safe medium. As it's a pretty tedious job I have tended to do this in batches, when I can be bothered getting all the necessary bits together. Fortunately my trusty 2012 MacBook Pro has Thunderbolt ports that with just a couple of cheap adapters, can connect to the 4-pin Firewire port of my still-functional Panasonic NV-GS27 camcorder and do the job.

But while the hardware is willing, sometimes the software is not. It's all too easy to get on the upgrade treadmill and forget about applications you only use once every couple of years. In the past I used Vidi, which was minimal but $0, and thus excellent. But it won't work on 64-bit MacOS and appears unmaintained so I needed something new.

All I needed was something that could capture the raw data from each cassette and dump it into a .dv file that I can stash away on a hard drive.After a very dismaying tour through Google and YouTube made me think I'd either need to pay for a software package, or kludge something together using libdc1394 (which would be massive overkill) I finally found what I needed by searching Github directly: vrecord by AMIA Open Source.

vrecord works beautifully on my Catalina (OSX 10.15) MacBook Pro - follow the Basic Usage guide and you'll be capturing those precious memories in no time.

Switching to git switch

A recent OS upgrade resulted in my Git version being bumped up to 3.x, an interesting feature of which is the new git switch command, which replaces part of the heavily overloaded git checkout functionality with something much clearer.

Now, to switch to branch foo you can just invoke git switch foo

And to create a new branch, instead of git checkout -b newbranch,
it's git switch -c newbranch

These are small changes, to be sure, but worthwhile in bringing more focus to individual commands, and relieving some of the incredibly heavy lifting being done by the flags passed to git checkout, which hopefully now can be my "tool of last resort" as it usually leaves me stranded in "detached head hell" ... my fault, not Git's!

I've also updated my gcm alias/script to use git switch, so accordingly it's now gsm.

TASCAM FireOne on MacOS High Sierra: finally dead

I suppose it had to happen, but today, my TASCAM FireOne Firewire audio interface just ceased to work properly - namely, the audio input has a constant clicking sound making it unusable.

I suppose I should feel fortunate that it has lasted this long; I mean, look at the MacOS compatibility chart:

- yep 10.4 and 10.5 only, yet here I am on High Sierra (10.13) and it's only just turned up its toes.

It's even less whelming on the Windows side:

... XP only (!)

So now I'm on the hunt for a good interface that will last as long as this one did. Firewire seems to have been effectively killed by Apple, and Thunderbolt interfaces are incredibly expensive, so it'll be back to good ol' USB I guess. I'm thinking that with the rise of podcasts etc, Apple will be obligated to ensure USB audio interfaces that use no additional drivers (aka "Class-Compliant devices") work really well for the foreseeable future...

Home-Grown Mesh Networking Part 2 - When It Doesn't Work ...

A few months ago I shared some tips on using existing Wifi gear to make your own mesh network.

Turns out though, it might not be as easy as I initially made out. In particular, I was noticing the expected switchover as I walked down the corridor in the middle of my house:

... was simply not happening. I would be "stuck" on Channel 3 (red) or Channel 9 (green) based on whatever my Mac had woken up with.

Lots of Googling later, and the simplest diagnostic tool on the Mac turns out to be Wireless Diagnostics -> Info - take a snapshot, turn off that AP, and wait for the UI to update. Then stick them side by side and eyeball them:

I wasted quite some time following a wild goose because of the differing Country Codes - it's not really something you can change in most consumer AP/routers so I thought I was in trouble, until I discovered that "X1" really just means "not broadcast" so I decided to ignore it, which turns out to be fine.

Now the other thing that was most definitely not fine was the different Security policies. I thought I had these set up to match perfectly, but as you can see, MacOS thought different (pun not intended).

When is WPA2 Not WPA2?

The D-Link AP (on Channel 9, on the right in the above screenshot) was supposedly in "WPA2 Personal" mode but the Mac was diagnosing it as just WPA v1. This is most definitely enough of a difference for it to NOT seamlessly switch channels. Even more confusingly, some parts of the MacOS network stack will report this as WPA2. It's quite tricky to sort out, especially when you have access points of different vintages, from different manufacturers, who use different terminology, but what worked for me (on the problematic D-Link) was using Security Mode WPA-Personal together with WPA Mode WPA2 plus explicitly setting the Cipher Type to AES and not the default TKIP and AES:

This last change did the trick for me, and I was able to get some automatic channel-switching, but the Mac was still holding on to the Channel 3 network for much longer than I would have liked. I could even stand in the same room as the Channel 9 AP (i.e. in the bottom-left corner of the heat map above) and not switch to Channel 9.

Performance Anxiety

The clue, yet again, is in the Info window above. In particular, the Tx Rate field. It would seem that rather than just naïvely choosing an AP based on signal strength, MacOS instead (or perhaps also) checks the network performance of the candidate AP. And look at the difference between the newer dual-band Linksys on Channel 3 (145 Mbps) and the D-Link on Channel 9 (26 Mbps)!

There are plenty of ways to increase your wireless data rate, the most effective being switching to be 802.11n exclusively, as supporting -b and -g devices slows down the whole network, but (as usual) I hit a snag - my Brother 2130w wireless (-only) laser printer needs to have an 802.11g network. As it lives in the study, a couple of metres from the D-Link AP, I'd had the D-Link running "mixed mode" to support it.

Printers were sent from hell to make us miserable

As it turns out, the mixed-mode signal from the Linksys at the other end of the house is good enough for the printer (being mains-powered it's probably got very robust WiFi) and so I could move the D-Link to "n-only". But there was a trick. There's always a trick ...
You need to make sure the printer powers up onto the 802.11g network - it doesn't seem to be able to "roam" - which, again, makes sense - it's a printer. It knows to join a network called MILLHOUSE and will attempt to do so - and if the "n-only" network is there, it'll try to join it and never succeed.
So powering down the n-only AP, rebooting the printer, checking it's online (ping it), then powering the n-only AP back up again should do the trick.

Summary

Moving the D-Link AP to n-only doubled the typical Tx Rate at the front of the house to around 50 Mbps, the result being that the Mac now considers Channel 9 to be good enough to switch to as I move towards that end of the house. It still doesn't switch quite as fast as I'd like, but it gets there, and doesn't drop any connections while it switches, which is great.

Here's the summary of the setup now:

	Living Room	Study
Device	Linksys X6200	D-Link DIR-655
IP Address	10.240.0.2	10.240.0.3
Channel	3	9
Mode	b/g/n	n-only
Band	2.4 GHz	2.4 GHz
Bandwidth	20 MHz	20 MHz
Security	WPA2 Personal	WPA Personal (sic)
WPA Mode	n/a	WPA2 Only
Cipher Type	n/a	AES Only

Stand by for even more excruciating detail about my home network in future updates!

Micro-optimisations

I finally got around to setting up some aliases for git commands that I issue many, many times a day. Can't believe it's taken me this long to do it. I've also placed them in a file in my Dropbox so I'll always be able to add them to any machine I work on regularly.

alias gs="git status"
alias gcm="git checkout master"
alias gp="git pull"
alias gd="git diff"
alias gcam="git commit -am"

Although I have a few other oft-used and favourite git commands, namely:

• git push - to push code to the server
• git merge master - to merge the code from master with code on this branch
• git checkout - - to switch to the previously-used branch (analogous to cd -)

I consider them either too powerful to be made dangerously accessible (in the first two cases) or, conversely, and perhaps not intuitively at first, too valuable to "forget" behind an alias (for the last case). I only recently discovered the - option to git checkout, but it's so good I'm deliberately trying to burn it into my brain.

This actually harks back to my first ever job as a professional engineer; we were using the mighty and fearsome ClearCase version control system, and I was tempted to shortcut some of the arcane commands required, but my manager (very wisely) cautioned similarly against aliasing away complexity. Don't underestimate the power of repetition for both muscle- and conventional memory!

I like to watch

Remember how computers were supposed to do the work, so people had time to think?

Do you ever catch yourself operating in a tight loop, something like:

  10 Edit file
  20 Invoke [some process] on file
  30 Read output of [some process]
  40 GOTO 10

Feels a bit mechanical, no? Annoying having to switch from the text editor to your terminal window, yes?

Let's break down what's actually happening in your meatspace loop*:

  10 Edit file in text editor
  15 Save file (e.g. Ctrl-S)
  17 Change active window to Terminal (e.g. Cmd/Alt+Tab)
  20 Press [up-arrow] once to recall the last command
  22 Visually confirm it's the expected command
  25 Hit [Enter] to execute the command
  30 Wait for the command to complete
  35 Interpret the output of the command
  40 Cmd/Alt+Tab back to the editor
  45 GOTO 10

That's even more blatant! Most of the work is telling the computer what to do next, even though it's exactly the same as the last iteration.
(*) Props to anyone recognising the BASIC line-numbering reference 😂

Wouldn't something like this be better?

  10 Edit file in text editor
  15 Save file (e.g. Ctrl-S)
  20 Swivel eyeballs to terminal window
  30 Wait for the command to complete
  35 Interpret the output of the command
  40 Swivel eyeballs back to editor
  45 GOTO 10

It can be better

If you've got npm on your system somewhere it's as simple as:

  $ npm install -g watch

and arranging your UI windows suitably. Having multiple monitors is awesome for this. Now by invoking:

  $ watch '[processing command with arguments]' dir1 dir2 ... dirN

you have the machine on your side. As soon as you save any file in dir1, dir2 etc, the command will be run for you. Here are some examples:

Validate a CircleCI build configuration

You're editing the circleci/config.yml of a CircleCI continuously-integrated project. These YAML files are notoriously tricky to get right (whitespace matters...🙄) - so you can get the circleci command-line tool to check your work each time you save the file:

  $ brew install circleci
  $ watch 'circleci config validate' .circleci

Validate a Terraform configuration

You're working on a Terraform infrastructure-as-code configuration. These .TF files can have complex interrelationships - so you can get the terraform command-line tool to check your work each time you save the file:

  $ brew install terraform
  $ watch 'terraform validate' .

Auto-word-count an entire directory of files

You're working on a collection of files that will eventually be collated together into a single document. There's a word-limit applicable to this end result. How about running wc to give you a word-count whenever you save any file in the working directory?:

  $ watch 'wc -w *.txt' .

Power tip

Sometimes, the command in your watch expression is so quick (and/or its output so terse), you can't tell whether you're seeing the most-recent output. One way of solving this is to prefix the time-of-day to the output - a quick swivel of the eyeballs to the system clock will confirm which execution you're looking at:

  $ watch 'echo `date '+%X'` `terraform validate`' .
  > Watching .
  13:31:59 Success! The configuration is valid. 
  13:32:23 Success! The configuration is valid.
  13:34:41 Success! The configuration is valid.
  

Tascam FireOne hardware buttons and GarageBand

Another blatant Google-troll here but hopefully it'll help someone else out there.

As mentioned elsewhere I use a Tascam FireOne Firewire Audio Interface when I make music with GarageBand, and it works pretty well.

Side note for even more karma: There are times when it doesn't work well (particularly on OSX Mavericks) and I humbly present my fixes which seem to work - mostly variations on the classic "turn it back off and back on again" trick:

• Mac doesn't "see" the FireOne - Check Thunderbolt-to-Firewire adaptor is snug, unplug-replug.
• Mac sees FireOne, FireOne seems dead - Unplug-replug.
• Mac sees FireOne, FireOne lights and meters working, no sound - Mash both PHANTOM buttons at the same time. This seems to (probably not by design!) cause a hardware soft-ish reset and audio should ensue.

But I digress. One of the nice things about the FireOne is the hardware control surface it offers. Now ideally you're running Pro Tools or some other very nice, very expensive DAW where the FireOne's buttons Just Work but if, like me, your needs are actually met quite nicely by GarageBand (not to mention its price), then you'll be wanting to get those buttons going in GB. Because they most certainly don't by default.

Sadly, you won't be able to map all the FireOne's buttons to GB functions, but the most important ones can be done. Firstly, download GarageRemote, a very simple, but nicely done System Preferences extension thingy. Install it, and turn on its "Listener" functionality so it can do its thing. Then, you'll need to customise the MIDI message mapping as follows:

I diagnosed the MIDI messages that the FireOne sends by using the free Snoize MIDI Monitor utility. Here's the full list, in case you want to tune your setup:

FireOne Hardware Control	MIDI Message Bytes
<<	90 5B 7F
>>	90 5C 7F
[]	90 5D 7F
>	90 5E 7F
O	90 5F 7F
F1	90 36 7F
F2	90 37 7F
F3	90 38 7F
F4	90 39 7F
F5	90 3A 7F
F6	90 3B 7F
F7	90 3C 7F
F8	90 3D 7F
Jogwheel CW (Slowest)	90 3C 01
Jogwheel CW (Slow)	90 3C 02
Jogwheel CW (Medium)	90 3C 03
Jogwheel CW (Fast)	90 3C 04
Jogwheel CW (Fastest)	90 3C 05
Jogwheel CCW (Slowest)	90 3C 41
Jogwheel CCW (Slow)	90 3C 42
Jogwheel CCW (Medium)	90 3C 43
Jogwheel CCW (Fast)	90 3C 44
Jogwheel CCW (Fastest)	90 3C 45
SHIFT (on its own)	90 46 7F

Weirdly, using SHIFT + other keys doesn't actually change the MIDI message that is sent, making it pretty useless for our purposes. I'd sure love to get my hands on that GarageRemote source code and support more buttons!

Easy artifact uploads: MacOS to WebDAV Nexus

I posted a while back about using the WebDAV plugin for SBT to allow publishing of SBT build artifacts to the CloudBees repository system.

Well it turns out that this plugin is sadly not compatible with SBT 0.13, so it's back to the drawing board when publishing a project based on the latest SBT.

Luckily, all is not lost. Hinted at in a CloudBees post, your repositories are available via WebDAV at exactly the same location you use in your build.sbt to access them, but via https.

And the MacOS Finder can mount such a beast automagically via the Connect To Server (Command-K) dialog - supply your account name (i.e. the word in the top-right of your CloudBees Grand Central window) rather than your email address, and boing, you've got a new filesystem mounted, viz:

The only thing the WebDAV plugin actually did was create a new directory (e.g. 0.6) on-demand - so if you simply create the appropriately-named "folder" via the MacOS Finder, a subsequent, completely-standard SBT publish will work just fine.

You might even want to create a whole bunch of these empty directories (e.g. 0.7, 0.8, 0.9) while you're in there, so you don't get caught out if you decide to publish on a whim from somewhere else.

Fixing FireWire audio interface instability under OSX Mavericks

A variation from my usual blog topics today, but hopefully this helps someone. I have been a happy user of the Tascam FireOne FireWire audio/MIDI interface ever since picking one up for a bargain price a couple of years ago. As a recovering music-gearaholic, I embraced its minimal dimensions, and together with GarageBand on the Mac, it has allowed me to eBay vast amounts of outboard equipment while actually improving the quality of the music I create. Thus confirming a suspicion I had at the peak of my gear-hoarding tendencies:

More Music-Making Gear == More Distraction From Making Music

But I digress. Despite being technically unsupported since OSX 10.5 Leopard The FireOne worked perfectly for me right up to (and including) OSX 10.8 Mountain Lion, so when 10.9 Mavericks was released I gleefully jumped aboard.

And was horrified when within a few seconds of playback in GarageBand, the entire hardware-software combination locked up, sounded garbled and/or complained about sample-rate problems. This was not good and I thought that either Apple had broken FireWire timing accuracy in Mavericks (perhaps as part of their timer-coalescing improvements) or I was just SoL and would have to shell out for a new audio interface.

As it turns out, neither was true.

If you are experiencing problems working with external devices under audio applications (my particular combination being a FireWire interface and GarageBand) your first action should be:

• Open Finder/Applications
• Find GarageBand (or the app giving trouble)
• Right-click -> Get Info
• Check Prevent App Nap

This is slightly counter to the Apple's own statement on App Nap which states:

if that app isn’t currently doing something for you — playing music, downloading a file or checking email, for example — App Nap conserves valuable battery life by slowing down the app

But I'm not too upset - it's an easy fix and the extra battery life is definitely worth the upgrade.