Some quick thoughts about the project space I see myself working in (meaning personal coding projects that aren’t the productivity tools I mentioned before), both now and for the foreseeable future. To be honest, it’s mostly a roadmap for myself, posted here as part of working in public.
Bookmaking tools
One of the areas in the project space is bookmaking tools: tools that help with making either print books or ebooks. What I’ve worked on in that area (and some of these are still in progress or in the future):
Storybook — writing tool (covered under the productivity tools, yes, but I feel it fits in here)
Creativity tools
The next area, somewhat related, is creativity tools: tools for making art, music, etc. I do realize that there’s a bit of overlap between the two areas — art can be used in books, for example. This is not a rigorous taxonomy.
While I haven’t done much in this area so far, the intersection of software and art has been calling to me more lately. I expect creativity tools to become much more of a focus for me, probably even more so than the bookmaking tools.
Human-Computer Interaction
Last but not least, HCI. My master’s thesis is in this area, and much of my other work also touches on it in limited ways. (What I mean by that, I think, is that with projects like Trill, Curves, and Press, the parts that have most interested me are the interfaces. Also, those interfaces have been textual in these particular cases, but I’m also interested in other kinds of UIs.) So I plan to start building more proofs of concept and interface experiments — like the spatial interface ideas I mentioned several weeks ago.
A year and a half ago I started working on a REPL-based music composition environment called Trill. After a short amount of time I stashed the project for the time being, but since I can see myself working on it again someday, I figured it’s due a write-up.
The core idea here is a text-based REPL for composing music (and by music I mean more things like hymns and movie scores and folk songs, not as much pop or rock or electronic), with a focus on making the composition experience more aural and less visual.
An example session will hopefully help anchor the ideas:
> score mysong
> staff piano # add a piano staff
> keysig c
> timesig 4/4
> keytime c 4/4 # alternate
> play v. v. v. iii.... # plays the note sequence (. = quarter note, .. = half note, .... = whole note)
> play v. v. v. iii-.... # - = flat (and v, iii are based on the key signature)
> play v/ v// v/// # eighth, sixteenth, thirty-second notes
> add . # adds what was last played to the active staff
> play V IV^ IV_ # play a V chord and then a IV chord one octave up and again one octave down
> pm vi. # plays the last measure plus whatever notes are specified
> add vi.
> staff violin # adds a violin staff
> play @arpeggiate piano # plays two measures of violin arpeggiation based on the piano staff (where @arpeggiate is a generative method)
> save
And some miscellaneous, unordered notes:
Rather than seeing the notes listed out (either in standard music notation or in text format), you basically only hear them (via play). This is the aural-over-visual part.
Duration is represented by the number of periods (cf. the play examples), as an experiment with making the length feel more visceral — a longer string of periods makes for a longer sound.
I’m also experimenting with using the relative scale notes (the Roman numeral notation) rather than absolute note names (C, D, E, etc.), to make transposing easier.
Not sure yet how dotted notes fit in here.
I threw in the idea of having some kind of generative functionality (@arpeggiate), but that’s pretty raw and not thought through at all yet.
The session transcript would also possibly function as the source for a song, and reloading it later would just skip the actual playing and instead just build the staff. Kind of nice to have the full history recorded, I think.
To be clear, I have no idea if any of these ideas are actually good. They’re just half-baked thoughts at this point. I did implement a very small proof-of-concept using FluidSynth and Prompt Toolkit, with the play functionality working, but that’s where I left off. (Writing about it now, though, has me excited again. Maybe this will be my homework-avoidance project for the semester.)
The main things I need to sort out when next I work on Trill are how to navigate a score and how to manipulate notes using textual commands and this aural-first system. Basically, some way to say “go to this part and play this much” and “bump this note up this much” or “make this note a chord.” Seems doable; I just haven’t gotten that far yet.
The productivity tools series has now come to its end, thankfully. (Thankfully because I’m more interested in talking about current and future work.) I ended up featuring only twelve; there are a couple others I’ve stopped using, but if that ever changes, I’ll write about them.
The last entry in the navel-gazing series talking about my personal productivity tools.
Arc is my private notes app. It’s a Python app running FastAPI. The name is short for Archive, as in an archive of notes. It’s my latest app, too — I wrote it around a month ago, as a replacement for Apple Notes (to try to get back to more of a Notational Velocity or Simplenote kind of thing). And just to be clear, this is distinct from the digital garden notes idea I talked about earlier.
Overview
Notes are just text files, stored in a directory with UUIDs for filenames. By default it opens to a blank note screen, but that’s boring, so instead you get to see what it looks like when editing a note (with the bar at the top indicating the text isn’t saved — I originally implemented autosave but soon realized that I prefer manual):
The search page lists the twenty most recently modified notes (dummy data):
The search results page uses Ag under the hood (since all the notes are just in a flat directory for now, it was super easy and took maybe ten minutes to implement):
How I use Arc
On my laptop, I have it open in Firefox as a pinned tab. On my phone, I have it saved to my dock as a PWA.
I’ve been using Arc daily, to keep track of things that I want to be able to refer to easily later on; normal notes usage, nothing too exciting here.
The future
Arc is still pretty new, so we’ll see where continued usage takes us. I’m happy with the plain text storage and with FastAPI, though. (Thus the plans to move over to those for the other tools.) It too is a small app, with around 500 lines of code. Maybe at some point I’ll switch from Ag to ripgrep, but that’s about the only change I can think of right now.
Yet another entry in the ignominious series talking about my personal productivity tools.
Lector is a reading app for macOS. It’s an Electron app for now. The name comes from the Latin (for someone who reads), with a homophonic hat tip to Hannibal. It came about from wanting a minimalist app that would let me read PDFs and scanned books in dark mode and keep track of my spot across multiple books.
Overview
A Lector book is just a directory full of images. (PDFs have to be split up into image files first, so I have a small script to do that.) When the app starts up, it looks at the book list directory to see what books are available. It also has a JSON file to track where I’m at on each book (which page and which part of the page), what size the window is, which book I last had open, etc.
The app itself looks like this, on an empty desktop to show how I usually use it:
No title bar, since I find that distracting. And the page images are scaled by default to fit the window width.
Hitting g / brings up a brief panel showing the books that are in the system, with alphabetized keys to get to them (so g a to go to the first, g b for the second, etc.). When I’m done reading a book, I delete its directory, so these mappings change fairly regularly.
j and f and double-clicking all go to the next page; k and d both go back to the previous page. J and K move up and down the page (in larger jumps), and the mouse can also be used to scroll. (I find that I mostly use the mouse for scrolling and f/d for page navigation, but every once in a while I’ll use the other keys.)
As you can see in the screenshot, it defaults to dark mode, with slightly lowered contrast for easier reading. i inverts the colors and s toggles the higher contrast view.
How I use Lector
I use it when I want to read a book I’ve scanned (usually with Scanbook). I haven’t used it as often lately, but I fully expect that to change soon. (It’s been very handy for reading textbooks.)
I’ve found that I prefer the window size shown in the screenshot, wide (so that the text is large enough) with just enough vertical room for a paragraph or so (since reading in smaller chunks is easier).
The future
I’d like to move off Electron at some point, probably to a native Swift app. Having it support PDFs directly (or splitting them up itself) would be nice, and having a way within the app to remove books would also be good.
Finally, I’d love to add EPUB support at some point. (I haven’t yet found a desktop EPUB reader I like. Marvin’s great on iOS, though.)
Saturn is my launcher app for my phone. It’s a small Go web app. The name comes from the Saturn V rocket launcher, and I wrote it as a replacement for Launch Center Pro (when it switched to a subscription model, because apparently I am allergic to those).
Overview
This is what it looks like:
The blue buttons are direct links to pages. There’s a very hard to see dark textbox at the bottom, and if I type something in there, the green buttons take that and execute a search somewhere else. Finally, the pink buttons open secondary panels, like this Notebooks panel:
On this panel, the lighter rectangle above the buttons is a search box that allows filtering through Vinci notebooks.
How I use Saturn
On my phone, I have it saved to my dock. It’s not set to be a PWA, because then the links would open in the in-app Safari; I prefer having them open in normal Safari.
I use Saturn pretty much every day. I mainly use it to set reminders, search Amazon, Goodreads, and eReaderIQ, and get to my journal and my daily review list.
The future
I’m largely happy with it as-is. Maybe some more refactoring of the buttons (the Search button is largely obsolete now that I’ve moved all those buttons to the main screen, for example), and it could use a little design love to make things more consistent (search boxes, for example), but that’s it.
