[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GLISS] why the hell all this fuss
From: |
David Kastrup |
Subject: |
Re: [GLISS] why the hell all this fuss |
Date: |
Thu, 06 Sep 2012 09:55:45 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) |
Janek Warchoł <address@hidden> writes:
> On Thu, Sep 6, 2012 at 12:15 AM, Reinhold Kainhofer
> <address@hidden> wrote:
>> [1] Note, however, that ANY change, even a very small, subtle change, is a
>> really grave argument for a music publisher against using lilypond.
>> I wrote a huge piece (~95 pages full score, 23 orchestra instruments, choir,
>> etc) a few years ago. I didn't count the hours it took me last month to
>> bring it up to date with the latest lilypond version (I had to visually
>> compare the whole full score and all instruments to make sure that nothing
>> had been lost).
>> At that time, I really, really, really cursed lilypond and its frequent
>> syntax changes.
>
> :(
>
> I think that's Graham's point: syntax changes are bad, so if we have
> to make them (and apparently we still have to), let's do it once and
> for all. Or at most 1-2 times per decade.
> In order for this to make sense, we must be really confident in the
> syntax we are going to label "stable". That's why i think we all need
> a lot of discussions to get a better understanding of both user needs
> and problems in parser (ambiguities etc). In my opinion Lily syntax
> isn't expressive enough, which means that sooner or later we'll have
> to make some changes, which means that we should make them now.
>
> Example: hairpins. There is no convenient way of specifying hairpins
> that don't align with the notes (you have to use spacer rests, which
> is bad for a number of reasons). We need to have a convenient way.
> Adding this will be a syntax change, so let's do it now instead of
> later.
I don't see why you should not be able to do this using music functions.
> Another example: vertical hairpins attached to arpeggios (Elaine Gould
> shows them). I don't think we have a simple way of extending our
> syntax to express them - some basic design principles would have to be
> changed a bit, i suppose. So let's change them now.
I don't see why you should not be able to do this using music functions.
--
David Kastrup