lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lilypond duet writing


From: Urs Liska
Subject: Re: lilypond duet writing
Date: Mon, 24 Apr 2017 10:43:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0


Am 24.04.2017 um 10:35 schrieb David Kastrup:
> Urs Liska <address@hidden> 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.
>

-- 
address@hidden
https://openlilylib.org
http://lilypondblog.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]