Day 9: Possibility
I'll admit, I'm getting a little bogged down by having to read several different Django tutorials that all basically say the same thing.
Dain explains in the Advanced Beginner Challenge that it's about social context — by the time we actually begin to work with the code, we will have seen the instructions a bunch of times and gotten a sense of the community and best practices.
And I'm doing it! But I couldn't help myself — I started some other projects.
I've been interested, for a long time, in software that would help musical theater collaboration teams to work better together. Of course, what comes to mind right away is a fully-featured, online collaboration tool, with everything from videoconferencing to version control to task management…
But honestly, it's way beyond my skill level. And anyway, there are a zillion different tools that already do those things better than I likely ever could.
I realized today, though, that Final Draft and Finale — the applications my collaborator and I use to write musicals together — both export data in some form of XML. Between the two applications, there's a lot of redundancy. One of those redundancies is lyrics.
That is to say, when my collaborator prepares a libretto for a scene that includes a song, and I prepare a lead sheet or fully-realized arrangement of a song, we both type in the lyrics manually. Because of that, there's a high chance of discrepancies between the two, especially when we're both tired and overwhelmed.
It's the kind of thing that a music editor would help to mitigate, but that's… not always in the cards.
So I thought, What if there's a way to extract lyrics from both MusicXML files and Final Draft documents and compare them?
As I began to dive in to the file formats, I realized it's no easy task: Final Draft creates <text></text> tags for every word, and MusicXML's specification separates words by syllable.
I was, ultimately, able to create a function that concatenates MusicXML syllables extracted from an uncompressed .musicxml file with one voice and print() the resulting text to the screen.
And as I tried to make sense of Final Draft's implementation of XML (with some friends' sample scripts at my fingertips), I thought, There's got to be a way to parse this and convert it to HTML so folks don't have to spend $250 on the software just to be able to open their collaborators' scripts. Surely, there are implementations out there.
I even spent some time learning how to render a website so it looks like a page, and how to make print-friendly CSS. How cool would it be to make a Flask app that accepts a Final Draft script, extracts metadata, and renders a nice, HTML site that's paginated and printable?
In my cursory search, I found a parser by Alex Coppen called screenplay-parser. But, perhaps more interestingly, I found his specification for a ScreenJSON file format that treats screenplays as JSON objects. It's pretty cool.
And it's a cool medium- to long-term project: to figure out how to implement a web application — probably in Django — that can accept a ScreenJSON object and render a rich, web-friendly screenplay, complete with access control for each element, version control, and tons of metadata.
As far as I can tell, it's not been implemented yet, and Coppen's ScreenJSON specification is yet to be adopted.
What if there's a future in which I could develop a web-based tool that can read and write MusicXML and Final Draft, store an annotated, canonical libretto with version control and hypertext to sound files and sheet music, and can even automate the process of creating an integrated score? Lilypond is supposed to be very good at automatic music formatting, and there are tools to convert MusicXML to Lilypond.
Ah. I'm probably getting ahead of myself, but I have to admit — it's fun to think about what's possible.