Problems with `\repeat percent'

[Werner LEMBERG]

[445bf3bb2fbd1f259fe43ade204fb34d68bdd581]


Folks,


have a look at NR section `Percent Repeats', `Known Issues and
Warnings'.  There is code like

  \relative c'' {
\repeat percent 3 { \time 5/4 c2. 2 \time 4/4 2 2 }
  }

which generates the attached image.  The generation of a second staff
can't be right...  A bug?

Additionally, the `improved' version

  \relative c''
<<
  \repeat percent 3 { c2. 2 2 2 }
  \repeat unfold 3 { \time 5/4 s4*5 \time 4/4 s1 }
>>

also generates an empty staff, which looks definitely wrong to me.

BTW, both snippets generate

  programming error:
No spacing entry from DoublePercentRepeat to `right-edge'

warnings.


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

Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300280043 by truer...@gmail.com)

[Carl Sorensen]

On 7/22/16 12:35 PM, "James"  wrote:

>
>jlowe@jloweDesktop ~/lilypond-git/build/input $  du -smh * | sort -hr
>1.9Gregression
>8.0Kout-www
>8.0Kout
>4.0KGNUmakefile

Do we turn off point and click when doing the doc builds?

Carl


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

Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300280043 by truer...@gmail.com)

[David Kastrup]

James  writes:

> NB> It seems that the Japanese docs are built using its own 'build'
> dir (i.e. it has its own out-www build doc and doesn't seem to share
> any of the files the other docs do while building, but I am probably
> not understanding this).
>
> Are we wasting build time and space with the way we build the Japanese
> docs compared to the other languages?
>
> Anyway...
>
> jlowe@jloweDesktop ~/lilypond-git/build $  du -smh * | sort -hr
> 1.9Ginput
> 1.4GDocumentation
> 773Mout
> 592Mout-www
> 171Mlily
> 9.5Mmf
> 7.5Mflower
> 1.2Mpo
> ..
>
> jlowe@jloweDesktop ~/lilypond-git/build/Documentation $  du -smh * |
> sort -hr
> 425Mout-www /<--- English Docs/
> 341Mja /< why is this so big compared to the other language
> docs?/

Because if thousands of snippets include a Japanese font over and over
again rather than include some Western font over and over again, the
total size is quite larger.

-- 
David Kastrup

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

Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300280043 by truer...@gmail.com)

[James]

hello,


On 22/07/16 18:48, Carl Sorensen wrote:


On 7/22/16 9:35 AM, "lilypond-devel on behalf of David Kastrup"
 wrote:


A 30% reduction in the final output file size sounds nice.  Personally,
I find the prospect of not having 4GB of disk usage for running
lilypond-patchy-staging quite more compelling, and I would seriously
suspect that all the amount of font juggling and merging subsetted fonts
will not just take quite a bit of disk space but also of processing
time.  So if we could successfully pull this off and have it work
reliably for lilypond-book, I consider it likely to end up as a real
boon in resource usage.

I expect this to be a real boon as well.

However, without doing a careful study, I expect that the 4GB of disk
space used for running lilypond-patchy-staging largely related to the
large number of snippet files, each of which rather inefficiently uses
disk allocation units.  So I'm not sure I see a huge reduction in this
overall disk usage for running patchy.

But this is just a hunch, not a demonstrated reality.


After my last Patchy run (just now) I get this (ive edited so just the 
largest dirs in each case are shown):


NB> It seems that the Japanese docs are built using its own 'build' dir 
(i.e. it has its own out-www build doc and doesn't seem to share any of 
the files the other docs do while building, but I am probably not 
understanding this).


Are we wasting build time and space with the way we build the Japanese 
docs compared to the other languages?


Anyway...

jlowe@jloweDesktop ~/lilypond-git/build $  du -smh * | sort -hr
1.9Ginput
1.4GDocumentation
773Mout
592Mout-www
171Mlily
9.5Mmf
7.5Mflower
1.2Mpo
..

jlowe@jloweDesktop ~/lilypond-git/build/Documentation $  du -smh * | 
sort -hr

425Mout-www /<--- English Docs/
341Mja /< why is this so big compared to the other language docs?/
233Mde
133Mes
90Mit
89Mfr
39Mca
21Mhu
20Mout
17Mcs
13Mnl
8.3Mpictures
3.6Mly-examples
1.8Mpo
1.7Msnippets

...

jlowe@jloweDesktop ~/lilypond-git/build/Documentation/out-www $  du -smh 
* | sort -hr

50Mnotation
36Mnotation.pdf
36Mnotation.it.pdf
36Mnotation.fr.pdf
36Mnotation.es.pdf
34Mnotation.de.pdf
25Mlearning
18Minternals
15Mmusic-glossary
11Msnippets.pdf
9.3Mweb
7.7Musage
6.7Mcontributor
5.3Msnippets
5.3Mlearning.pdf
5.3Mlearning.fr.pdf
5.3Mlearning.es.pdf
5.3Mlearning.de.pdf
5.2Mlearning.it.pdf
4.9Mlearning.ca.pdf
4.7Mlearning.nl.pdf
4.1Mnotation-big-page.fr.html
4.1Mnotation-big-page.es.html
4.0Mnotation-big-page.ja.html
4.0Mnotation-big-page.it.html
3.9Mnotation-big-page.de.html
3.8Mnotation-big-page.html

jlowe@jloweDesktop ~/lilypond-git/build/input $  du -smh * | sort -hr
1.9Gregression
8.0Kout-www
8.0Kout
4.0KGNUmakefile

jlowe@jloweDesktop ~/lilypond-git/build/input/regression $  du -smh * | 
sort -hr

705Mout-test-baseline
705Mout-test
238Mout-www
155Mmusicxml
44Mmidi
32Mabc2ly
20Mlilypond-book
468Kcollated-files.texi2pdf.log


jlowe@jloweDesktop ~/lilypond-git/build/Documentation/ja $  du -smh * | 
sort -hr

512Mout-www
8.0Kout
8.0Knotation.splittexi.log
8.0Knotation.bigtexi.log

...

jlowe@jloweDesktop ~/lilypond-git/build/Documentation/ja/out-www $ du 
-smh * | sort -hr

70M34
52M37
38Mef
38M3c
33Mbf
21Mf1
20M8b
20M4e
19M9a
9.6Mnotation
 

James




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

Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300280043 by truer...@gmail.com)

[Carl Sorensen]

On 7/22/16 9:35 AM, "lilypond-devel on behalf of David Kastrup"
 wrote:

>
>A 30% reduction in the final output file size sounds nice.  Personally,
>I find the prospect of not having 4GB of disk usage for running
>lilypond-patchy-staging quite more compelling, and I would seriously
>suspect that all the amount of font juggling and merging subsetted fonts
>will not just take quite a bit of disk space but also of processing
>time.  So if we could successfully pull this off and have it work
>reliably for lilypond-book, I consider it likely to end up as a real
>boon in resource usage.

I expect this to be a real boon as well.

However, without doing a careful study, I expect that the 4GB of disk
space used for running lilypond-patchy-staging largely related to the
large number of snippet files, each of which rather inefficiently uses
disk allocation units.  So I'm not sure I see a huge reduction in this
overall disk usage for running patchy.

But this is just a hunch, not a demonstrated reality.

Thanks,

Carl


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

Re: ps2pdf issues

[Masamichi Hosoda]

>> For remote PDF links, rather than they are lost, I think that PDF
>> destination names are replaced.
> 
> Hmm.  This smells fishy.
> 
>> Would you know a tool other than texinfo that can generate remote
>> PDF links?
> 
> Sorry, no.

I've noticed that
plain pdfTeX (without texinfo) can generate PDF destination names
and web browsers can jump to them.

If I understand correctly,
Ghostscript seems to discard PDF destination names.

I've reported to Ghostscript Bugzilla.
http://bugs.ghostscript.com/show_bug.cgi?id=696943

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

Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300280043 by truer...@gmail.com)

[Werner LEMBERG]

>> Comparing the `--bigpdfs' method with the fontless PDF approach as
>> outlined above, the latter creates a final output file about 30%
>> smaller (at least in my small test).
> 
> A 30% reduction in the final output file size sounds nice.

This is an *additional* 30%, since `--bigpdfs' already makes the
final output file much smaller.

> Personally, I find the prospect of not having 4GB of disk usage for
> running lilypond-patchy-staging quite more compelling, and I would
> seriously suspect that all the amount of font juggling and merging
> subsetted fonts will not just take quite a bit of disk space but
> also of processing time.  So if we could successfully pull this off
> and have it work reliably for lilypond-book, I consider it likely to
> end up as a real boon in resource usage.

Me too.  The writing of font resources shouldn't be too difficult to
implement, at least for persons who are fluent with Scheme...


Werner

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

Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300280043 by truer...@gmail.com)

[David Kastrup]

Werner LEMBERG  writes:

> About a month ago we discussed how to reduce the disk space necessary
> for builing the lilypond documentation.
>
>> [...]  Since lilypond itself converts all fonts to PostScript
>> resources, why not writing those resources to a `fontresource'
>> directory instead of embedding?  We could add a checksum to the
>> resource name, just to be sure that, say, `foo.tff' and `foo.otf'
>> will be rejected.
>> 
>> Ideally, all intermediate PDFs also refer to this `fontresource'
>> directory, and only in the last step PDFs with subsetted, embedded
>> fonts are created.
>
> Such an approach has now been discussed on the the pdftex mailing
> list, cf.
>
>   http://tug.org/pipermail/pdftex/2016-July/009045.html
>
> and the following e-mails in this thread.
>
> I've just tested successfully the following method, except item 1,
> which I've executed manually.
>
> 1. Instead of embedding font resources into the file, lilypond writes
>them to a font resource directory and uses the `.loadfont' operator
>in its PS output file.  For simplicity, the font resources should
>have the PS font name as its file name (regardless of the font
>format), e.g. `TeXGyraSchola-Regular'; we then don't need a font
>map for ghostscript.
>
> 2. Lilypond's PS files are converted to PDFs with the additional gs
>option `-dEmbedAllFonts=false' (to be added to `postscript->PDF' in
>file `backend-library.scm').
>
> 3. Both xetex and pdftex accept the fontless PDFs without complaints;
>they simply embed them into its output file without alterations,
>AFAICS.
>
> 4. After the output PDF is built, a call to
>
>  ps2pdf -I \
> -dNOSAFER -P \
> Fontless.pdf WithEmbeddedFonts.pdf
>
>creates the final document.
>
> Comparing the `--bigpdfs' method with the fontless PDF approach as
> outlined above, the latter creates a final output file about 30%
> smaller (at least in my small test).

A 30% reduction in the final output file size sounds nice.  Personally,
I find the prospect of not having 4GB of disk usage for running
lilypond-patchy-staging quite more compelling, and I would seriously
suspect that all the amount of font juggling and merging subsetted fonts
will not just take quite a bit of disk space but also of processing
time.  So if we could successfully pull this off and have it work
reliably for lilypond-book, I consider it likely to end up as a real
boon in resource usage.

-- 
David Kastrup

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

Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300280043 by truer...@gmail.com)

[Werner LEMBERG]

>  ps2pdf -I \
> -dNOSAFER -P \
> Fontless.pdf WithEmbeddedFonts.pdf

This should rather be

  ps2pdf -I \
  -dNOSAFER \
  Fontless.pdf WithEmbeddedFonts.pdf

I've tested with the fonts in the current directory, thus `-P'.


Werner

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

Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300280043 by truer...@gmail.com)

[Werner LEMBERG]

About a month ago we discussed how to reduce the disk space necessary
for builing the lilypond documentation.

> [...]  Since lilypond itself converts all fonts to PostScript
> resources, why not writing those resources to a `fontresource'
> directory instead of embedding?  We could add a checksum to the
> resource name, just to be sure that, say, `foo.tff' and `foo.otf'
> will be rejected.
> 
> Ideally, all intermediate PDFs also refer to this `fontresource'
> directory, and only in the last step PDFs with subsetted, embedded
> fonts are created.

Such an approach has now been discussed on the the pdftex mailing
list, cf.

  http://tug.org/pipermail/pdftex/2016-July/009045.html

and the following e-mails in this thread.

I've just tested successfully the following method, except item 1,
which I've executed manually.

1. Instead of embedding font resources into the file, lilypond writes
   them to a font resource directory and uses the `.loadfont' operator
   in its PS output file.  For simplicity, the font resources should
   have the PS font name as its file name (regardless of the font
   format), e.g. `TeXGyraSchola-Regular'; we then don't need a font
   map for ghostscript.

2. Lilypond's PS files are converted to PDFs with the additional gs
   option `-dEmbedAllFonts=false' (to be added to `postscript->PDF' in
   file `backend-library.scm').

3. Both xetex and pdftex accept the fontless PDFs without complaints;
   they simply embed them into its output file without alterations,
   AFAICS.

4. After the output PDF is built, a call to

 ps2pdf -I \
-dNOSAFER -P \
Fontless.pdf WithEmbeddedFonts.pdf

   creates the final document.

Comparing the `--bigpdfs' method with the fontless PDF approach as
outlined above, the latter creates a final output file about 30%
smaller (at least in my small test).


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

Patches for issue #4814

[Guido Aulisi]

Hello,
I made 2 patches for issue #4814 and for a FTBFS witch gcc 6 on Fedora 24.
These 2 patches seem to solve that problem for me.

Best regards
Guido Aulisi
From 682f75315e6820220ecf45717664f6d32f480c98 Mon Sep 17 00:00:00 2001
From: Guido Aulisi 
Date: Fri, 22 Jul 2016 15:26:29 +0200
Subject: [PATCH 1/2] Avoid segfault in grob.cc with gcc 6 (see issue #4814)

When optimizing, GCC 6 now assumes the "this" pointer can never be null,
which is guaranteed by the language rules.
Programs which assume it is OK to invoke a member function through a null 
pointer
(possibly relying on checks like this != NULL) may crash or otherwise fail at 
run time
if null pointer checks are optimized away.
---
 lily/grob.cc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lily/grob.cc b/lily/grob.cc
index 7ce89d5..eafa662 100644
--- a/lily/grob.cc
+++ b/lily/grob.cc
@@ -333,7 +333,7 @@ Real
 Grob::relative_coordinate (Grob const *refp, Axis a) const
 {
   /* eaa - hmmm, should we do a programming_error() here? */
-  if ((this == NULL) || (refp == this))
+  if (refp == this)
 return 0.0;
 
   /* We catch PARENT_L_ == nil case with this, but we crash if we did
@@ -342,7 +342,8 @@ Grob::relative_coordinate (Grob const *refp, Axis a) const
   if (refp == dim_cache_[a].parent_)
 return off;
 
-  off += dim_cache_[a].parent_->relative_coordinate (refp, a);
+  if (dim_cache_[a].parent_ != NULL)
+off += dim_cache_[a].parent_->relative_coordinate (refp, a);
 
   return off;
 }
-- 
2.7.4

From 54aef120afc3857fe07971ce0a62cb21426890d0 Mon Sep 17 00:00:00 2001
From: Guido Aulisi 
Date: Fri, 22 Jul 2016 15:32:46 +0200
Subject: [PATCH 2/2] Fix FTBFS with GCC 6.

GCC 6 now defaults to -std=gnu++14 instead of -std=gnu++98.
Since C++11, the constexpr keyword is needed when initializing
a non-integral static data member in a class.
---
 lily/audio-item.cc | 6 +++---
 lily/include/audio-item.hh | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/lily/audio-item.cc b/lily/audio-item.cc
index 2c5d691..c5b1f87 100644
--- a/lily/audio-item.cc
+++ b/lily/audio-item.cc
@@ -102,9 +102,9 @@ Audio_key::Audio_key (int acc, bool major)
   major_ = major;
 }
 
-const Real Audio_span_dynamic::MINIMUM_VOLUME;
-const Real Audio_span_dynamic::MAXIMUM_VOLUME;
-const Real Audio_span_dynamic::DEFAULT_VOLUME;
+constexpr Real Audio_span_dynamic::MINIMUM_VOLUME;
+constexpr Real Audio_span_dynamic::MAXIMUM_VOLUME;
+constexpr Real Audio_span_dynamic::DEFAULT_VOLUME;
 
 Audio_span_dynamic::Audio_span_dynamic (Moment mom, Real volume)
   : start_moment_ (mom),
diff --git a/lily/include/audio-item.hh b/lily/include/audio-item.hh
index 597fa6a..9a2eea0 100644
--- a/lily/include/audio-item.hh
+++ b/lily/include/audio-item.hh
@@ -48,9 +48,9 @@ private:
 class Audio_span_dynamic : public Audio_element
 {
 public:
-  static const Real MINIMUM_VOLUME = 0.0;
-  static const Real MAXIMUM_VOLUME = 1.0;
-  static const Real DEFAULT_VOLUME = 90.0 / 127.0;
+  static constexpr Real MINIMUM_VOLUME = 0.0;
+  static constexpr Real MAXIMUM_VOLUME = 1.0;
+  static constexpr Real DEFAULT_VOLUME = 90.0 / 127.0;
 
 private:
   Moment start_moment_;
-- 
2.7.4

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

Re: Optional fraction after \afterGrace command (issue 304200043 by d...@gnu.org)

[mark . opus11]

On 2016/07/22 07:55:54, dak wrote:

On 2016/07/22 07:41:00, http://mark_opus11.net wrote:
> On 2016/07/22 04:26:01, lemzwerg wrote:
> > LGMT. Thanks a lot!
>
> Might it be a good idea to keep one example using the old define

method, which

> is still more convenient for setting the value for multiple usages

of

> \afterGrace (or globally)?



Frankly, I decided against doing so since redefining parser behavior

by

resetting a global variable controlling its behavior in the middle of

a music

expression is a complete abomination.  This is different to how

\tupletSpan (or

its equivalent \override) works since \tupletSpan becomes a _part_ of

the music

expression.


I appreciate that reasoning, however the ability to set global behaviour
is one
of lilypond's major strengths - if overriding a default has to be
entered at every
usage of \afterGrace then we are back to making changes with sed
scripts.

The default value of 3/4 is almost always not appropriate, and I
regularly set this globally after entering the music to find a suitable
value.

Perhaps afterGraceFraction could be somehow included in graceSettings or
some other property of the Voice context?

https://codereview.appspot.com/304200043/

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

Re: Optional fraction after \afterGrace command (issue 304200043 by d...@gnu.org)

[dak]

Reviewers: lemzwerg, mark_opus11.net,

Message:
On 2016/07/22 07:41:00, mark_opus11.net wrote:

On 2016/07/22 04:26:01, lemzwerg wrote:
> LGMT. Thanks a lot!



Might it be a good idea to keep one example using the old define

method, which

is still more convenient for setting the value for multiple usages of
\afterGrace (or globally)?


Frankly, I decided against doing so since redefining parser behavior by
resetting a global variable controlling its behavior in the middle of a
music expression is a complete abomination.  This is different to how
\tupletSpan (or its equivalent \override) works since \tupletSpan
becomes a _part_ of the music expression.

That's not really something we want to paint as a user interface.  It's
also impossible to reflect with \displayLilyMusic.

I actually asked myself the question "might it be a good idea to keep
one example using the old define method" and my personal answer to that
question ended up being "no".  If anything, i was rather tempted
undocumenting it completely but then the arbitrary default value of 3/4
needed to get mentioned so that one would be able to understand how
custom values were related.  And I decided that just mentioning where
this default was stored would provide a comparatively small opening in
the can of worms.

So this was a conscious decision on my part and I'll require some
convincing to revert.

Description:
Optional fraction after \afterGrace command

\afterGrace had its fraction determining the position of the aftergrace
notes hardwired to be read from the parser variable afterGraceFraction.
This change here allows for optionally specifying it right as the first
argument of the \afterGrace command.


Also contains commit:

NR: show optional \afterGrace argument

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

Affected files (+21, -16 lines):
  M Documentation/notation/rhythms.itely
  M ly/music-functions-init.ly


Index: Documentation/notation/rhythms.itely
diff --git a/Documentation/notation/rhythms.itely  
b/Documentation/notation/rhythms.itely
index  
d3263d4f6a43f93d6e6c50e1f78868aa80bb13e0..c08e4da361f9d9517a49a5e25a8183398f667064  
100644

--- a/Documentation/notation/rhythms.itely
+++ b/Documentation/notation/rhythms.itely
@@ -3433,10 +3433,14 @@ notes following the main note.
 @end lilypond

 This will put the grace notes after a space lasting 3/4 of the
-length of the main note.  The default fraction 3/4 can be changed by
-setting @code{afterGraceFraction}.  The following example shows
-the results from setting the space at the default,  at 15/16, and
-finally at 1/2 of the main note.
+length of the main note.  The default fraction of @code{3/4} is
+stored in the parser variable @code{afterGraceFraction}.
+Fractions differing from the default can be specified right after
+the @code{\afterGrace} command.
+
+The following example shows the results from setting with the
+default space, setting it at @code{15/16}, and finally at
+@code{1/2} of the main note.

 @lilypond[quote,verbatim]
 <<
@@ -3444,12 +3448,10 @@ finally at 1/2 of the main note.
 c''1 \afterGrace d1 { c16[ d] } c1
   }
   \new Staff \relative {
-#(define afterGraceFraction (cons 15 16))
-c''1 \afterGrace d1 { c16[ d] } c1
+c''1 \afterGrace 15/16 d1 { c16[ d] } c1
   }
   \new Staff \relative {
-#(define afterGraceFraction (cons 1 2))
-c''1 \afterGrace d1 { c16[ d] } c1
+c''1 \afterGrace 1/2 d1 { c16[ d] } c1
   }
 >>
 @end lilypond
Index: ly/music-functions-init.ly
diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index  
f4f50fafef22fb7248b2612cb6066139fbaaa62c..37f76bbe1f8c6e19bb57a8c7ff7f4cd34ef872dd  
100644

--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -56,12 +56,17 @@ addQuote =
(add-quotable name music))

 %% keep these two together
-afterGraceFraction = #(cons 6 8)
+afterGraceFraction = 6/8
 afterGrace =
-#(define-music-function (main grace) (ly:music? ly:music?)
-   (_i "Create @var{grace} note(s) after a @var{main} music expression.")
+#(define-music-function (fraction main grace) ((fraction?) ly:music?  
ly:music?)

+   (_i "Create @var{grace} note(s) after a @var{main} music expression.
+
+The musical position of the grace expression is after a
+given fraction of the main note's duration has passed.  If
+@var{fraction} is not specified as first argument, it is taken from
+@code{afterGraceFraction} which has a default value of @code{6/8}.")
(let ((main-length (ly:music-length main))
- (fraction  (ly:parser-lookup 'afterGraceFraction)))
+ (fraction (or fraction (ly:parser-lookup 'afterGraceFraction
  (make-simultaneous-music
   (list
main
@@ -71,10 +76,8 @@ afterGrace =
  (make-music 'SkipMusic
  'duration (ly:make-duration
 0 0
-(* (ly:moment-main-numerator main-length)
-   (car fraction))
- 

Re: Optional fraction after \afterGrace command (issue 304200043 by d...@gnu.org)

[mark . opus11]

On 2016/07/22 04:26:01, lemzwerg wrote:

LGMT. Thanks a lot!


Might it be a good idea to keep one example using the old define method,
which is still more convenient for setting the value for multiple usages
of \afterGrace (or globally)?

https://codereview.appspot.com/304200043/

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

Re: 4919: beam 1/20 and shorter notes by 1/4 in 2/2 and 3/2 time (issue 303980043 by simon.albre...@mail.de)

[dak]

https://codereview.appspot.com/303980043/diff/20001/scm/time-signature-settings.scm
File scm/time-signature-settings.scm (right):

https://codereview.appspot.com/303980043/diff/20001/scm/time-signature-settings.scm#newcode73
scm/time-signature-settings.scm:73: ((beamExceptions . ((end . ((1/20 .
(5 5 5 5
Well, the other exceptions tend to draw the line differently (see 6/4,
9/4, 12/4, and the somewhat different 3/4 and 4/4 resume beat-beaming at
triplets rather than smaller).  One problem with quintuplets are that
they are
indistinguishable from decemtuplets in the exception rules.

Take for example

\score {
  \fixed c'
  {
\time 2/2
\tuplet 10/8 2 { c16 d e g f d g f e d
 c g e d f e g f d e }
c1
  }

  \layout {}
  \midi { \tempo 2 = 60 }
}

under old and proposed rules.  So I think that when changing the
autobeaming rules, we should try to keep LilyPond's defaults somewhat
consistent and predictable and not arbitrarily draw the tuplet lines
differently for every meter.

I particularly don't see why quintuplets at 3/2 should be treated
differently than at 6/4 as compared to triplets.

https://codereview.appspot.com/303980043/

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