Am 24.04.2017 um 10:35 schrieb David Kastrup: > Urs Liska <u...@openlilylib.org> writes: > >> Am 24.04.2017 um 03:35 schrieb Margaret Voorhaar: >>> Hi Hans, >>> Thank-you very much for responding to my first efforts at learning >>> Lilypond. >>> >>> I am going to take advantage of your kindness and submit my next >>> conundrum to you. >>> >>> I have written a flute melody which is is complete at 32 bars in >>> length. Is it too late to integrate a second flute part beneath >>> this? >> No, not at all. It is one of the beauties of text-based work that you >> will very rarely run into such a situation. While in a graphical >> program adding something "after the fact" may indeed break things, in >> a text based program the whole text is considered newly upon each >> compilation. > Well, "considered new" is not the fundamental difference: a graphical > program will consider its input "new" on each load. Graphical programs > offer a number of transformations you can do to your project and any > work you need to do have to be matched to what the program can do. > > With a text-based program, you have access to the "meat" of the matter > independently. If there is no sensible _structural_ transformation you > can do to your project, you can still strip all the meat (the notes) off > the bones of an existing project and put them on a different skeleton. > So if you want to have a giraffe and all you have is an elephant, you > just need a giraffe skeleton (which is comparably lightweight) and you > can hang all the elephant meat off that skeleton and are finished. > Don't ask me what to do the with the trunk, though. > > So the bulk of work you already invested rarely goes to waste. The > downside, of course, is that it is easy to create invalid input, > something that graphical programs usually only do due to bugs. But > recovery is often straightforward, and you can continue working on your > material even while it is in invalid state and you are waiting for help > to fix that.
This is even true when it's not invalid *input*. You may want to read the last section of this blog post (http://lilypondblog.org/2014/10/segmented-workflows/) describing how a team could continue working on a big score while we were suffering from a LilyPond bug that prevented the score from being properly compiled at all. Urs > > Like the help from Urs. > -- u...@openlilylib.org https://openlilylib.org http://lilypondblog.org _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
