1.  How Abjad handles pitch. Motivation: pitch is handled a bunch of different
    ways in different music software systems. It seems like at least half (or
    even more) of articles describing music software systems spend at least a
    paragraph describing the way that pitch is represented. Perhaps it makes
    sense for us to detail the different ways that Abjad handles pitch and to
    explain why we reached the decisions we did concerning the representation
    of pitch. So that's a first category: pitch *representation*. Can we go one
    step further? Can we also explain some of the ways we implement pitch
    *transformation*? Abjad's rules regarding what happens when, for example,
    one pitch is subtracted from another (to produce an interval) are
    nontrivial but should be easy to understand when we lay out the entire
    regime. It seems like the decisions we have reached regarding pitch
    transformation should applicable to essentially any music software system
    and that, for whatever reasons, papers describing music software systems
    almost never discuss this topic. So the paper allows for a rich set of
    comparisons to the existing literature regarding pitch representation and
    also a novel contribution in the form of a discussion on pitch
    transformation. There are probably other systematic ways of thinking about
    pitch that such an article would allow us, finally, to document, too.

2.  "Implementation-independent analyses in music formalization." How do we get
    ourselves -- and developers of other music software systems -- to express
    the important notation-oriented problems solved during system development
    in an implementation-independent way?

    Outline in pseudocode the implementation for our tree model, beginning from
    incredibly basic grounds and gradually working in more and more complexity.
    Such a discussion should describe exactly how our tree works, but also why
    it was implemented this way rather than other ways, and what the various
    implications are for our model over others.
    
    Begin with basic containers and leaves as a naive nested list model. Then
    discuss Component as a parent class which encapsulates shared functionality
    (why and how should class hierarchy be used?). Discuss why and how any
    component can only have one parent (bi-directional pointers and the complex
    "handshake" of `Component._set_parent()`). Discuss how this model affords
    various tree-traversal routines. Discuss how and when durations and offsets
    are calculated and cached. Discuss how names are propagated up parentages.
    Discuss how indicator scoping is implemented.

    (Spanners might be too complicated for the above discussion, as that brings
    in problems of contiguity and logical voices.)

    A extensive discussion of our tree model, entirely in pseudo-code, should
    be possible in 10-15 pages.

3.  "From Music Representations to Operations on Music Representations."
    Motivation: isn't there an awful lot of literature on music representation?
    (How should pitch be represented?) And isn't there a dramatic silence on
    *operations* on things (like subtracting one named pitch from another named
    pitch?). We can address this point in a single paragraph attached to
    another article. Or we can raise this point directly as the topic of its
    own article. Possibly this makes for a very good verbal conference
    presentation that splits the difference between literature analysis and
    provocation.

2015-16 conferences/deadlines/specs/sites:
ACM Code Generation 2016(9/12, up to 10 pages, http://cgo.org/cgo2016/call-for-papers/)
ACM Document Engineering 2016 (??) 
