Re: Sponsoring lilypond development Was Re: Score parts: instrument and duration

[Han-Wen Nienhuys]

Trevor Baca wrote:
> > Is this a conscious decision? It's easy to have a list archived
> > (including spam-protecting addresses) through mail-archive.com or gmane.org.
>
>
> I'm sure it's not conscious; SCORE's mailing list is run out of the
> generosity of Gordon's time and I'm sure it's probably a simple matter
> of Gordon not yet having hand the time to take advantage of what gmane
> has to offer.

(then again, much of the conversion is unintelligible anyway, so it's 
not a problem)


> As a sidenote, it's always struck me that it's seems *much* easier to
> lure users away from one music notation package and towards another
>
> Enter, then, the fact that Sibelius has been able to court away so
> many Finale users (hundreds of thousands now, in fact): the beginning
> of each new project is a chance for a user of a notation program to
> leave and try out a new package.

interesting observation, that hadn't occurred to me. However, it's not 
completely true. Publishing houses have huge archives of old files, 
which they would like to access with their current solution. Or so I gather.

> > I think there is a one big problem with going to LilyPond for the
> > majority of SCORE users. Adding a tweak is clumsy, and you have to rerun
> > the program to see the result. Also the result of a tweak is less
> > predictable, as anything besides extra-offset might impact spacing, line
> > breaking, etc.  Also, working with multi-page documents is a nightmare,
> > since page breaks are hard to get right.
>
>
> This is the crucial question, right here -- the question of tweaking.
> (Much less so the question of rerunning the program to see the result,
> imo: you spend a *LOT* of time rerunning things in SCORE ... exactly
> like in Lily, outputting to postscript is a completely separate
> process than editing input ... you call entirely separate DOS
> programs, in fact: SCOR4 to summon and use the editor and SCORLAS to
> set up printing options and actually generate the postscript. So no
> problems there for SCORE users interested in the LilyPond work-cycle.)

ok.

> Anyway, the availability of *absolute* horizontal positioning of each
> "code" on the page in SCORE is a major differentiator, imo, beween
> SCORE and all other notation packages (and, unfortunately, in this
> case Lily is actually in the Finale / Sibelius camp: horizontal
> positioning of items is all relative, rather than absolute). Alignment
> in SCORE is mostly rock-solid: want the start of your cresendo to
> align directly with a notehead, or want an initial tempo indication to
> align exactly with your time signature? Simply give them both the same
> p3 horizontal position value (then picking whether things left- or
> right-align is usually done by toggling some higher number p-value
> between -1, 0, 1.)

It's very hard to write something modular and robust with absolute 
coordinates. For example, x -positions of fingerings are relative to the 
note head. Now this means that the accents move along if the note head 
if is moved (due to collisions, seconds in chords, spacing etc.). With 
absolute positioning, that would be impossible, or you have to make the 
fingering positioning code aware of collisions, chords, spacing, etc.

> Unless I'm misreading (which I very well might be), Lily's code isn't
> set up to afford the caching of the intermediate stages between input
> interpretation and postscript output; if it were then that would open
> up an entire editing stage for Lily users in place of sprinkling
> extra-offsets in the initial input-entry stage!

That's possible to add, but it would be major brainsurgery to get the 
caching there, and then someone has to write meaningful postprocessors. 
It's easier to just add those processors as a new feature.

> the problem is that
> Well, hairpins should acquire a better interface (not just attaching
> to rhythmic positions but also to "typographical" positions, like just
> one side or the other of a barline, for example, or the start or stop
> of entire measures) but that can be run as sponsored work, I'm sure.

Yes, like ties, dynamics are in for a general overhaul. Werner has been 
begging for angled hairpins for a long time.

> But I disagree that Lily can only replace SCORE for single staff
> pieces; why should this be the case? If Lilly's not there yet then
> it's very close. What's actually missing? Possibly ...

> 1. (Horizontal) spacing regions throughout a piece

This is a small feature (probably 100 - 150 euro). Interested parties 
may contact me privately.

> 2. (Vertical) spacing regions throughout a piece (so that the
> forced-distance between piano staves can vary from system-to-system);
> there is the bleeding-edge example in the tips 'n tricks section, but
> it's not end-user-ready

There could a solution similar to the spacing regions could be built, by 
stopping and starting a new alignment object. Of course, you have to 
force a linebreak at the same point, otherwise, you get strange effects.

> 3. Either absolute horizontal positions open to the user (as mentioned
> above) and / or glyph alignment to non-rhythmic points on the staff
> (intial indications should be alignable to left time sig edge, right
> time sig edge, left key sig edge, right key sig edge, etc; hairpin
> start- and stop-points should be alignable to barlines or left text
> edge, right text edge, etc); again, maybe these abilities exist
> already, perhaps by examining position attributes of parent objects in
> attachment, but if so I haven't yet figured it out yet

It is possible, but it has to be done in code: the hairpin can start 
from exactly the left edge of the note head, by spanning it between 
heads, and taking

  hairpin->get_bound(LEFT)->extent (common_parent, X_AXIS)[LEFT]

> 4. Flexibility in the slurring interface (explicity instructions to
> the interpreter to say things like "slur starts notehead center; slur
> starts left notehead edge; slur starts right notehead edge; slur
> starts at stem tip; etc); FAIK those affordances may, again, already
> exist in the current slurring interface somewhere in slur-details

:-)  we used to have an interface like that. I could even bolt it onto 
the existing slur interface, but I'd rather prefer to improve the 
scoring algorithm further, so less tweaks are necessary.  What we have 
now is better than what we used to have, but it still sucks for many cases.

--

Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com