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 <jamshar...@qq.com> 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 > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user