Home Archives Search Feed

A Deaf Audiophile

“Listening”: a Video Tribute to Art Dudley

Listening, an extraordinary video tribute to the late writer Art Dudley’s taste, vision, and devotion to music, premiers this month on Stereophile’s YouTube channel. The video follows the unusual path of Art’s beloved Altec Lansing Flamenco loudspeakers from their home in Upstate New York to their current residence, the listening room of deaf audiophile Bob Lichtenberg in Port Orchard, Washington.

Lichtenberg, 64, who serves as senior court program analyst for the Washington Supreme Court Interpreter Commission, began to lose his hearing at age 5. By 8, he was completely deaf. Today, he’s a confirmed audiophile with a huge LP collection and a dedicated listening room that holds several systems. He began listening to music by mapping musical vibrations emanating from a small bookshelf speaker held to his ear. From there, he moved on to HiFiMan, Sennheiser, and AKG headphones, which enabled him to map more nuanced vibrations.

“Listening” | YouTube

July 8, 2023 deafness audio music

Using the tool is the cure for thinking about the tool

I spent most of my waking free time this weekend (so far) researching clothes dryers. I used The Archive to collect manufacturers, model numbers, prices, vendor URLs, reviews, and Reddit recommendations and horror stories. All that stuff gets written to a file in my trusty folder of Markdown notes. Zero effort to edit on the MacBook, easy to update and refer to on 1Writer on the iPhone. I thought for a couple of seconds about using org-mode for it, but in this case, I needed ubiquitous, easy access from everywhere. I never second-guessed it once I got started! Markdown is imperfect and not as good or fun as org-mode, but fine for this job. I just needed the momentum of doing something with a tool to (temporarily) get over thinking about which tool to use.

July 2, 2023 org-mode Markdown tools The Archive

Stopping to think

I have 16 minutes left in my lunch break and don’t have time to write this in a way that makes sense. But I want to put this here to remind myself to try to tie together:

  1. What Mike Hall wrote in Because You Can about the tendency to shave off keystrokes and end up over-automating something, when sometimes it’s better to preserve enough friction in your process to give you a chance to slow down and think. I used to actually enter things directly into all my topic journals and individual log files in one Markdown folder. Even when all I had at the moment was a phone! I still have all those files, one each for found music, books to read, movies to see, and dozens of other areas. But then I adopted the Daily Notes idea. Drafts was extremely good and fast at capturing ideas, quotes, links, and any kind of text-based ephemera into one note per day. And now I have 3,958 draft blobs in the Drafts inbox and the individual text files are neglected and poorer for it.
  2. What Dave Gauer wrote in Making sense of it all: wrap-ups about doing weekly and/or monthly retrospectives on your daily notes, journals, obsessive logs, whatever. I feel like tedious, manually-created wrap-ups are the secret decoder key to making notes and logs into something valuable. Whether I’ve relied on Roam, TiddlyWiki, Obsidian, Logseq, or org-mode to “tie everything together”, it’s still the same thing: hoping technology will make sense of everything without me having to do any work.
  3. Looking back at this list of questions to ask yourself in a yearly review, and finding the text file where I answered most of those questions at the end of 2017. In there were tons of events I’d forgotten about and advice I gave to my future self, also forgotten. But the 2017 text file was all manually created — certainly copied and pasted from other sources, but not auto-generated in a dynamic list from tags sprinkled across Daily Notes. And because the minutiae was sifted out and the best parts rose to the top, it’s one of the most important records I have.

June 30, 2023 time speed automation order

A haphazard Doom upgrade

Last night, just before midnight, I thought I would do a “quick” upgrade of Doom Emacs on the M1 Max MacBook, since it had been well over a year since I’d upgraded. It’s a dumb choice for someone who knows, say, what a bad idea it is to do a deployment to prod on a Friday afternoon. This is the same thing at home. Here’s what I did, and I’m not saying any of it is recommended, but it’s what got things working again.

It all started when I did this in Terminal:

    doom upgrade

And got:

  > Upgrading Doom Emacs...
    > Cleaning .elc files
      - No elc files to clean
    x There was an unexpected error
      Message: File is missing
      Error: (file-missing "Opening input file" "No such file or directory" "/Users/phil/.emacs.d/core/packages.el")
      Backtrace:

etc.

So I googled that and found on the Doom Discourse site:

Breaking change on b9933e663771

A heads up to Doom users: doom upgrade will break itself when updating Doom past b9933e6

A-ha!

So I tried these lines in The workaround section:

    cd ~/.emacs.d
    git reset --hard a9866e37e45b43785116ef474c8cd6aa9b5185dd
    git pull origin master
    doom sync -u

And got this:

    x There was an unexpected runtime error
      Message: Symbol's function definition is void
      Details: (straight-recipes-nongnu-elpa-retrieve)
      Backtrace:

etc.

I thought maybe I needed to follow the advice here:

https://github.com/doomemacs/doomemacs/issues/4950

You need to manually upgrade straight :

So I did what they suggested:

    cd ~/.emacs.d
    rm -r .local/straight/repos/straight.el
    ./bin/doom sync -up

That seemed to go mostly ok but I got a handful of warnings about branches being ahead/behind, so I went with the options it suggested to follow when you’re “unsure”.

And then at the end it said:

    ! Wrote extended straight log to ~/.emacs.d/.local/state/logs/cli.doom.230627002937.13605.error
    ! Script was abruptly aborted, leaving Doom in an incomplete state!
    - Run 'doom sync' to repair it.

So I ran:

    doom sync

and that seemed to go ok.

And then I tried to manually upgrade Doom again:

    cd ~/.emacs.d
    git reset --hard a9866e37e45b43785116ef474c8cd6aa9b5185dd
    git pull origin master
    doom sync -u

Got a few more prompts to “pick this if unsure”, followed those, and got:

    ! Wrote extended straight log to ~/.emacs.d/.local/state/logs/cli.doom.230627003634.17287.error
    ! Script was abruptly aborted, leaving Doom in an incomplete state!
    - Run 'doom sync' to repair it.

So I again did:

    doom sync

Ran Emacs and got some errors like this. You know you’re in trouble when you can’t even get a clean launch:

    Error (doom-after-init-hook): Error running hook "doom-modeline-mode" because: (void-variable doom-modeline-mode-alist)

Ran this:

    doom doctor

And oh lord, lots of problems, starting with:

    > Checking your Emacs version...
      ! Emacs 27 is supported, but consider upgrading to 28.1
        Emacs 28.1 is better supported, faster, and more stable. Plus, Doom
        will drop 27.x support sometime mid-2022.

Ok, then! Might as well upgrade Emacs, too.

    brew update
    brew upgrade
    doom sync

And it ran forever, updating tons of things I probably will never use, and then I launched Emacs and thank heaven it worked ok. Whew. Now I’m on Emacs 28.2 and Doom 3.0.0.

And this is something I do for fun?

June 27, 2023 Emacs Doom

Blindness and note-taking

As if I didn’t need another thing to worry about regarding where to keep notes (Markdown, org-mode, paper, etc.), I’m adding a new layer: What if I go blind someday?

I’m not even kidding here. I’m already legally blind in my right eye because of having a congenital cataract removed shortly after I was born. Back then, we were years away from lens implants being commonplace, so my eye just never learned to do much of anything and now it’s only useful for peripheral vision. I was taught from before I could speak to protect the left eye at all costs. That eye seems to be doing overall fine, and I’m going through all the life milestones that come to a 52-year-old person. First came distance eyeglasses, reading glasses, and now progressives.

But someday that eye may get a lot worse, or I may get injured somehow in a way that leaves me truly without usable sight. What happens to all my carefully curated Markdown and org-mode files then? How will I use a computer with any kind of speed? I hope to not find out anytime soon, but I’m curious, and so I find things like this:

EmacsConf 2019 - 08 - How a Completely Blind Manager/Dev Uses Emacs Every Day - Parham Doustdar

(Text version, in org-mode!)

Of course tons of people in this situation adapt and figure out ways to use their hardware and software for work and play. But it makes me wonder, for now:

  • Is Markdown more blind-friendly because it’s less powerful and there are so many apps that understand it?
  • Is org-mode the better bet because it’s so transmutable?
  • Which corner am I painting myself info if something happens?
  • All this stuff is text anyway, so does it even matter?
  • What file-naming convention is the easiest to hear instead of see?
  • How granular should my text files be? Small, single-purpose files, or sprawling with tons of headlines?

June 23, 2023 blindness org-mode notetaking

Jumping between org-journal entries

I go hot and cold on org-journal, and when I get into it I build up quite a history in it, especially after settling on the monthly file format (like 2023-06.org) as the one that fits my brain the best. I like how even if you’re not in Emacs, it’s easy to scroll through and scan the days with your eyes, and the entry metadata makes for a nice header:

#+TITLE: 2022 February

* Friday, 04 February 2022
:PROPERTIES:
:CREATED:  2022-02-04
:END:

Worked on-site. Ate lunch w/Josh and Kathy.

* Sunday, 06 February 2022
:PROPERTIES:
:CREATED:  2022-02-06
:END:

Finally got `consult-ripgrep` working in Doom Emacs for org-mode files thanks to help from Jack.

Washed more dishes. Watched part of an old Psych with SH. Ate a small lunch of leftover falafel and 1/2 a bun.

But I didn’t feel nimble in it when I was in Emacs. You can do consult-org-heading to jump to any heading when you’re in a monthly org-journal file (or any org-mode file), but if you have subheadings, you’re going to wade through those, too. And you can navigate through headings in other ways in org-mode, but the nicest org-journal way is with org-journal-next-entry (C-n) and org-journal-previous-entry (C-p), because it jumps you back and forth by whole days, switches you between files when necessary, and collapses all but the one day you’re looking at:

#+TITLE: 2022 February

* Friday, 04 February 2022
:PROPERTIES:
:CREATED:  2022-02-04
:END:

Worked on-site. Ate lunch w/Josh and Kathy.

* Sunday, 06 February 2022 ...
* Monday, 07 February 2022 ...

I still don’t have a good convention for what goes in org-journal entries vs. daybook.org, events.org, or Day One, but every little bit of friction I can remove from Emacs helps. Using org-journal to browse around its own entries as nature intended also helps me step away from the crazy idea of including all the org-journal files in org-agenda.

June 18, 2023 org-mode org-journal