Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-09 Thread lilyliska 


https://codereview.appspot.com/150670043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):

https://codereview.appspot.com/150670043/diff/1/Documentation/notation/spacing.itely#newcode1857
Documentation/notation/spacing.itely:1857: @end lilypond
On 2014/10/08 05:01:40, Keith wrote:

Why not store the common music in a variable, and show
  \score {\music}
  \discaredOriginalBreaks
  \score {\music}
?


Because it wouldn't work that way. \discardOriginalBreaks
would be interpreted when the command is written. So the
change doesn't have an effect when the variable is called the
second time (but actually it's not the use case to change
the behaviour along the way of a score).

https://codereview.appspot.com/150670043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-09 Thread Urs Liska 


Am 08.10.2014 00:30, schrieb nine.fierce.ball...@gmail.com:

On 2014/10/07 08:37:06, uliska wrote:

On 2014/10/07 08:37:06, uliska wrote:

On 2014/10/07 08:37:06, uliska wrote:

On 2014/10/07 08:37:06, uliska wrote:

Important:
* There should be regression tests.


OK. (but only *if* the patch should  be accepted ...)



Musing:
* Why not use tags?  (Example below.)


Because that requires the command definition to be done locally or in a 
library.

The point of the patch is not to make original breaks *possible* but to make
them *available*.


* Does this implementation make it possible to set the option from the
lilypond command line?


Yes, but not as a command line option but using the -e option defining 
the configuration variable



* When using original breaks, wouldn't one also want original page size,
staff size, etc.?
* What about hundreds of other features of the original edition?


IMO these are different things.
The detailed aspects of an original edition are a matter of a style 
sheet - if you want to mimick them.
What I am talking about is a tool to improve the user experience for 
music entry or proof-reading. It is extremely practical to have 
identical breaks when you have to match the original manuscript and the 
compiled LilyPond output in a score of 100+ pages. But of course you 
don't want to hardcode these breaks and prevent LilyPond from doing its 
own breaking.
So what I want is a way to be able to enter the original manuscript's 
breaks in the input file and switch them on and off.


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.


Urs

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-09 Thread David Kastrup 
Urs Liska u...@openlilylib.org 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.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-09 Thread Urs Liska 


Am 09.10.2014 10:44, schrieb David Kastrup:

Urs Liska u...@openlilylib.org 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?


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-09 Thread David Kastrup 
Urs Liska u...@openlilylib.org writes:

 Am 09.10.2014 10:44, schrieb David Kastrup:
 Urs Liska u...@openlilylib.org 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.  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?  And if that is the only conceivable
version, why would we put the breaks in conditionally?  If they are
disabled, we could be producing _another_ document with breaks that
nobody should ever want to reproduce.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-09 Thread Urs Liska 


Am 09.10.2014 11:27, schrieb David Kastrup:

Urs Liska u...@openlilylib.org writes:


Am 09.10.2014 10:44, schrieb David Kastrup:

Urs Liska u...@openlilylib.org 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.





___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-09 Thread tdanielsmusic 

I've not followed the corresponding email discussion closely, and maybe
I've missed something, but how is this better than simply using \obreak
for an original break, and \nbreak for a new, required, break, having
defined

obreak = \break
nbreak = 

in order to obtain the original breaks.  And then simply redefining

obreak = 
nbreak = \break

to remove the original breaks and activate the new ones?  And
equivalently for page breaks.

This has the advantage that newly inserted breaks don't interfere with
the original ones.

It would also be trivial to remove all these editing aids finally with a
simple global edits.

That seems so simple anyone can do it without adding anything to the
base code and almost a page to the documentation.

Trevor


https://codereview.appspot.com/150670043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-09 Thread Graham Percival 
On Thu, Oct 09, 2014 at 10:21:45AM +, tdanielsmu...@googlemail.com wrote:
 I've not followed the corresponding email discussion closely, and maybe
 I've missed something, but how is this better than simply using \obreak
 for an original break, and \nbreak for a new, required, break, having
 defined
 
 obreak = \break
 nbreak = 
...
 That seems so simple anyone can do it without adding anything to the
 base code and almost a page to the documentation.

This method is already in the documentation!  At least, it used to
be... Learning Manual, tips for typesetting or something like
that?  it's just possible it was moved to Notation or Usage at
some point.  But it was definitely in the docs ten years ago.
(yes, literally 10 years ago.  Mao, where did the time go?)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-09 Thread dak 

On 2014/10/09 10:21:45, Trevor Daniels wrote:


It would also be trivial to remove all these editing aids finally with

a simple

global edits.


I think the basic point was to get different aspects of the same
document _without_ doing any edits on it.

https://codereview.appspot.com/150670043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-09 Thread Federico Bruni 
2014-10-09 12:41 GMT+02:00 Graham Percival gra...@percival-music.ca:

 On Thu, Oct 09, 2014 at 10:21:45AM +, tdanielsmu...@googlemail.com
 wrote:
  I've not followed the corresponding email discussion closely, and maybe
  I've missed something, but how is this better than simply using \obreak
  for an original break, and \nbreak for a new, required, break, having
  defined
 
  obreak = \break
  nbreak = 
 ...
  That seems so simple anyone can do it without adding anything to the
  base code and almost a page to the documentation.

 This method is already in the documentation!  At least, it used to
 be... Learning Manual, tips for typesetting or something like
 that?  it's just possible it was moved to Notation or Usage at
 some point.  But it was definitely in the docs ten years ago.
 (yes, literally 10 years ago.  Mao, where did the time go?)


It's actually in Usage:
http://lilypond.org/doc/v2.19/Documentation/usage/typesetting-existing-music

But it's not enough, you should also use the information provided here:
http://lilypond.org/doc/v2.19/Documentation/notation/explicit-breaks

```
There are cases when manual \break or \pageBreak commands are ignored by
LilyPond. There are two commands to override this behavior:

\override NonMusicalPaperColumn.line-break-permission = ##f
\override NonMusicalPaperColumn.page-break-permission = ##f
```
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-09 Thread Federico Bruni 
2014-10-09 11:38 GMT+02:00 Urs Liska u...@openlilylib.org:

 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.


Urs, I like a lot the idea but a simple example would help to understand
the benefits of this patch. I'm currently using \mbreak and two overrides
in a \layout that I can easily comment.

I'm having problems with commenting on Rietveld through browser atm.. I
think that this part is not clear:

 1800 While copying or proof-reading music from existing manuscripts
 1801 it is useful to have the compiled scores respect the line
 1802 and page breaking of the manuscript source.  LilyPond provides
 1803 the commands @code{\origBreak} and @code{\origLineBreak} that
 1804 conditionally create line and page breaks.  They are enabled with


\origBreak refers to page break? Then call it \origPageBreak.. or at least
keep the symmetry in your sentence, i.e. create page and line breaks.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-09 Thread k-ohara5a5a 

On 2014/10/09 08:11:29, uliska wrote:

On 2014/10/08 05:01:40, Keith wrote:
 Why not store the common music in a variable, and show
  \score {\music}
  \discaredOriginalBreaks
  \score {\music}
 ?



Because it wouldn't work that way. \discardOriginalBreaks
would be interpreted when the command is written.


Oh.  I see how it works now.


https://codereview.appspot.com/150670043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):

https://codereview.appspot.com/150670043/diff/1/Documentation/notation/spacing.itely#newcode1842
Documentation/notation/spacing.itely:1842: \discardOriginalBreaks
In that case you could do everything you describe in this documentation
by typing
  origBreak = {} %\break
here instead of \discardOriginalBreaks, and then we don't need the
include file.

Do you plan to add a command-line option like -doriginal-breaks so you
can switch behaviors from the command line?

https://codereview.appspot.com/150670043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-07 Thread lilyliska 

Reviewers: ,

Description:
Add original-breaks.ly commands

The commands defined in this patch allow the user to insert breaks
(line and page) from the original manuscript that are conditionally
respected or discarded. This is very useful for entering and
proof-reading music from larger scores.

Actually I would prefer having them enabled automatically (i.e.
parsed on initialisation without requiring to include the file
explicitly. But I think the way it is done in the patch will make
it easier to accept its inclusion.

Two commits:

Add docs for original-breaks.ly

Add original-breaks.ly

Define commands:
- origBreak
- origPageBreak

Depending on the presence and state of variables
- keep-original-breaks
- keep-original-page-breaks

these result in a \break or \pageBreak or nothing.
Default is #t (so when the file is included original
breaks are automatically respected).

Additionally define top-level commands
- \keepOriginalBreaks
- \discardOriginalBreaks
- \keepOriginalPageBreaks
- \discardOriginalPageBreaks

The idea is to let the user enter breaks from the manuscript
she is copying. While working on the content of the score
it is very handy to have LilyPond compile the score with
the breaks of the original manuscript, but of course one
doesn't want to enter hard-coded breaks.

Please review this at https://codereview.appspot.com/150670043/

Affected files (+148, -0 lines):
  M Documentation/notation/spacing.itely
  A ly/original-breaks.ly



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-07 Thread nine . fierce . ballads 

On 2014/10/07 08:37:06, uliska wrote:

On 2014/10/07 08:37:06, uliska wrote:

On 2014/10/07 08:37:06, uliska wrote:

On 2014/10/07 08:37:06, uliska wrote:

Important:
* There should be regression tests.

Musing:
* Why not use tags?  (Example below.)
* Does this implementation make it possible to set the option from the
lilypond command line?
* When using original breaks, wouldn't one also want original page size,
staff size, etc.?
* What about hundreds of other features of the original edition?

\version 2.19.0

originalBreak = { \tag #'originalBreak \break }

music = { c'1 \originalBreak 1 }

\score {
  \new Staff { \music }
}

\score {
  \new Staff { \removeWithTag #'originalBreak \music }
}


https://codereview.appspot.com/150670043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-07 Thread dak 

On 2014/10/07 22:30:53, Dan Eble wrote:


* When using original breaks, wouldn't one also want original page

size, staff

size, etc.?


That would not map well to tags.  Not without additional facilities, I
guess.  Still, I think that tags at least address a large enough problem
space that making them available on the command line makes sense.  And
we can still add a macro like

(define-macro (tagged tags . body)
  `(if (check-against-document-options ,tags) (begin ,@body))

to make the document-level tag specification useful in Scheme-provided
content as well.


https://codereview.appspot.com/150670043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add original-breaks.ly commands (issue 150670043 by lilyli...@googlemail.com)

2014-10-07 Thread k-ohara5a5a 

For this particular task, you should also show the user that he can
define at the top of the input, or in a header file if he uses one,
  originalBreak = \break
and insert before music where we are done with the original breaks,
  originalBreak = {} %\break

That is easy enough to understand, and easy to adapt to other tasks.


https://codereview.appspot.com/150670043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):

https://codereview.appspot.com/150670043/diff/1/Documentation/notation/spacing.itely#newcode1857
Documentation/notation/spacing.itely:1857: @end lilypond
Why not store the common music in a variable, and show
 \score {\music}
 \discaredOriginalBreaks
 \score {\music}
?

https://codereview.appspot.com/150670043/diff/1/ly/original-breaks.ly
File ly/original-breaks.ly (right):

https://codereview.appspot.com/150670043/diff/1/ly/original-breaks.ly#newcode36
ly/original-breaks.ly:36: origBreak =
Almost religiously, LilyPond avoids abbreviation.
Maybe  originalBreak ?

https://codereview.appspot.com/150670043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel