music function to be included somewhere in scm/*
Hi everybody! There is a discussion on lilypond-user with the target to allow automated lyric extenders to lilypond. One part of that is a patch to clean and extend lyric_extender.cc. To allow automated creation of lyric extenders a helper function is needed. Putting the following code into a lilypond score does the job: #(define autoextenders (define-music-function (lyrics) (ly:music?) (music-map (lambda (event) (if (and (eq? (ly:music-property event 'name) 'LyricEvent) (not (let* ((art (ly:music-property event 'articulations)) (is-hyphen? (lambda (ev) (eq? (ly:music-property ev 'name) 'HyphenEvent (find is-hyphen? art))) (not (string=? (ly:music-property event 'text) " "))) (ly:music-set-property! event 'articulations (append (ly:music-property event 'articulations) (list (make-music (quote ExtenderEvent) event ) event) lyrics))) Q1: Where should a definition of \autoextenders reside? scm/music-functions.scm? Q2: Obviously the definition of \autoextenders does not match the coding style used in scm/*. It does not even work if it is added to music-functions.scm. Some advice is needed ... the extending-manual is not a real help in this case. Cheers, Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function to be included somewhere in scm/*
Hi Knut, hi all. On 2016-12-14 10:16, Knut Petersen wrote: Hi everybody! There is a discussion on lilypond-user with the target to allow automated lyric extenders to lilypond. One part of that is a patch to clean and extend lyric_extender.cc. Knut is playing down his work here. The crucial point: with his patch, there is no harm in adding lyric extenders everywhere, because they will not produce any output on non-melismata (unless overriden specifically). Also, the handling of extender's minimum-length is cleaned up. To allow automated creation of lyric extenders a helper function is needed ... that does exactly this, adding extenders everywhere. IMHO, the actual question to decide upon is: Do we want this to be enabled by default? IIUC, the fact that extenders are not automatic is a known shortcoming. NR 2.1.1 states under "Known issues and warnings": "Extender lines under melismata are not created automatically; they must be inserted manually with a double underscore." (see http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-vocal-music#multiple-notes-to-one-syllable) With Knut's patch, this will mostly impact scores where extenders are left out unintentionally. Still, it will be a burden for convert-ly unless we have a global (or per lyric definition) \noAutomaticExtender rule that is inserted by default. On the other hand, there is the chance to get rid of scores where users don't add extenders simply because they are not aware of their importance or the proper syntax. Putting the following code into a lilypond score does the job: #(define autoextenders (define-music-function (lyrics) (ly:music?) (music-map (lambda (event) (if (and (eq? (ly:music-property event 'name) 'LyricEvent) (not (let* ((art (ly:music-property event 'articulations)) (is-hyphen? (lambda (ev) (eq? (ly:music-property ev 'name) 'HyphenEvent (find is-hyphen? art))) (not (string=? (ly:music-property event 'text) " "))) (ly:music-set-property! event 'articulations (append (ly:music-property event 'articulations) (list (make-music (quote ExtenderEvent) event ) event) lyrics))) Q1: Where should a definition of \autoextenders reside? scm/music-functions.scm? AFAICS: yes. Q2: Obviously the definition of \autoextenders does not match the coding style used in scm/*. It does not even work if it is added to music-functions.scm. Some advice is needed ... the extending-manual is not a real help in this case. I think you mixed up define-music-function and a plain Scheme define. IIUC, define-music-function creates an anonymous function with some syntactic sugar (e.g., type-checking of the additional arguments past parser and location) which is then assigned to a variable: function = #(define-music-function (parser location arg1 arg2) (arg1-type-check? arg2-type-check?) ...) That's used in user space and relies on Lilypond's parser, for the assignment of the anonymous function. So if we use that, it must go to some .ly file with my original syntax; e.g. ly/lyrics-tkit.ly, is apt. Otherwise, it can go to a .scm file as just (define (autoextenders lyrics) (music-map ...)) Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function to be included somewhere in scm/*
Am 14.12.2016 um 10:43 schrieb Alexander Kobel: >> Q2: Obviously the definition of \autoextenders does not match the coding >> style used in scm/*. It does not even >> work if it is added to music-functions.scm. Some advice is needed ... >> the extending-manual is not a real help in >> this case. > > I think you mixed up define-music-function and a plain Scheme define. > IIUC, define-music-function creates an anonymous function with some > syntactic sugar (e.g., type-checking of the additional arguments past > parser and location) which is then assigned to a variable: > > function = #(define-music-function > (parser location arg1 arg2) > (arg1-type-check? arg2-type-check?) > ...) > > That's used in user space and relies on Lilypond's parser, for the > assignment of the anonymous function. So if we use that, it must go to > some .ly file with my original syntax; e.g. ly/lyrics-tkit.ly, is apt. > > Otherwise, it can go to a .scm file as just > (define (autoextenders lyrics) > (music-map ...)) > Not having looked into the actual code I'd like to add that within a .scm file you'd define a music function as in Knut's original email - but without the starting hash sign. But music-functions.scm doesn't seem to use this syntax and does plain defines (or define-public). Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: linux-ppc harfbuzz GUB build error
> On 13 Dec 2016, at 01:20, Hans Aikema wrote: > > On 12 Dec 2016, at 15:41, Masamichi Hosoda wrote: >> >> <…> >> Maybe the issue is to use ICU of CentOS system. >> >> I've created a patch. >> https://github.com/trueroad/gub/commit/081cc91f698186795dca45e8d6db8af6616826d4 >> >> If this patch solves the issue, I will send the pull request. > > New gub bootstrapped from you repo; running a trialbuild tonight… more to > follow tomorrow > New build from Masamichi’s branch passed the linux ppc harfbuzz, so the ICU patch worked. Now looking into a breaking freebsd-x86 lilypond error: building package: freebsd-x86::lilypond *** Stage: download (lilypond, freebsd-x86) *** Stage: untar (lilypond, freebsd-x86) *** Stage: patch (lilypond, freebsd-x86) *** Stage: autoupdate (lilypond, freebsd-x86) Command barfed: cd /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master && ./smart-autogen.sh --noconfigure Tail of target/freebsd-x86/log/lilypond.log + unset CDPATH /home/gub/gub/target/tools/root/usr/bin/autoconf: line 188: CONFIG_SHELL: unbound variable + exit 1 Command barfed: cd /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master && ./smart-autogen.sh --noconfigure Tail of target/freebsd-x86/log/lilypond.log ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function to be included somewhere in scm/*
Am 14.12.2016 um 10:43 schrieb Alexander Kobel: >> To allow automated creation of lyric extenders a helper function is >> needed > > ... that does exactly this, adding extenders everywhere. > > IMHO, the actual question to decide upon is: Do we want this to be > enabled by default? IIUC, the fact that extenders are not automatic is > a known shortcoming. NR 2.1.1 states under "Known issues and warnings": > "Extender lines under melismata are not created automatically; they > must be inserted manually with a double underscore." (see > http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-vocal-music#multiple-notes-to-one-syllable) > > > With Knut's patch, this will mostly impact scores where extenders are > left out unintentionally. Still, it will be a burden for convert-ly > unless we have a global (or per lyric definition) \noAutomaticExtender > rule that is inserted by default. > > On the other hand, there is the chance to get rid of scores where > users don't add extenders simply because they are not aware of their > importance or the proper syntax. My gut feeling says: Yes, this is an improvement and should be there by default. IIUC the reason why this has to be discussed is because that could change/break existing scores, right? If so, could you please think about an example where the patch would have a negative impact that can't reasonably be caught by convert-ly? Just because you two are much more into the topic, so that could help us others understand ... Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: linux-ppc harfbuzz GUB build error
> New build from Masamichi’s branch passed the linux ppc harfbuzz, so the ICU > patch worked. Now looking into a breaking freebsd-x86 lilypond error: Would you show me the whole log file? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
Hello, On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote: Reviewers: , Message: add choral and choral-cautionary accidental style ... Please review this at https://codereview.appspot.com/311430043/ Affected files (+151, -1 lines): M Documentation/notation/pitches.itely M ly/engraver-init.ly M scm/music-functions.scm ___ Does this have an associated tracker item or do we need to create one for you? https://sourceforge.net/p/testlilyissues/issues/?source=navbar Thanks James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: linux-ppc harfbuzz GUB build error
> On 14 Dec 2016, at 12:28, Masamichi Hosoda wrote: > >> New build from Masamichi’s branch passed the linux ppc harfbuzz, so the ICU >> patch worked. Now looking into a breaking freebsd-x86 lilypond error: > > Would you show me the whole log file? Went into a bit of experimentation afterwards, still failed attempts only, after discovering that the message is basically a side-effect of set -u combined with autoconf apparently trying to use unbound variable CONFIG_SHELL On a cleanly booted docker-image recreated the issue with bin/gub freebsd-x86::lilypond lilypond.log.gz Description: GNU Zip compressed data Current environment (post build): sh-4.2$ set BASH=/bin/sh BASHOPTS=cmdhist:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=() BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]="4" [1]="2" [2]="46" [3]="1" [4]="release" [5]="x86_64-redhat-linux-gnu") BASH_VERSION='4.2.46(1)-release' COLUMNS=181 DIRSTACK=() EUID=1000 GROUPS=() HISTFILE=/home/gub/.bash_history HISTFILESIZE=500 HISTSIZE=500 HOME=/home/gub HOSTNAME=b16319215462 HOSTTYPE=x86_64 IFS=' ' LINES=68 MACHTYPE=x86_64-redhat-linux-gnu MAILCHECK=60 OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PIPESTATUS=([0]="1") POSIXLY_CORRECT=y PPID=0 PS1='\s-\v\$ ' PS2='> ' PS4='+ ' PWD=/home/gub/gub REGTESTS_CURRENT=2.19.52-1 SHELL=/bin/bash SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor:posix SHLVL=1 TERM=xterm UID=1000 _=freebsd-x86::lilypond no_proxy='*.local, 169.254/16’ sh-4.2$ export -p export HOME="/home/gub" export HOSTNAME="b16319215462" export OLDPWD export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" export PWD="/home/gub/gub" export REGTESTS_CURRENT="2.19.52-1" export SHLVL="1" export TERM="xterm" export no_proxy="*.local, 169.254/16" ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
Hi James, thanks for taking care of that one. On 2016-12-14 13:15, James wrote: Hello, On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote: Reviewers: , Message: add choral and choral-cautionary accidental style ... Please review this at https://codereview.appspot.com/311430043/ Affected files (+151, -1 lines): M Documentation/notation/pitches.itely M ly/engraver-init.ly M scm/music-functions.scm ___ Does this have an associated tracker item or do we need to create one for you? https://sourceforge.net/p/testlilyissues/issues/?source=navbar I don't think git-cl created one; I received some error message but I thought it related to the known and documented "no automatic notification" after patch upload. But obviously, I mis-configured git-cl's Allura bearer token... Please create one if you don't mind; I will have a look at the configuration for my next upload. Thanks, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
On 14/12/16 12:32, Alexander Kobel wrote: Hi James, thanks for taking care of that one. On 2016-12-14 13:15, James wrote: Hello, On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote: Reviewers: , Message: add choral and choral-cautionary accidental style ... Please review this at https://codereview.appspot.com/311430043/ Affected files (+151, -1 lines): M Documentation/notation/pitches.itely M ly/engraver-init.ly M scm/music-functions.scm ___ Does this have an associated tracker item or do we need to create one for you? https://sourceforge.net/p/testlilyissues/issues/?source=navbar I don't think git-cl created one; I received some error message but I thought it related to the known and documented "no automatic notification" after patch upload. But obviously, I mis-configured git-cl's Allura bearer token... Please create one if you don't mind; I will have a look at the configuration for my next upload. Actually I cannot see you (or an appropriate email) for you in the list of people able to create tickets so that may be why. https://sourceforge.net/p/testlilyissues/issues/5010/ has been created. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
LilyDev 5.0 released
Hi all Eventually I managed to build the new ISO. I decided to upgrade to Stretch (still in testing), because otherwise I had problems with pinning guile-2.0 from testing. Another advantage is that in Stretch there's also LxQT (successor of LXDE), which seems lightweight, fast and feature-rich. You can donwload the image here: https://github.com/fedelibre/LilyDev/releases/tag/v5.0 Let me know if you find any problem. Notable changes: - upgrade to Debian 9 Stretch and live-build 5 - switch to [LXQt](http://lxqt.org/), successor of LXDE - upgrade to guile-2 - update some lilypond build dependencies - added samba support: now you can share files between host and guest just by using in the file manager a link like `smb://10.0.20.10/` (replace it with your local IP); bookmark the link and it will be always available under Places. Let me know if you need any guidance with Samba shares, in case you prefer using libvirt instead of VirtualBox. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
Passes make, make check and a full make doc https://codereview.appspot.com/311430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: linux-ppc harfbuzz GUB build error
>>> New build from Masamichi’s branch passed the linux ppc harfbuzz, so the ICU >>> patch worked. Now looking into a breaking freebsd-x86 lilypond error: >> >> Would you show me the whole log file? > Went into a bit of experimentation afterwards, still failed attempts only, > after discovering that the message is basically a side-effect of > set -u > combined with autoconf apparently trying to use unbound variable CONFIG_SHELL > > On a cleanly booted docker-image recreated the issue with > bin/gub freebsd-x86::lilypond In my environments, autoconf does not raise such error. Do you set the "set -u" or "set -o nounset" somewhere? If so, would you remove the setting? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function to be included somewhere in scm/*
Hi Urs, hi all.
On 2016-12-14 11:18, Urs Liska wrote:
Am 14.12.2016 um 10:43 schrieb Alexander Kobel:
To allow automated creation of lyric extenders a helper function is
needed
... that does exactly this, adding extenders everywhere.
IMHO, the actual question to decide upon is: Do we want this to be
enabled by default? IIUC, the fact that extenders are not automatic is
a known shortcoming. NR 2.1.1 states under "Known issues and warnings":
"Extender lines under melismata are not created automatically; they
must be inserted manually with a double underscore." (see
http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-vocal-music#multiple-notes-to-one-syllable)
With Knut's patch, this will mostly impact scores where extenders are
left out unintentionally. Still, it will be a burden for convert-ly
unless we have a global (or per lyric definition) \noAutomaticExtender
rule that is inserted by default.
On the other hand, there is the chance to get rid of scores where
users don't add extenders simply because they are not aware of their
importance or the proper syntax.
My gut feeling says: Yes, this is an improvement and should be there by
default. IIUC the reason why this has to be discussed is because that
could change/break existing scores, right?
Correct. Change: yes, for sure; break: hardly, unless non-standard
adjustments to lyrics have been made.
If so, could you please think about an example where the patch would
have a negative impact that can't reasonably be caught by convert-ly?
Just because you two are much more into the topic, so that could help us
others understand ...
The only difficult situation for an automatic conversion that I can
think of is the following:
Attached is a modified version of the "divisi lyrics" example from NR
2.1.2, along with a modified version of \autoextenders that alleviates
the severity and offers a way out. The file features a slightly
different approach to divisi lyrics, where the second voice persists
over the entire length of music, but some notes are skipped in the
lyrics with _.
The short stub extenders after "We" and in the third lyrics line will be
removed by Knut's patch, so they are not a problem (the picture is made
from an unpatched Lily version). The issue is with the long extenders
after "will" without corrections. That's because the several _ _ in the
lyrics create a melisma over several notes, which is semantically wrong,
but visually indistinguishable from the correct semantics; hence, I
could imagine that this notation has been used in several scores with
divisi lyrics. I'm no exception myself.
My guess is that a convert-ly rule that translates every occurence of
word _
to
\once \override LyricText.self-alignment-X = #LEFT word \markup{\null}
or
\once \override LyricText.self-alignment-X = #LEFT word ""
will be sufficient to resolve it, but I'm not sure how robust this
approach is. This fakes the melisma by left-alignment, but semantically
leaves "word" assigned to only one note.
"" gives a warning "LyricText has empty extent and non-empty stencil.",
though; for the more verbose \markup{\null} I can't figure out how to
leave out the braces: \markup \null translates to (markup #:null) in
Scheme, but the Scheme construct (markup #:null) creates (markup #:line
(#:null)) somewhere on the way, and those don't compare equal...
For "normal" lyrics, it's difficult to tell. I cannot imagine a
"negative" impact in the sense that readability is affected for proper
lyrics. But at least there is a change.
E.g., I took some (more or less) random piece from CPDL - have a look at
http://www.uma.es/victoria/pdf/Cum_Beatus_Ignatius.pdf
A typical renaissance piece with typical notation (no slurs). Alvarez is
clearly aware of extenders and uses them, e.g. in m. 43. However, he
decided not to add them at other places, e.g. for the very first word of
the canto or in the final bars m. 100 - 102. I guess that this is
deliberate decision and not lazyness, and the same is done throughout
his other scores.
I could e.g. imagine that some editor distinguishes for { b2~ | b r } in
m. 53: with extender, hold the entire value of the note; without, you're
allowed to stop earlier, e.g. on the barline. Not saying that this is
Alvarez' intention, or that this is a good or bad interpretation, but
you never know. At least, it would be an explanation for having
extenders only here and there.
But I'm confident that in most cases (basically, short of misusing
lyrics for other means), the changes will not deteriorate the appearance
and readability, rather the contrary.
Cheers,
Alexander
\version "2.19"
autoextenders =
#(define-music-function (lyrics) (ly:music?)
(let* ((has-hyphen?
(lambda (event)
(let* ((art (ly:music-property event 'articulations))
(is-hyphen? (lambda (ev) (eq? (ly:music-property ev 'name) 'HyphenEvent
(find is-h
Re: music function to be included somewhere in scm/*
Hi Urs! My gut feeling says: Yes, this is an improvement and should be there by default. IIUC the reason why this has to be discussed is because that could change/break existing scores, right? If so, could you please think about an example where the patch would have a negative impact that can't reasonably be caught by convert-ly? Just because you two are much more into the topic, so that could help us others understand ... For the changes to the lyric-extender.cc: There is no "__": nothing changes. There is a melisma and "__" in the lyrics: = Old behaviour: print an extender line. Even if there is no place: print an extender line New behaviour: print an extender line only if the extender line is longer than minimum-length. There is no melisma but there is "__" in the lyrics. == Old behaviour: print a short extender line. New behaviour: print an extender line of minimum-length only if forced by the new force-extender boolean property. In other words: Never ever print an extender line if there is no melisma unless forced with new syntax. Some code needs to be (and can be) converted, e.g. http://lsr.di.unimi.it/LSR/Item?id=1006 Advantages: With a music function \autoextenders that adds extender events to every syllable you - can be sure never to forget extenders, - can be sure never to generate too short extenders - can use the same lyrics definition for voices that require extenders at different places. Nobody is forced to use \autoextenders, manual definition is still possible. cu, Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: linux-ppc harfbuzz GUB build error
> On 14 Dec 2016, at 14:30, Masamichi Hosoda wrote: > New build from Masamichi’s branch passed the linux ppc harfbuzz, so the ICU patch worked. Now looking into a breaking freebsd-x86 lilypond error: >>> >>> Would you show me the whole log file? >> Went into a bit of experimentation afterwards, still failed attempts only, >> after discovering that the message is basically a side-effect of >> set -u >> combined with autoconf apparently trying to use unbound variable CONFIG_SHELL >> >> On a cleanly booted docker-image recreated the issue with >> bin/gub freebsd-x86::lilypond > > In my environments, autoconf does not raise such error. > Do you set the "set -u" or "set -o nounset" somewhere? > If so, would you remove the setting? The set -u (or to be complete set -ux) I discovered inside /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/smart-configure.sh which was the command that was called when the error was signalled ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function to be included somewhere in scm/*
Hi Knut, On Wed, Dec 14, 2016 at 3:16 AM, Knut Petersen wrote: > Hi everybody! > > There is a discussion on lilypond-user with the target to allow automated > lyric extenders > to lilypond. One part of that is a patch to clean and extend > lyric_extender.cc. > > To allow automated creation of lyric extenders a helper function is needed. > Putting the > following code into a lilypond score does the job: > > #(define autoextenders (define-music-function (lyrics) (ly:music?) >(music-map > (lambda (event) >(if (and (eq? (ly:music-property event 'name) 'LyricEvent) > (not (let* ((art (ly:music-property event 'articulations)) > (is-hyphen? (lambda (ev) (eq? (ly:music-property ev > 'name) 'HyphenEvent >(find is-hyphen? art))) > (not (string=? (ly:music-property event 'text) " "))) > (ly:music-set-property! event 'articulations > (append (ly:music-property event 'articulations) (list > (make-music (quote ExtenderEvent) event ) > event) >lyrics))) > > Q1: Where should a definition of \autoextenders reside? > scm/music-functions.scm? > The right place to define a music function is in ly/music-functions-init.ly. Supporting Scheme functions might go in scm/music-functions.scm. David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue311430043 by perpeduumimmob...@gmail.com)
Alexander, you wrote Wednesday, December 14, 2016 12:32 PM > On 2016-12-14 13:15, James wrote: > >> On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote: >>> Reviewers: , >>> >>> Message: >>> add choral and choral-cautionary accidental style >> ... >>> >>> Please review this at https://codereview.appspot.com/311430043/ >>> >>> Affected files (+151, -1 lines): >>> M Documentation/notation/pitches.itely >>> M ly/engraver-init.ly >>> M scm/music-functions.scm >>> >>> ___ >> >> Does this have an associated tracker item or do we need to create one >> for you? >> >> https://sourceforge.net/p/testlilyissues/issues/?source=navbar > > I don't think git-cl created one; I received some error message but I > thought it related to the known and documented "no automatic > notification" after patch upload. But obviously, I mis-configured > git-cl's Allura bearer token... > Please create one if you don't mind; I will have a look at the > configuration for my next upload. AFAICS you don't have developer status at SourceForge. Have you ever asked to be added as a developer? That would explain the failure. To fix it please send me (or post to the list) your SourceForge identifier and I'll add you. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown for December 14th
Hello, Here is the current patch countdown list. The next countdown will be on December 17th. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ __ Push: No patches to Push at this time. Countdown: 5004 Doc: CG - Add Graham to Bug Squad list - Graham Percival https://sourceforge.net/p/testlilyissues/issues/5004 http://codereview.appspot.com/313160043 Review: 5010 add choral and choral-cautionary accidental style - James Lowe https://sourceforge.net/p/testlilyissues/issues/5010 http://codereview.appspot.com/311430043 New: No new Patches at this time. Waiting: 4600 Let notes/rests suppress multi-measure rest grobs - Dan Eble https://sourceforge.net/p/testlilyissues/issues/4600 http://codereview.appspot.com/265160043 Regards James ___ 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
Re: music function to be included somewhere in scm/*
On 14.12.2016 14:54, Knut Petersen wrote: With a music function \autoextenders that adds extender events to every syllable you - can be sure never to forget extenders, - can be sure never to generate too short extenders - can use the same lyrics definition for voices that require extenders at different places. Nobody is forced to use \autoextenders, manual definition is still possible. Would it be possible/wanted to have this triggered by a context property as well? I for one would prefer that, it’s easier to use. Best, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: linux-ppc harfbuzz GUB build error
> On 14 Dec 2016, at 14:56, Hans Aikema wrote: > > >> On 14 Dec 2016, at 14:30, Masamichi Hosoda wrote: >> > New build from Masamichi’s branch passed the linux ppc harfbuzz, so the > ICU patch worked. Now looking into a breaking freebsd-x86 lilypond error: Would you show me the whole log file? >>> Went into a bit of experimentation afterwards, still failed attempts only, >>> after discovering that the message is basically a side-effect of >>> set -u >>> combined with autoconf apparently trying to use unbound variable >>> CONFIG_SHELL >>> >>> On a cleanly booted docker-image recreated the issue with >>> bin/gub freebsd-x86::lilypond >> >> In my environments, autoconf does not raise such error. >> Do you set the "set -u" or "set -o nounset" somewhere? >> If so, would you remove the setting? > The set -u (or to be complete set -ux) I discovered inside > > /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/smart-configure.sh > > which was the command that was called when the error was signalled > > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel My suspicion was that Ubuntu and CentOS shells treat 'set -u’ different when used in an if test "x$CONFIG_SHELL" = x; then construct so as a varification of that assumption on the prompt I did: set -u if test "x$CONFIG_SHELL" = x; then echo "Configshell not set"; else echo "Configshell set"; fi for both a CentOS 7 and an Ubuntu Xenial container. Unfortunately both yield a bash: CONFIG_SHELL: unbound variable will do some more digging inside autoconf to see if I can spot any reason why CONFIG_SHELL would not be set in my case ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function to be included somewhere in scm/*
Am 14.12.2016 um 18:03 schrieb Simon Albrecht: On 14.12.2016 14:54, Knut Petersen wrote: With a music function \autoextenders that adds extender events to every syllable you - can be sure never to forget extenders, - can be sure never to generate too short extenders - can use the same lyrics definition for voices that require extenders at different places. Nobody is forced to use \autoextenders, manual definition is still possible. Would it be possible/wanted to have this triggered by a context property as well? I for one would prefer that, it’s easier to use. LyricEvents are generated by the following code in music-functions.scm: (define-public (make-lyric-event string duration) (make-music 'LyricEvent 'duration duration 'text string)) Here only a few lines of code are enough to add LyricExtender events for every syllable by default. Of course we would need to disable the warning about more than one extender event. But do we want to enable lyric extenders by default? Cheers, Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function to be included somewhere in scm/*
Am 14. Dezember 2016 18:03:09 MEZ, schrieb Simon Albrecht : >On 14.12.2016 14:54, Knut Petersen wrote: >> With a music function \autoextenders that adds extender events to >> every syllable you >> - can be sure never to forget extenders, >> - can be sure never to generate too short extenders >> - can use the same lyrics definition for voices that require >extenders >> at different places. >> >> Nobody is forced to use \autoextenders, manual definition is still >> possible. > >Would it be possible/wanted to have this triggered by a context >property >as well? I for one would prefer that, it’s easier to use. From my perspective this would make sense. The extender behaviour is actually a property of the Lyrics context and not something that shiuld be applied to a music expression. Urs > >Best, Simon -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function to be included somewhere in scm/*
Hi Alexander, in your example, the last line is just a mockup, isn't it? It is not done by the proposed function? The extender after "We" in the last line is unexpected for me. Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
Worth an entry in changes? Some wording-nitpicks, otherwise LGTM https://codereview.appspot.com/311430043/diff/1/Documentation/notation/pitches.itely File Documentation/notation/pitches.itely (right): https://codereview.appspot.com/311430043/diff/1/Documentation/notation/pitches.itely#newcode2210 Documentation/notation/pitches.itely:2210: style. It is intended for editions that are used both by singers that only The wording feels not very elegant. Though, I'm a non-native speaker... https://codereview.appspot.com/311430043/diff/1/scm/music-functions.scm File scm/music-functions.scm (right): https://codereview.appspot.com/311430043/diff/1/scm/music-functions.scm#newcode1847 scm/music-functions.scm:1847: ;; that the first alteration within a voice (as opposed to on the wording again, maybe: Similar to piano, except that the first alteration within a voice is always printed (as opposed to within a staff). But again: non-native-speaker https://codereview.appspot.com/311430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: linux-ppc harfbuzz GUB build error
> On 14 Dec 2016, at 18:22, Hans Aikema wrote: > > >> On 14 Dec 2016, at 14:56, Hans Aikema wrote: >> >> >>> On 14 Dec 2016, at 14:30, Masamichi Hosoda wrote: >>> >> > <..> > will do some more digging inside autoconf to see if I can spot any reason why > CONFIG_SHELL would not be set in my case > I ran into docker diskspace issues as mentioned on https://forums.docker.com/t/no-space-left-on-device-error/10894/16 Decided to not be too picky on disk consumption and start over with a much larger docker storage volume (200G). As I had to start over I decided to first try and get a dockerized Ubuntu Xenial up-and-running and only when successful on that one start experimenting again with CentOS If you’d like a CentOS validation build somewhere in between I could still do that, as I have the Dockerfiles available to build them as well; but for now I will first trial the docker-path with a Linux distro that has proven compatibility with GUB to rule out the possibility of Linux distro issues when failing to run GUB dockerized. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue311430043 by perpeduumimmob...@gmail.com)
Hi Trevor, yes, I guess I never asked to be on that list. My last commit was pre-Rietveld and pre-Allura, I think; and it's unlikely that contributions from my side will come more often in the foreseeable future (except for one more patch "in the pipeline", waiting for a cleanup and documentation). So I guess it's not really worth to give me any other status than other occasional users. On the other hand, do whatever is the most convenient for you - handling a lonesome patch every other year manually or adding me. Cheers, Alexander On 2016-12-14 16:28, Trevor Daniels wrote: Alexander, you wrote Wednesday, December 14, 2016 12:32 PM On 2016-12-14 13:15, James wrote: On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote: Reviewers: , Message: add choral and choral-cautionary accidental style ... Please review this at https://codereview.appspot.com/311430043/ Affected files (+151, -1 lines): M Documentation/notation/pitches.itely M ly/engraver-init.ly M scm/music-functions.scm ___ Does this have an associated tracker item or do we need to create one for you? https://sourceforge.net/p/testlilyissues/issues/?source=navbar I don't think git-cl created one; I received some error message but I thought it related to the known and documented "no automatic notification" after patch upload. But obviously, I mis-configured git-cl's Allura bearer token... Please create one if you don't mind; I will have a look at the configuration for my next upload. AFAICS you don't have developer status at SourceForge. Have you ever asked to be added as a developer? That would explain the failure. To fix it please send me (or post to the list) your SourceForge identifier and I'll add you. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function to be included somewhere in scm/*
On 2016-12-14 21:36, Noeck wrote: Hi Alexander, in your example, the last line is just a mockup, isn't it? It is not done by the proposed function? The extender after "We" in the last line is unexpected for me. Hi, not a mockup, but not the real thing either. I sent this from a PC with the "official" unstable version, without Knut's modification, and I did not fake the effect of the patch. With Knut's proposed addition, it looks as attached (and as you expect). Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
On 2016-12-14 23:13, thomasmorle...@gmail.com wrote: Worth an entry in changes? Maybe. Doesn't need a lot, I guess; something like "Accidental rules can now be defined across ChoirStaff contexts. Two new rules choral and choral-cautionary are available that combine the characteristics of modern-voice and piano or their equivalents with cautionary accidentals." Some wording-nitpicks, otherwise LGTM Thanks. https://codereview.appspot.com/311430043/diff/1/Documentation/notation/pitches.itely#newcode2210 Documentation/notation/pitches.itely:2210: style. It is intended for editions that are used both by singers that only The wording feels not very elegant. Though, I'm a non-native speaker... Not a native speaker here, either, so I'm open to proposals. https://codereview.appspot.com/311430043/diff/1/scm/music-functions.scm#newcode1847 scm/music-functions.scm:1847: ;; that the first alteration within a voice (as opposed to on the wording again, maybe: Similar to piano, except that the first alteration within a voice is always printed (as opposed to within a staff). Agreed, that sounds better. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function to be included somewhere in scm/*
On 2016-12-14 19:46, Knut Petersen wrote: Am 14.12.2016 um 18:03 schrieb Simon Albrecht: On 14.12.2016 14:54, Knut Petersen wrote: With a music function \autoextenders that adds extender events to every syllable you - can be sure never to forget extenders, - can be sure never to generate too short extenders - can use the same lyrics definition for voices that require extenders at different places. Nobody is forced to use \autoextenders, manual definition is still possible. Would it be possible/wanted to have this triggered by a context property as well? I for one would prefer that, it’s easier to use. LyricEvents are generated by the following code in music-functions.scm: (define-public (make-lyric-event string duration) (make-music 'LyricEvent 'duration duration 'text string)) Here only a few lines of code are enough to add LyricExtender events for every syllable by default. Yes. In fact, it's more straightforward to add it here than with the extra music function. Not sure how a context property would come into play here; I guesss that'd mean that make-lyric-event branches on a variable named, say, autoAddExtenders, and adds an ExtenderEvent if and only if it is set to #t? Not sure how to code that part, but it seems plausible that we can make that work. Of course we would need to disable the warning about more than one extender event. And we might need to offer a way to remove a LyricExtender event. Unless we go the radical route and ... But do we want to enable lyric extenders by default? ... have them enabled by default, get rid of ExtenderEvent entirely, and just assume it's there for every syllable, unless there is a HyphenEvent (any use case for hyphen + extender?). If a user doesn't want it, we need to provide a function \extenderOff (that translates, e.g., to \override LyricExtender.stencil = ##f). Only thing to consider there: We'd need a "stop sign" for extenders that shall only extend to some point in a _ _ _ sequence, as required in a divisi lyrics setting. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
