Migrating to Day One has resurrected my efforts to scan and transcribe my older paper journals. As I’ve been doing this, I’ve run into the need for a couple small shell scripts to automate things.
On several of these journals I’m scanning the full two-page spread because the whole journal fits on the scanner platen, which means splitting the resulting image out into two (one for each page). Splitimage uses ImageMagick to do that nicely. There’s some overlap, but for a fully automated solution it’s not bad, and it saves me a lot of time cropping.
I prefer taking these split images and renaming them sequentially using something more meaningful (“journal-2009.005.jpg” rather than “IMG_0034.JPG”, for example). I used to do this with OS X’s Automator tool, and it works quite well, but I wanted a quick command-line tool to speed things up. Enter dub, a zsh script that simplifies the batch renaming process. Now I can just type:
dub journal-2009.X.jpg *.JPG
And then it’s just a matter of dumping them into Unbindery and transcribing them.
As many of you already know, yesterday morning the Church announced a new 2013 edition of the LDS scriptures. Nothing exceedingly groundbreaking — no new or changed doctrine, for example — but still exciting, at least to scripture nerds like me (especially since it’s been over thirty years since the last major edition came out).
Here’s a quick overview of the changes I found interesting (keep in mind that I’m a typesetting/editing geek and so most of what I find interesting is dreadfully dull to ordinary folk):
Standardized formatting on title pages across the standard works.
In the Book of Mormon, they’re now using roman text for anything that was on the original plates and italics for the extracanonical additions (like the chapter headings). It’s a small change, but it’s nice, since some people don’t realize that most of the book headings are part of the original and not a later addition.
Standardization of things like “house of Israel” and “firstborn” in the Book of Mormon.
“Rereward” in the Bible is now “rearward” (so hurray, it now no longer looks like “re-reward”).
The introduction of the Book of Mormon now says “a record of God’s dealings with ancient inhabitants of the Americas” (not “the ancient inhabitants”), to provide clarity and greater accuracy. Also, “they are the principal ancestors” is now “they are among the ancestors,” again for clarity and greater accuracy. Which is great.
There are a few new paragraphs in the D&C introduction adding interesting historical information.
The D&C 13 heading no longer mentions the banks of the Susquehanna River as being the site of the restoration of the Aaronic Priesthood. That section heading explanations page has the details.
The first three verses of D&C 89 (the Word of Wisdom) are no longer attributed to Joseph Smith but are part of the revelation itself.
D&C 135 is no longer attributed to John Taylor.
The Harmony of the Gospels (in the study guide section) now uses a portrait layout instead of a landscape layout. Finally.
Larger typeface on the JST section at the back.
New JST entries and footnotes. I haven’t checked them out yet, but I’m looking forward to it.
The 2013 edition is already available at scriptures.lds.org and in Gospel Library, and the print edition will come out in August. And yes, of course I’ll be getting the print edition.
I’ve gotten some questions as to whether I’ll be updating my reader’s editions with these changes. You know, I haven’t decided — mostly because I’m not sure whether the changes are covered by copyright or not. The study guides are, of course, as are the chapter headings, but I don’t include those in my editions (mine are based on pre-1923 editions so that I’m positive it’s public domain). We’ll see.
Our toddler loves looking at letters and saying their names. A while ago we printed the alphabet out onto cardstock and have been using that with her, which is great, but I’ve also wanted to write a small web app that does the same thing — mostly for when we’re in another room, but also to make the randomization a little better. And because I can’t seem to stop writing little apps.
I’m starting to get more into typeface design, and so I put together a little web app to generate PDF templates for sketching type out (with guides for the ascender, baseline, x-height, etc.). It’s called Typlate:
You twiddle with the numbers till you get proportions you like, then print out the PDF and start drawing:
Technical note: I’m using jsPDF to generate the PDF in-browser. In fact, there’s no server-side code at all. It’s amazing what you can do with JavaScript these days.
Introducing Spin, a game I threw together hastily for a little game jam I did with some friends.
Basically, you’re in a maze and have to get out before the timer runs out (ten minutes, which I display as 600 seconds because hey, I didn’t have much time) (pun not intended?). The world rotates 90° every five seconds with gravity changing as well, and the walls and obstacles hurt you if you touch them. And that’s about it. I threw most of the level together in, oh, about twenty minutes, so gameplay may end up being more frustrating than fun. But there is an exit, I promise. It may just take several rounds to find it without dying.
Technology-wise, Spin uses Box2D for the physics and THREE.js (WebGL) for rendering. I recommend playing it in Chrome, since Firefox’s WebGL wasn’t hardware accelerated (at least on my Mac) and was dog slow. (Safari works fine, but you have to enable the developer menu and then enable WebGL.)
Update: I realized this morning that it would be fairly trivial to add a first-person mode, since all I’d need to do is change the camera. So I did. It’s more boring of a game — with the gravity and world-rotation gone, it’s just maze exploration — but it’s kind of cool that WebGL makes it easy to do both kinds. The README has more info on how to activate the first-person mode.
For a while now I’ve used option-0 on OS X to type a degree symbol, primarily for tweets about how blasted cold this winter has been. But I’ve accidentally transgressed. That symbol (º) is not in fact a degree symbol, though it sure looks a lot like one. It’s actually an ordinal indicator. Sayonara to my typographic street cred…
To get the real degree symbol (°), type option-shift-8 instead. Now if only I could go back and edit all those tweets… (I blame iOS, where holding down the 0 key does in fact get you a degree symbol.)
A semi-literary art experiment, wherein each letter gets assigned a color, the user types in a sentence, and the color bar gets drawn on the screen and melted up and down:
The colors are chosen by starting with a few base hues and then doing variations off them. Sometimes it produces gorgeous color schemes, and sometimes (okay, maybe most of the time) they’re jarring. What I should have done was start with a random hue, then build an appropriate color scheme (whether monochromatic or complementary or whatever) off of that.
I’m using a really simple dithering-esque algorithm for doing the melting (pulling from a random nearby neighbor pixel). Part of me wants nice antialiasing instead, but I suppose this has a slight 8-bit charm to it. Right now the left and right edges inadvertently end up pulling in some outer darkness, which I kind of like. (Oddly, though, it only happens in the top half of the screen. Not sure why.)
As usual, the code is on GitHub. There’s a live demo as well.
More examples, all using the default sentence (from Pride & Prejudice, unintentionally in honor of the 200th anniversary of its publication yesterday):
Two years ago my friend Chad and I released Botswana, a browser-based arena game with programmable bots written in JavaScript.
But the original was kind of boring. So we tweaked the game mechanics a bit and made a number of other modifications (multiple bots per team, extensible rulesets, etc.). And now we present Botswana 2.0, a culmination of rampant nerdiness.
The thing that interests me most about the game now is the customizable rulesets. For example, it took all of ten minutes to change the game so it’s played on a series of conveyor belts that move the bots up and down:
It likewise took less than half an hour to make the bots orbit the Death Star instead:
Since the drawing code is part of the ruleset, it’s fairly easy to get a radically different look:
Switching between the rulesets is just a matter of changing the URL in the ruleset box and starting a new tournament.
Anyway, as before, the release is on GitHub, with a README that explains how to write bots and customize rulesets and stuff.
The web is now the best document delivery platform, and that will become even more true as time goes on.
Documents need to be flexible so you can view them on any size device — desktop, tablet, mobile, anything.
As I’ve been doing more responsive web design, I’ve been thinking that this principle of reflowable content could apply to sheet music. For example, here’s a normal page of sheet music (from the Mutopia project):
If you were to view this music on a smartphone, you’d either have to zoom all the way out (making it super small), or zoom in on just one section of the page and pan around, which can be a lot of two-dimensional panning — not too great if you’re trying to actually play the music.
Neither is ideal. So I’m thinking maybe sheet music should automatically reflow to fit your viewport — the way both text and responsive websites do:
(This is just a quick copy-and-paste mockup — in reality you’d keep the clefs on each line and probably make things a little smaller and so on — but you get the idea.)
So as the viewport shrinks, you would drop the space between notes until you hit an unacceptable squishiness, then drop the number of measures per line by one and set the space between notes to be wider to fill the space again. Rinse and repeat. By the time you’re down to smartphone size, you’d probably be at two measures per line as in the above mockup.
Implementation
In a perfect world, there’d be a set of tags in HTML for typesetting music, and the browser would do the rendering, and CSS media queries would take care of the rest. That will almost certainly never happen, though, since it’s too domain-specific. I think the best we can hope for is a JavaScript rendering engine that uses SVG — something like Vexflow.
One other thought: jumps (repeats, codas) should be hyperlinks, so the player doesn’t have to think about where to go. (And when it jumps to the location, it could flash a highlight or marker or something on the measure you should start at.) Or, even better, since we aren’t really worried about taking up space, just flatten repeats and codas altogether — take the repeated section and write it out. Space isn’t as much of an issue on the web. The disadvantage is that it’s not as easy to know that the repeated section is in fact identical.
Disadvantages
If you’re only seeing one or two measures per line on, say, a smartphone, and if you’re playing something with more than one staff (piano music, for example), then you’re going to be doing a lot of scrolling. So you probably wouldn’t want to go down quite this much.
There’s also a slight loss of familiarity. When you play a page of music over and over again, you get familiarity grooves etched into your mind; with responsive sheet music, you wouldn’t really get that as much. (If you used the same device every time in the same orientation, then it’d be a little more stable, but you’d be scrolling instead of flipping pages, which anchors things less.)
Ticker-style sheet music
Another idea that came to mind when I was mulling this over was reducing the music to one line and automatically scrolling it like a ticker. (This probably already exists. Responsive sheet music may exist as well, but I couldn’t find it — if someone has already implemented it, let me know. I want to use it.)
Advantages:
Focus. Since the music is one-dimensional, the player doesn’t have to think about other dimensions (down and up, where the end of the page is, etc.).
Linearity. With this style it really would be better to flatten out repeats and codas, so it’s just one long line of sheet music. Then you don’t have to spend any mental cycles thinking about jumping around.
The disadvantages are pretty much the same as with responsive:
You lose some familiarity — with a full page of music, you get used to its layout and it reminds you of things, whereas a scrolling ticker would always feel somewhat new.
Flattening repeats makes you lose the knowledge that the repeated section you’re starting to play is the exact same as the previous section.
