Implement -dtags-to-keep and -dtags-to-remove commandline options (issue 149650043 by d...@gnu.org)
https://codereview.appspot.com/149650043/diff/1/Documentation/usage/running.itely
File Documentation/usage/running.itely (right):
https://codereview.appspot.com/149650043/diff/1/Documentation/usage/running.itely#newcode680
Documentation/usage/running.itely:680: @item @code{tags-to-keep}
What do you think about
@code{keep-with-tag} and @code{remove-with-tag}
to match the corresponding @code{\keepWithTag} and @code{\removeWithTag}
LilyPond commands?
Giving similar functions different names would at least confuse myself
as a user ;-)
https://codereview.appspot.com/149650043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement -dtags-to-keep and -dtags-to-remove commandline options (issue 149650043 by d...@gnu.org)
Reviewers: marc,
Message:
On 2014/10/09 06:36:16, marc wrote:
https://codereview.appspot.com/149650043/diff/1/Documentation/usage/running.itely
File Documentation/usage/running.itely (right):
https://codereview.appspot.com/149650043/diff/1/Documentation/usage/running.itely#newcode680
Documentation/usage/running.itely:680: @item @code{tags-to-keep}
What do you think about
@code{keep-with-tag} and @code{remove-with-tag}
to match the corresponding @code{\keepWithTag} and
@code{\removeWithTag}
LilyPond commands?
Giving similar functions different names would at least confuse myself
as a user
;-)
The reason I picked those names was basically that the list of options
for
lilypond -dhelp
and in the Usage Reference is alphabetically sorted and I had to pick
between separating the options, abandoning the sorting order, or letting
them start in a similar way. So I thought this would likely be the
lesser evil, but of course that is entirely subjective and if we get
enough feedback to be even closely similar to a vote or statistical
relevance, I'll be happy to change the choice.
Description:
Implement -dtags-to-keep and -dtags-to-remove commandline options
Please review this at https://codereview.appspot.com/149650043/
Affected files (+26, -0 lines):
M Documentation/usage/running.itely
M scm/lily.scm
M scm/music-functions.scm
Index: Documentation/usage/running.itely
diff --git a/Documentation/usage/running.itely
b/Documentation/usage/running.itely
index
0bff8f68df9636786d7eed1e0fdf43b83b8e4ea2..2979f66088198811ad01211f9c9d396c8310dfca
100644
--- a/Documentation/usage/running.itely
+++ b/Documentation/usage/running.itely
@@ -677,6 +677,16 @@ size increases in PDF files.
@tab @code{#f}
@tab Use woff font files in SVG backend.
+@item @code{tags-to-keep}
+@tab @code{#f}
+@tab Run @code{\keepWithTag} with the given list of tags on the
+music in every @code{\score}, see @ruser{Using Tags}.
+
+@item @code{tags-to-remove}
+@tab @code{#f}
+@tab Run @code{\removeWithTag} with the given list of tags on the
+music in every @code{\score}, see @ruser{Using Tags}.
+
@item @code{trace-memory-frequency}
@tab @code{#f}
@tab Record Scheme cell usage this many times per second. Dump the
Index: scm/lily.scm
diff --git a/scm/lily.scm b/scm/lily.scm
index
3ba26bc6dc6eece709b3714ec9e300a41311f46b..11dd0386b1cf0ad9c84ceb8fd168415aec7cd0c2
100644
--- a/scm/lily.scm
+++ b/scm/lily.scm
@@ -339,6 +339,12 @@ PDF previews.)
(svg-woff
#f
Use woff font files in SVG backend.)
+(tags-to-keep
+ #f
+ List of tags to keep.)
+(tags-to-remove
+ #f
+ List of tags to remove.)
(trace-memory-frequency
#f
Record Scheme cell usage this many times per
Index: scm/music-functions.scm
diff --git a/scm/music-functions.scm b/scm/music-functions.scm
index
aad473c7f0cf126684c6e5a893fbdc39dea04b18..3b289ea57e907daaaed43b179c8c18d631fa846e
100644
--- a/scm/music-functions.scm
+++ b/scm/music-functions.scm
@@ -1347,6 +1347,16 @@ then revert skipTypesetting.
(define-session-public toplevel-music-functions
(list
+ (lambda (music parser)
+ (let ((tags (ly:get-option 'tags-to-keep)))
+ (if (symbol-list-or-symbol? tags)
+ (music-filter (tags-keep-predicate tags) music)
+ music)))
+ (lambda (music parser)
+ (let ((tags (ly:get-option 'tags-to-remove)))
+ (if (symbol-list-or-symbol? tags)
+ (music-filter (tags-remove-predicate tags) music)
+ music)))
(lambda (music parser) (expand-repeat-chords!
(cons 'rhythmic-event
(ly:parser-lookup
parser '$chord-repeat-events))
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement -dtags-to-keep and -dtags-to-remove commandline options (issue 149650043 by d...@gnu.org)
The patch works as expected. However, it has to be noted that by default (that is, running without the option) *keeps* the tags. When I define a command and encapsulate it in a tag this command is executed unless explicitly switched off with -dtags-to-remove. https://codereview.appspot.com/149650043/ ___ 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)
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)
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: Implement -dtags-to-keep and -dtags-to-remove commandline options (issue 149650043 by d...@gnu.org)
On 2014/10/09 07:45:38, uliska wrote:
The patch works as expected.
However, it has to be noted that by default (that is, running without
the
option) *keeps* the tags.
Sure. So does \keepWithTag #'() \tag hi { c4 4 4 4 } (actually, before
the existence of \tagGroup it didn't).
When I define a command and encapsulate it in a tag
this command is executed unless explicitly switched off with
-dtags-to-remove.
Or unless you use -dtags-to-keep on a different tag. Yes.
You can check the options with (ly:get-option '...) and set them with
(ly:set-option '...) so you have the ability to push in an implicit
\keepWithTag #'score when nothing of other relevance is specified on the
command line.
If that is not good enough, the question is how this could be made
better.
https://codereview.appspot.com/149650043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement -dtags-to-keep and -dtags-to-remove commandline options (issue 149650043 by d...@gnu.org)
Am 09.10.2014 10:27, schrieb d...@gnu.org:
On 2014/10/09 07:45:38, uliska wrote:
The patch works as expected.
However, it has to be noted that by default (that is, running without
the
option) *keeps* the tags.
Sure. So does \keepWithTag #'() \tag hi { c4 4 4 4 } (actually, before
the existence of \tagGroup it didn't).
When I define a command and encapsulate it in a tag
this command is executed unless explicitly switched off with
-dtags-to-remove.
Or unless you use -dtags-to-keep on a different tag. Yes.
You can check the options with (ly:get-option '...) and set them with
(ly:set-option '...) so you have the ability to push in an implicit
\keepWithTag #'score when nothing of other relevance is specified on the
command line.
If that is not good enough, the question is how this could be made
better.
It probably *is* good enough, so my comment wasn't a request for change.
___
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)
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)
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)
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)
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 bylilyli...@googlemail.com)
- Original Message - From: Urs Liska u...@openlilylib.org 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. I'd add my voice to saying that I could see how this would be useful. When transcribing any piece of older music (renaissance in my case) it would be convenient to keep the original line breaks to aid checking, and then get rid of them to produce an appropriate newer version. I'm less sure that having to \include a file is the best way to do it, though. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add original-breaks.ly commands (issue 150670043 bylilyli...@googlemail.com)
Am 09.10.2014 11:48, schrieb Phil Holmes: - Original Message - From: Urs Liska u...@openlilylib.org 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. I'd add my voice to saying that I could see how this would be useful. When transcribing any piece of older music (renaissance in my case) it would be convenient to keep the original line breaks to aid checking, and then get rid of them to produce an appropriate newer version. I'm less sure that having to \include a file is the best way to do it, though. I would prefer having the commands available as built-in commands too. I just created the patch in the way I did it because I thought this would make it easier to get accepted (because it's less intrusive and doesn't add anything to runtime ressources unless needed explicitly). 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)
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)
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)
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: Issue 4154: Compact Chord Symbols Patch (issue 153160043 by d...@gnu.org)
On Wed, 2014-10-08 at 17:41 +, d...@gnu.org wrote: Reviewers: , https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm File scm/chord-ignatzek-names.scm (right): https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm#newcode98 scm/chord-ignatzek-names.scm:98: (vector-ref #(C D E F G A B) (ly:pitch-notename This looks like a bad idea. It does not obey the various chord name languages. It does not use the same callbacks. It is a large duplication of code not connected with the other code and not using the same options, functionality and interfaces. When I saw this (on the lilypond-devel mailing list) I thought this was a comment about the existing code. The code quoted is the existing code, which I haven't changed. My code does not generate any chord names, so it can't obey any chord name languages, it just typesets the elements of the chord name in a more compact fashion. Sorry for not replying earlier, but I did think that my patch had sparked a debate about the quality of the original file, not my patch to it, which is purely concerned with how the markup is created for the chord names as generated by the existing code. Richard Can't you try to integrate this kind of code better with the existing code, both regarding the code that is called as well as the naming conventions and functionality that are available? Description: Issue 4154: Compact Chord Symbols Patch Please review this at https://codereview.appspot.com/153160043/ Affected files (+100, -26 lines): M scm/chord-ignatzek-names.scm M scm/define-context-properties.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown for October 12th 2014
Hello, Here is the current patch countdown list. The next countdown will be on October 12th. You can always view the most current countdown list here: http://code.google.com/p/lilypond/issues/list?q=Patch%3Apush%2Ccountdown%2Creview%2Cnew%2Cwaitingcolspec=Patch%20Owner%20ID%20Summarysort=patch PUSH: David Kastrup: Patch: Eliminate will never be null warnings in smobs.tcc. http://code.google.com/p/lilypond/issues/detail?id=4152 James Lowe: Patch: Doc: Usage 1.2 - Added note about using wildcards http://code.google.com/p/lilypond/issues/detail?id=4147 Valentin Villenave: Add functionality to string numbers http://code.google.com/p/lilypond/issues/detail?id=4139 David Kastrup: tie in TabStaff (using q) displays one of the unisone notes in a chord http://code.google.com/p/lilypond/issues/detail?id=3066 David Kastrup: \lyricsto may turn into a voice-mangling zombie when both parents die at the same time http://code.google.com/p/lilypond/issues/detail?id=2010 David Kastrup: ossia staff doesn't stop at correct horizontal position http://code.google.com/p/lilypond/issues/detail?id=660 David Kastrup: non-synchronized grace note makes voiceOne go stems down http://code.google.com/p/lilypond/issues/detail?id=630 COUNTDOWN: David Kastrup: Patch: Turn Smob_base::print_smob into member functions http://code.google.com/p/lilypond/issues/detail?id=4158 Dan Eble: Patch: Let \time in mid-measure work without warning in some cases http://code.google.com/p/lilypond/issues/detail?id=4127 REVIEW: David Kastrup: Patch: Implement -dtags-to-keep and -dtags-to-remove commandline options http://code.google.com/p/lilypond/issues/detail?id=4160 David Kastrup: Patch: Define Smob constructors. http://code.google.com/p/lilypond/issues/detail?id=4156 Urs Liska: Patch: Add original-breaks.ly commands http://code.google.com/p/lilypond/issues/detail?id=4155 WAITING: Keith OHara: allow bn for B-natural in English http://code.google.com/p/lilypond/issues/detail?id=4076 Urs Liska: Patch: Issue 3916: Add \alternatingTimeSignatures http://code.google.com/p/lilypond/issues/detail?id=3918 Mike Solomon: Patch: Prevents vertical axis groups with empty skylines http://code.google.com/p/lilypond/issues/detail?id=3156 Mike Solomon: Patch: Removes the translate_axis call from axis-group-interface outside-staff positioning. http://code.google.com/p/lilypond/issues/detail?id=3134 David Kastrup: Patch: Implement music functions in Scheme rather than C++ http://code.google.com/p/lilypond/issues/detail?id=2716 Thank you, James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4154: Compact Chord Symbols Patch (issue 153160043 by d...@gnu.org)
On 2014/10/09 11:08:16, richard_rshann.plus.com wrote: On Wed, 2014-10-08 at 17:41 +, mailto:d...@gnu.org wrote: Reviewers: , https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm File scm/chord-ignatzek-names.scm (right): https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm#newcode98 scm/chord-ignatzek-names.scm:98: (vector-ref #(C D E F G A B) (ly:pitch-notename This looks like a bad idea. It does not obey the various chord name languages. It does not use the same callbacks. It is a large duplication of code not connected with the other code and not using the same options, functionality and interfaces. When I saw this (on the lilypond-devel mailing list) I thought this was a comment about the existing code. The code quoted is the existing code, which I haven't changed. It most certainly isn't the existing code. It is not even present anywhere in the same file. You might have copied parts of it into the file from some other file, but even git blame -w -C -C -C does not point to any purported other file as a potential source. https://codereview.appspot.com/153160043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4154: Compact Chord Symbols Patch (issue 153160043 by d...@gnu.org)
On Thu, 2014-10-09 at 11:36 +, d...@gnu.org wrote: On 2014/10/09 11:08:16, richard_rshann.plus.com wrote: On Wed, 2014-10-08 at 17:41 +, mailto:d...@gnu.org wrote: Reviewers: , https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm File scm/chord-ignatzek-names.scm (right): https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm#newcode98 scm/chord-ignatzek-names.scm:98: (vector-ref #(C D E F G A B) (ly:pitch-notename This looks like a bad idea. It does not obey the various chord name languages. It does not use the same callbacks. It is a large duplication of code not connected with the other code and not using the same options, functionality and interfaces. When I saw this (on the lilypond-devel mailing list) I thought this was a comment about the existing code. The code quoted is the existing code, which I haven't changed. It most certainly isn't the existing code. Well, that depends what I meant by the existing code - the specific file I was modifying calls chordRootNamer which is initialized to note-name-markup which is in chord-names.scm:62, and that is where the quoted construct exists in the current lilypond code, in fact I see it is repeated several times in that file. Richard ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Roman numerals may be used for page numbers too (issue 151230044 by v.villen...@gmail.com)
Greetings, having pushed the recent string-number-styles patch, I thought another area where we might benefit from roman numerals would be page numbers. This is an attempt at getting there. https://codereview.appspot.com/151230044/ ___ 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 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 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)
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
