Re: Do we really offer the future?

[Shane Brandes]

Lilypond is not a terribly great tool for composition purposes. Not
that I don't use it for that but when I do the whole piece is already
in my head and I am not usually prone to making large changes in
structure. As  noted previously that tends to be a cumbersome process.
Also somewhat cumbersome is adding agogic marks with any rapidity. But
despite these deficiencies, I would not go to another software unless
it demonstrated a truly superior output coupled with a openly
accessible files format.

Shane

On Tue, Apr 21, 2015 at 11:24 PM, James Harkins <address@hidden> wrote:
> It's a bit of a side topic, but the the thread has touched on
> questions of usability, so I think it's related.
>
> I think there's one command in Finale that demonstrates a major obstacle to
> widespread adoption of LilyPond: Delete Measure Stack. This is an extremely
> common need when editing scores, and raw LilyPond code offers no clean,
> easy way to do it.
>
> LP input is structured horizontally, around voices flowing forward in
> time. Meanwhile, composers think in terms of chunks of time whose
> arrangement is vertical. (I don't intend this to preclude polyphonic
> thinking, but even Bach must have struck a whole bar now and again.)
>
> "So how do I delete bar 47 from this LP score?"
>
> .... Well, first you go to your global variable holding rehearsal marks,
> tempo marks, special barlines and meter and key changes, and tweak the
> number of spacer rests. Then you go into the music expressions for every
> part, one by one, and delete the notes for that bar. Frescobaldi's
> point-and-click can help you with that, but it doesn't automate the process.
>
> "Umm... In Finale, all that takes half a second."
>
> We try to explain this away by saying that LP is an engraving tool,
> not a composition tool, but -- if we're really serious about making LP
> more attractive to the "average" user of notation software, this is
> too glib. People writing music simply don't think of musical
> simultaneity in the same terms that LP does. It *does* take effort to
> adapt one's thinking to LP's way, and we shouldn't try to convince
> ourselves that this isn't off-putting.
>
> I don't see a way, with LP input as currently defined, to handle this
> requirement cleanly. If the LP community were to decide that it's
> important, as a way to attract users, I think it would call for a
> higher-level musical representation that generates LP code. Denemo is a
> step in this direction, though I'm not in a position to evaluate it as I
> haven't used it.
>
> Don't get me wrong -- I think LP's rendering engine is amazing, and for me,
> it *is* worth the effort to shoehorn my music into LP's format if it means
> I can use this fantastic engine. But I can't pretend it isn't any effort,
> either.
>
> hjh
>
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user