Re: Do we really offer the future?

[Kieren MacMillan]

Hi Pete,

> So major compositional changes -- the ones we're
> calling "structural" here -- are implemented at that
> first (gen.purp.prog.lang) level, tossing LP not much
> to trip over then or fail to carry through.
> 
> My point, then: Why stuff a complicated-enough
> engraving program with (compositional) issues
> that by nature demand more abstract handling?

Here are two real-world examples, drawn from my own recent life.

1. In 2013, I composed and engraved a piece with nearly 12,000 frames (57 
staves x 208 measures). It contains two sections (of ~32 and ~16 measures) 
which were specifically added "for That Production” (and, as such, contain 
“external material”). Now I want to modify the piece — someone has asked to 
license it for performance later this year. So I want to either eliminate those 
two sections, or replace them with different transitional material, so that I 
can publish a “standalone” work, separate from “That Production”.

2. One of my stage musicals (“Robin Hood: The Legendary Musical Comedy”) has 
been picked up for further development. It comprises nearly three dozen cues, 
each ranging from a few measures up to over 200; and there are 23 staves at its 
thickest point. In the Finale (the longest and most complex cue!), we want to 
trim the coda by [an internal] 16 measures for the next version.

In both scenarios, the prospect of editing and rewriting is quite daunting, 
given the structure of the Lilypond code and its identified limitations in this 
area.

Call it a “compositional” issue if you want… but post-hoc 
manipulation/modification of large [and thus code-heavy] scores are a fact of 
life, and the easier we can make it for [power-?]users to modify existing large 
scores, the better IMO. And expecting users to implement and learn a 
complicated extra toolchain is not the right answer.

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: address@hidden