Time for a short report on office hours in practice: I’ve held three sessions so far and all have been great, at least from my perspective. Interesting conversations, good questions, and it’s been as humanizing as I had hoped.
Some of the people included (in their initial email) a list of things to talk about, which was nice, but I don’t think I want to make that a requirement.
I’ve also realized that I don’t like talking about politics, so that’s now off the table for these. (The political conversation that I had, though, was fine and civil and not a problem at all, to be clear.)
While it’s only been a week and my sample size to date is still fairly small, as of today I consider this office hours idea to be a great success. Definitely planning to keep doing it.
I’m getting a bit of a nostalgia kick reading through the Standard Ebooks process. I haven’t made anything with them (though they do good work and I’m reading two of their editions right now), but years ago — in a former life, it seems — I used to make ebook editions of old books.
As far as I can tell, the first ebook I made was Chesterton’s The Ball and the Cross, which I typed up by hand and posted to Project Gutenberg. Around that time I worked on a handful of other books for PG, including Henry Sweet’s An Icelandic Primer, which was much more involved (Old Icelandic characters, tables, etc.) and incredibly fun.
Somewhere around five or so years ago I stopped, partly from working on other things, partly from repetitive strain injuries. (Even with Vim macros to help, there’s still a multitude of repetitive keystrokes in cleaning up texts, at least for me.) With reading about Standard Ebooks and writing this post, though, I’m tempted to get back into it. I built Fledge years ago as an attempt to script away more of the repetitive work, and I suspect wiser use of both it and Vim might be enough to minimize the RSI.
On a related note, I’ve been wanting to rewrite md2epub. It’s a decent-enough Python script that takes Markdown files and turns them into an EPUB, and it’s worked well. But it’s an old codebase, and I don’t like the name anymore, and it could be faster, and I have a few ideas on how to make it more ergonomic, so I’m planning to dub it Caxton and rewrite it in Go or Rust. (Primarily so I’ll have an easier way to make EPUB editions of my fiction.) This part is the most likely to actually happen, I think.
I realized (this is the very small breakthrough I mentioned yesterday) that I could use Blender to add 3D texture to my pieces. Verisimilitude has been the goal all along, and using an actual 3D renderer brings so much to the table that it boggles my mind that I didn’t think of this much earlier.
A closeup of the texture:
How I made this piece: I mocked it up in Illustrator, then exported it to SVG where I manually added the turbulence and displacement filters (in Vim) to distress the edges of the white square, which you can see in that closeup. I used Inkscape to export the SVG to a 6500×6500 PNG.
Then, in Blender, I created a plane and went to town on the shading, using a combination of procedural and image textures to mix the colors together and displace the geometry of the plane. There’s a key light and a dim fill light. And in the compositor I added a little chromatic aberration around the edges with the lens distortion filter.
Rendered it at 5200×5200, which took about two hours on my 16″ MacBook Pro. I tend to work a little smaller and then upscale to 6500×6500 (for square pieces), since Photoshop’s upscaling is fairly decent these days. After upscaling, I added my signature thingie, which I’ll add in Blender in the future so it fits in better.
Here’s the node setup on the plane (and in the future I’ll use groups to make things more manageable):
Overall, I’m happy with this technique. It’s more time-consuming than painting textures in Photoshop, but I can do other things while it’s rendering, and the result looks much better to me. Working in 3D is more fun, too. Most importantly, using Blender gives me loads of new options that would have been harder to do well with my old technique — shiny paint, glowing materials, etc.
After avoiding the preparation of my thesis defense presentation for an embarrassingly long time, I got it together, put it together, and did a dry run with my advisor. All’s well.
Art seems to be reclaiming me after that dry spell, though who knows how long it’ll last. I gave my kids a short tour of Blender last night to showcase how animation works, and that sparked an idea which I’ll write about soon once I have a demo piece to show — probably tomorrow. (One could reasonably call it a very small breakthrough.)
I’ve been thinking (as I often do, because I am weird) about the flow of time in the consumption of creative arts. More plainly: looking at and initially comprehending a painting is fast. Almost instantaneous. But a book, a song, a dance, a film — all these require time to consume and comprehend. No conclusions yet; still mulling it over, trying to suss out any relevant meaning. Which may not be there, of course.
For fun, and to sharpen the saw, I’ve started working through some LeetCode problems. Mmm.
I haven’t yet started working on a new story or novel, but that will happen soon, just figuring out which ideas to use.
Several good video chats this week —family, friends, and office hours (of which I will post a writeup in the near future). It’s been a humanizing week.
It would be nice to have virtual audio backgrounds in Zoom etc. as well as graphical backgrounds. Mask out the crying toddler, add some concert hall reverb.
I have to say, getting back into blogging has been incredibly fun, and I’ve very much enjoyed my initial foray so far into working and learning in public.
Went on a family drive round the lake. The lake is much larger than I expected; the version of the world in my head is so much smaller than the physical world.
What’s caught my interest lately: PostGIS and cartography and map data. I love geography.
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.
Achievement unlocked: today I finished the first draft of my (as yet untitled) novel, weighing in at just over 260 pages (65,000 words).
It’s a good feeling, but the work is far from done. As mentioned, I’ll let it sit for a month or so to distance myself from the text, then it’ll be time to dive into editing.
In the meantime I’m still planning to write several short stories and outline my next novel and try to figure out ways to speed up this novel-writing process without sacrificing quality. Fall semester starts soon and will inevitably slow all of this down, but hopefully not to a halt.
