[Top][All Lists]

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

Re: Add commands (issue 150670043 by address@hidden)

From: Urs Liska
Subject: Re: Add commands (issue 150670043 by address@hidden)
Date: Thu, 09 Oct 2014 11:38:48 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

Am 09.10.2014 11:27, schrieb David Kastrup:
Urs Liska <address@hidden> writes:

Am 09.10.2014 10:44, schrieb David Kastrup:
Urs Liska <address@hidden> writes:

And I would really love to see that being part of LilyPond itself and
not only possible to implement in a library.
Firstly because I would like *all* LilyPond users to have that
available and secondly because I would like to add this as a Layout
Control Option to Frescobaldi.
When those goals conflict with placing specific functionality in a
library, we have an infrastructure problem.  We won't solve that problem
by cramming everything into the core, not least of all because such
specific solutions cannot really reliably be turned into a
one-size-fits-all approach.

So it is important _not_ to have shrinkwrapped functionality for a
particular purpose _forced_ onto users but have it loadable on demand.
And be able to offer choice between one or several different solutions
as well as rolling your own.

My approach *is* loadable on demand (just as the guitar fretboards).
What *could* make sense in my opinion is instead of adding "secondary"
files to the /ly directory adding them to a separate directory which
could contain such add-ons. Is there anything that makes my suggestion
less general than, say, the mentioned guitar fretboards?
Yes.  The guitar fretboards concern a whole family of instruments
literally millions of people play.

Your extension makes only very limited sense for scores reproducing the
"original breaks" of a single canonical original document.  That's a
rather specific situation.

Now I start to see your misunderstanding.

  If the breaks in _one_ version of a score
are so important, why is that the _only_ conceivable version of the
score with relevant breaks?

Where did I say that such a version is the only conceivable version of the score?

And if that is the only conceivable
version, why would we put the breaks in conditionally?

Because one wouldn't want to *finally* produce a version of the score with the breaks of the original score. If that's my interest (which then would actually be a "rather specific situation") I can simply use hardcoded \break commands.

The whole point of these conditional commands is to have a tool (maybe you can call it an editing mode) to match LilyPond's output with the *one* version of the score I'm copying from, that is the one I have on my desktop in front of me.

And such a tool would (positively) affect a whole family of music engravers, namely those who are engraving music from an existing copy. I think the ratio between these and music engravers who don't do this is significantly closer to 50:50 than the ration between engravers writing music for fretboard instruments and those who don't.

  If they are
disabled, we could be producing _another_ document with breaks that
nobody should ever want to reproduce.

If they are disabled (after music entry and proof-reading has been completed) we will produce a document that benefits from LilyPond's quality.

reply via email to

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