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):
- Press — low-level typesetting (PDF compiler)
- Ink — higher-level typesetting
- Curves — programmatic type design
- Typlate — type design templates
- md2epub/Caxton — ebook compiler
- epubdiff — ebook differ
- Fledge — text processing shell
- 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.
What I’ve worked on:
- Trill — music composition REPL
- Grain — command-line tool for texturing art
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.
- Influences that I’m aware of: ABC notation, Lilypond, and Alda.
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.