Re: Horizontal alingment of lyrics hyphens?
Hi Simon! I use the following in my standard style sheet: \override LyricExtender.whiteout-style = #'outline I recommend to use whiteout-box here as it will translate to much smaller ps/pdf code and should give identical results. \override LyricHyphen.whiteout-style = #'outline \override LyricHyphen.whiteout = 1.4 whiteout-box obviously isn't an option here. But I prefer higher values for LyricHyphen.whiteout, and stencil-whitout-outline is broken if whiteout is big compared to the height of the object, see attached file WhiteoutOrig.jpg where the whiteout areas are marked red. There is an easy fix for the problem: Increase angle-increments and radial-increments in scm/stencil.scm. For a higher LyricHyphen.whiteout of 4 I recommend the following changes: Original: (define*-public (stencil-whiteout-outline stil #:optional (thickness 0.3) (color white) (angle-increments 16) (radial-increments 1)) Edited (define*-public (stencil-whiteout-outline stil #:optional (thickness 0.3) (color white) (angle-increments 32) (radial-increments 3)) See WhiteoutImproved.jpg to verify that stencil-whiteout-outline works correctly for hyphens after this change. BUT: Using stencil-whiteout-outline will dramatically increase file size: example.pdf without whiteout: 113.185 bytes The same source with LyricHyphen.whiteout=outline 160.400 bytes The same source with edited LyricHyphen.whiteout=outline 342.336 bytes I think we need some optimization here, but LyricHyphen needs a serious overhauling anyway. Here it would help a lot if _every_ hyphen would be a grob as then we could use whiteout-box. cu, Knut ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond-book: Processing multiple lytex files with a single command
Thank you. I will give this a go. -- View this message in context: http://lilypond.1069038.n5.nabble.com/lilypond-book-Processing-multiple-lytex-files-with-a-single-command-tp194804p194895.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond-book: Processing multiple lytex files with a single command
Many thanks. This works well. -- View this message in context: http://lilypond.1069038.n5.nabble.com/lilypond-book-Processing-multiple-lytex-files-with-a-single-command-tp194804p194894.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
quoting percent repeats
Should I be able to quote a percent repeat?
xNotes = { \repeat percent 4 c''1 }
\addQuote qx \xNotes
yNotes = { \quoteDuring qx s1*4 }
\score{
\new StaffGroup << \new Staff \xNotes \new Staff \yNotes >>
}
TIA
Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: v2.19.47 on Mac x86 (Jacques Menu Muzhic)
>> https://bugs.freedesktop.org/show_bug.cgi?id=97546 >> >> The proposed fix hasn't been applied yet to the fontconfig git >> repository – maybe we should downgrade GUB's fontconfig version to >> 2.12.0 until this is fixed. > > I think that there is another possible solution. To use the > proposed patch in GUB. Certainly. However, I can't estimate whether there aren't side effects... On the other hand, given that the patch is from the fontconfig maintainer, there are high chances that it is the right one :-) Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: v2.19.47 on Mac x86 (Jacques Menu Muzhic)
>> Most likely cause of the issue will be the 2.12.1 change that >> improved cache validation logic (and for yet unknown reasons always >> invalidates the cache of the Mac OS System fonts) >> >> https://www.freedesktop.org/software/fontconfig/release/ChangeLog-2.12.1 > > Aah, this rings a bell. > > https://bugs.freedesktop.org/show_bug.cgi?id=97546 > > The proposed fix hasn't been applied yet to the fontconfig git > repository – maybe we should downgrade GUB's fontconfig version to > 2.12.0 until this is fixed. I think that there is another possible solution. To use the proposed patch in GUB. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: v2.19.47 on Mac x86 (Jacques Menu Muzhic)
> Most likely cause of the issue will be the 2.12.1 change that > improved cache validation logic (and for yet unknown reasons always > invalidates the cache of the Mac OS System fonts) > > https://www.freedesktop.org/software/fontconfig/release/ChangeLog-2.12.1 Aah, this rings a bell. https://bugs.freedesktop.org/show_bug.cgi?id=97546 The proposed fix hasn't been applied yet to the fontconfig git repository – maybe we should downgrade GUB's fontconfig version to 2.12.0 until this is fixed. Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: v2.19.47 on Mac x86 (Jacques Menu Muzhic)
Discovered already that indeed a newer version of font-config is packaged with
2.19.47 (2.12.1 versus 2.11.95).
Most likely cause of the issue will be the 2.12.1 change that improved cache
validation logic (and for yet unknown reasons always invalidates the cache of
the Mac OS System fonts)
https://www.freedesktop.org/software/fontconfig/release/ChangeLog-2.12.1
> On 24 Sep 2016, at 12:55, Hans Aikema wrote:
>
> Looked a bit furher into this, and seems to be an issue of the fontconfig
> library. Was that upgraded between the binaries of 2.19.46 and 2.19.47?
>
> Seems that in Lilypond 2.19.47 fontconfig is no longer having a cache/dir
> checksum match for the system font library and thus rescans it on each run to
> build the cache. On 2.19.46 it still shows a match.
>
> Lilypond 2.19.46:
>
> GNU LilyPond 2.19.46
> FC_DEBUG=16
> FcCacheTimeValid dir
> "/Users/aikebah/Downloads/LilyPond2.19.46.app/Contents/Resources/share/lilypond/current/fonts/otf"
> cache checksum 1469570231 dir checksum 1469570231
> FcCacheTimeValid dir "/Library/Fonts" cache checksum 1458750870 dir checksum
> 1458750870
> FcCacheTimeValid dir "/System/Library/Fonts" cache checksum 1458750878 dir
> checksum 1458750878
> Verwerken van 'test.ly'
> Ontleden...
> Vertolken van muziek...
> Voorbewerken van grafische objecten...
> Zoeken naar het ideale aantal pagina's...Fontconfig warning: ignoring UTF-8:
> not a valid region tag
>
> Muziek passend maken voor 1 pagina...
> Tekenen van systemen...
> Opmaakuitvoer naar
> '/var/folders/w1/2ppjzq0j4cj2wv3f06_rd6twgn/T//lilypond-GNcNkQ'...
> Converteren naar 'test.pdf'...
> Verwijderen van
> '/var/folders/w1/2ppjzq0j4cj2wv3f06_rd6twgn/T//lilypond-GNcNkQ'...
> Gelukt: compilatie is met succes voltooid
>
>
>
>
> Lilypond 2.19.47:
>
> GNU LilyPond 2.19.47
> FC_DEBUG=16
> FcCacheTimeValid dir
> "/Users/aikebah/Downloads/LilyPond2.19.47.app/Contents/Resources/share/lilypond/current/fonts/otf"
> cache checksum 1472556057 dir checksum 1472556057
> FcCacheTimeValid dir "/Library/Fonts" cache checksum 1458750870 dir checksum
> 1458750870
>
> charsets 281 -> 80 leaves 30419 -> 1687
> FcDirCacheWriteDir dir "/System/Library/Fonts" file
> "/Users/aikebah/.lilypond-fonts.cache-2//b0a71e6bf6a8a1a908413a823d76e21f-i686-apple-darwin8.cache-7"
> Verwerken van 'test.ly'
> Ontleden...
> Vertolken van muziek...
> Voorbewerken van grafische objecten...
> Zoeken naar het ideale aantal pagina's...Fontconfig warning: ignoring UTF-8:
> not a valid region tag
>
> Muziek passend maken voor 1 pagina...
> Tekenen van systemen...
> Opmaakuitvoer naar
> '/var/folders/w1/2ppjzq0j4cj2wv3f06_rd6twgn/T//lilypond-JVrgSZ'...
> Converteren naar 'test.pdf'...
> Verwijderen van
> '/var/folders/w1/2ppjzq0j4cj2wv3f06_rd6twgn/T//lilypond-JVrgSZ'...
> Gelukt: compilatie is met succes voltooid
>
>
>
>> On 05 Sep 2016, at 00:20, Hans Aikema wrote:
>>
>> On 04 Sep 2016, at 19:42, Cynthia Karl wrote:
>>>
>>>
Message: 5
Date: Sun, 4 Sep 2016 17:41:42 +0200
From: Jacques Menu Muzhic
To: Andrew Bernard
Cc: Jacques Menu Muzhic , lilypond-user
Subject: Re: v2.19.47 on Mac x86
I run El Capitan 10.11.6:
menu@macbookprojm:~/Documents/LaTeX/PartitionsLilypond > uname -a
Darwin macbookprojm 15.6.0 Darwin Kernel Version 15.6.0: Mon Aug 29
20:21:34 PDT 2016; root:xnu-3248.60.11~1/RELEASE_X86_64 x86_64
and I get:
menu@macbookprojm:~ > sudo dtruss lilypond --version
>>>
>>>
>>> I run El Capitan 10.11.6 and get the exact same output for “uname -a”.
>>>
>>> I wanted to see what the difference was between v2.19.46 and v2.19.47, so I
>>> ran them both on the following file:
>>>
>>> bash-3.2$ cat 1note.ly
>>> \version "2.19.46"
>>> { c4 }
>>>
>>> <….>
>>
>>> I then ran dtruss -c on both versions to see what the difference in system
>>> calls was.
>>>
>>> The following table shows the number of system calls which have a Count >
>>> 100 for the v2.19.47 version and the corresponding count for the v2.19.46
>>> version:
>>>
>>> CALLCOUNT LP46 COUNT LP47
>>> … … …
>>> getattrlist 112 128
>>> stat178
>>> 171
>>> stat64 207 207
>>> sigaltstack 222 228
>>> sigprocmask 263 269
>>> select_nocancel 320 323
>>> lseek 57 123013
>>> read_nocancel 341 125474
>>>
>>> I then did a count of the number of lseeks on file descriptors <= 13 (at
>>> first glance there are no file descriptors greater than 12:
>>>
>>> lseek(0xfile
Re: v2.19.47 on Mac x86 (Jacques Menu Muzhic)
Looked a bit furher into this, and seems to be an issue of the fontconfig
library. Was that upgraded between the binaries of 2.19.46 and 2.19.47?
Seems that in Lilypond 2.19.47 fontconfig is no longer having a cache/dir
checksum match for the system font library and thus rescans it on each run to
build the cache. On 2.19.46 it still shows a match.
Lilypond 2.19.46:
GNU LilyPond 2.19.46
FC_DEBUG=16
FcCacheTimeValid dir
"/Users/aikebah/Downloads/LilyPond2.19.46.app/Contents/Resources/share/lilypond/current/fonts/otf"
cache checksum 1469570231 dir checksum 1469570231
FcCacheTimeValid dir "/Library/Fonts" cache checksum 1458750870 dir checksum
1458750870
FcCacheTimeValid dir "/System/Library/Fonts" cache checksum 1458750878 dir
checksum 1458750878
Verwerken van 'test.ly'
Ontleden...
Vertolken van muziek...
Voorbewerken van grafische objecten...
Zoeken naar het ideale aantal pagina's...Fontconfig warning: ignoring UTF-8:
not a valid region tag
Muziek passend maken voor 1 pagina...
Tekenen van systemen...
Opmaakuitvoer naar
'/var/folders/w1/2ppjzq0j4cj2wv3f06_rd6twgn/T//lilypond-GNcNkQ'...
Converteren naar 'test.pdf'...
Verwijderen van
'/var/folders/w1/2ppjzq0j4cj2wv3f06_rd6twgn/T//lilypond-GNcNkQ'...
Gelukt: compilatie is met succes voltooid
Lilypond 2.19.47:
GNU LilyPond 2.19.47
FC_DEBUG=16
FcCacheTimeValid dir
"/Users/aikebah/Downloads/LilyPond2.19.47.app/Contents/Resources/share/lilypond/current/fonts/otf"
cache checksum 1472556057 dir checksum 1472556057
FcCacheTimeValid dir "/Library/Fonts" cache checksum 1458750870 dir checksum
1458750870
charsets 281 -> 80 leaves 30419 -> 1687
FcDirCacheWriteDir dir "/System/Library/Fonts" file
"/Users/aikebah/.lilypond-fonts.cache-2//b0a71e6bf6a8a1a908413a823d76e21f-i686-apple-darwin8.cache-7"
Verwerken van 'test.ly'
Ontleden...
Vertolken van muziek...
Voorbewerken van grafische objecten...
Zoeken naar het ideale aantal pagina's...Fontconfig warning: ignoring UTF-8:
not a valid region tag
Muziek passend maken voor 1 pagina...
Tekenen van systemen...
Opmaakuitvoer naar
'/var/folders/w1/2ppjzq0j4cj2wv3f06_rd6twgn/T//lilypond-JVrgSZ'...
Converteren naar 'test.pdf'...
Verwijderen van
'/var/folders/w1/2ppjzq0j4cj2wv3f06_rd6twgn/T//lilypond-JVrgSZ'...
Gelukt: compilatie is met succes voltooid
> On 05 Sep 2016, at 00:20, Hans Aikema wrote:
>
> On 04 Sep 2016, at 19:42, Cynthia Karl wrote:
>>
>>
>>> Message: 5
>>> Date: Sun, 4 Sep 2016 17:41:42 +0200
>>> From: Jacques Menu Muzhic
>>> To: Andrew Bernard
>>> Cc: Jacques Menu Muzhic ,lilypond-user
>>>
>>> Subject: Re: v2.19.47 on Mac x86
>>> I run El Capitan 10.11.6:
>>>
>>> menu@macbookprojm:~/Documents/LaTeX/PartitionsLilypond > uname -a
>>> Darwin macbookprojm 15.6.0 Darwin Kernel Version 15.6.0: Mon Aug 29
>>> 20:21:34 PDT 2016; root:xnu-3248.60.11~1/RELEASE_X86_64 x86_64
>>>
>>> and I get:
>>>
>>> menu@macbookprojm:~ > sudo dtruss lilypond --version
>>
>>
>> I run El Capitan 10.11.6 and get the exact same output for “uname -a”.
>>
>> I wanted to see what the difference was between v2.19.46 and v2.19.47, so I
>> ran them both on the following file:
>>
>> bash-3.2$ cat 1note.ly
>> \version "2.19.46"
>> { c4 }
>>
>> <….>
>
>> I then ran dtruss -c on both versions to see what the difference in system
>> calls was.
>>
>> The following table shows the number of system calls which have a Count >
>> 100 for the v2.19.47 version and the corresponding count for the v2.19.46
>> version:
>>
>> CALL COUNT LP46 COUNT LP47
>> …… …
>> getattrlist 112 128
>> stat 178 171
>> stat64 207 207
>> sigaltstack 222 228
>> sigprocmask 263 269
>> select_nocancel 320 323
>> lseek 57 123013
>> read_nocancel341 125474
>>
>> I then did a count of the number of lseeks on file descriptors <= 13 (at
>> first glance there are no file descriptors greater than 12:
>>
>> lseek(0xfiledes v46 v47
>>
>> lseek(0x0 1 23
>> lseek(0x1 1 1
>> lseek(0x2 1 1
>> lseek(0x3 2 2
>> lseek(0x4 0 0
>> lseek(0x5 0 0
>> lseek(0x6 2 2
>> lseek(0x735 35
>> lseek(0x8 8 122969
>> lseek(0x9 3 3
>> lseek(0xA 11
>> lseek(0xB 33
>> lseek(0xC 00
Re: Compound Slurs
Am 24. September 2016 00:29:17 MESZ, schrieb Pierre Perol-Schneider : >Hi Urs, > >Here's an attempt with a Ravel piece. >See: http://notat.io/download/file.php?id=208 >First attempt... Nice to see. I'd maybe try to make the edges a bit rounder, but ok, there's nit much space. >On thing: why not multiply the X-ratio by a factor of 10? It is >sometimes >confusing compare to the Y-offset. I had this idea as well, but I thought a range from 0 to 10 would actually be inconsistent. Why take 10 then an not 100? Or xF? I think it *is* the ratio and it should be treated like it. >Anyway, this is a really nice tool. Again, thanks for sharing this. If someone would like sharing a rendering of one of the relevant systems of Gaspard I'd be gappy to make that the "official" example. Urs > >Cheers, >Pierre > > >2016-09-22 18:32 GMT+02:00 Pierre Perol-Schneider < >pierre.schneider.pa...@gmail.com>: > >> Ok, I got it. >> Thank you very much Urs. >> Cheers, >> Pierre >> >> 2016-09-22 16:54 GMT+02:00 Pierre Perol-Schneider < >> pierre.schneider.pa...@gmail.com>: >> >>> That's just perfect. >>> I was anable to get your function yet but the output looks very >nice. >>> Thank you Urs. >>> Cheers, >>> Pierre >>> >>> 2016-09-22 15:44 GMT+02:00 Urs Liska : >>> Am 22.09.2016 um 14:26 schrieb Urs Liska: > Am 22.09.2016 um 13:39 schrieb Pierre Perol-Schneider: >> Hi Urs, >> >> Really nice, congrats! >> One thing: Last year I had a discussion about how to draw flat >slurs >> (see: https://notat.io/viewtopic.php?p=696#p696) >> Do you thing you could integrate such option in your function, I >mean a >> simple - but really strait - line in between slurs ? > That should be possible (within the limits of what Simon >responded - > OTOH Carl Sorensen already mentioned how that could be overcome). > > > I see two alternative approaches, although the second won't >always help > with *that*. > > a) > allow a special value 'straight as an inflection's "angle" >property. > This will then make the handle point to the next point. When the >angle > of the next point is 0 then you should have a straight line. > The problem with this is that when the angle is determined the >next > point isn't known yet, and when that next point becomes known the > control point left of the current inflection has already been calculated. > I'll have to look into this, but it should be possible to >re-calculate > the left point. This was actually quite easy to implement. Now you can specify one inflection to have an angle of 'straight >and the next inflection of 0 (zero), which reliably creates a straight line between the two (see attached). You'll see the differing line width, thought, but I hope we'll be >able to solve that as well. Urs > > b) > Currently the angle at an inflection is given as relative to the > previous segment's baseline. I like this because it gives quite > predictable results, but it could be extended by optional >behaviours: > A general or local option could interpret angles at an inflection >as > relative to the whole slur's baseline, or even as absolute angles > (relative to horizontal). This may in *some* cases simplify the > construction of flat segments, but I can imagine there are >situations > where this might be useful in general. > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user >>> >> -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What to do wanting a 4th order Bézier?
Am 24. September 2016 01:58:18 MESZ, schrieb Simon Albrecht : >On 17.09.2016 20:27, Simon Albrecht wrote: >> Hello folks, >> >> I’m attaching an excerpt from my current project, where I’d actually >> really need a 4th order Bézier slur – but that’s impossible with Lily > >> now. Unfortunately I also lack an idea what else to do in this >> situation – I’d like to avoid an extra staff… >> Any ideas? > >Funny story: I now changed the arrangement so that I don’t even need a >compound slur – LOL! > but I’m really glad to have kicked off this >development. >Thanks to those involved, and mainly thanks Urs! > >Best, Simon > >___ >lilypond-user mailing list >lilypond-user@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-user -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
