Re: music function to be included somewhere in scm/*
Am 16.12.2016 um 02:09 schrieb Alexander Kobel: Hi all. [...] What about hide-below-length or hide-if-shorter-than? minimum-visibility? Just my 2ct, Marc ___ 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 all. I second Werner's opinion that the goal should not necessarily be an identical score, but a reasonable one. This time, we could even hope for improvements: there will be some valid extenders that users simply did not bother (or did not know how) to add, and I think convert-ly should not try to hide them. On 2016-12-15 23:41, Knut Petersen wrote: Am 15.12.2016 um 19:29 schrieb Werner LEMBERG: We have convert-ly exactly for such changes. I doubt that all corner cases like the Issue 1006 update given in lyrextest.ly can be handled automatically ... ??? s/LyricExtender.minimum-length/LyricExtender.whatever-you-want/ Yes, that would be easy. I also second Werner's though that minimum-length is not the best description. In the context of spanners, it means "widen the score such that this spanner has length at least x"; quite different from the new meaning "suppress below length x" (remember that extenders never influence spacing). However, I dislike both minimum-space (it's not about widening so that there is enough space, either; plus this term is already used with a different meaning) and show-length (which sounds like a debug option that prints or annotates the length). What about hide-below-length or hide-if-shorter-than? What I meant is that I do believe that it is impossible to mechanically translate an old score to give exactly the same result with the new code. Let's try to start. See above; I don't think this was Werner's point. We do not need "__", so eliminate it: sed -e "s/__//g" Not sure if we should do that. Any __ in the lyrics don't do harm, and it keeps the source somewhat backwards compatible. Ok, that looks good. But wait: There is a melisma, Which convert-ly is unable to detect, unless there are _ in the lyrics. Other than that, melismata detection requires full parsing and interpretation, which is beyond the scope (and intention) of convert-ly. [...] Is convert.ly intelligent enough to handle that problem correctly? I doubt that although I admit that I never had a look at the code. AFAICS, it's a slighly more fancy grep. Pure pattern substitution. So I share your doubts. There is one way we could stay compatible: Keep the old code and use it for every score with a \version < X , enable the new code for \version >= X. My KISS proposal: (1) Keep lyrics sourcecode as-is in general (don't remove __), (2) replace LyricExtender.minimum-length by LyricExtender.whatever-it-will-be, and (3) replace all 'pattern _ ' by 'pattern "" ' where pattern != _ or __. The latter rule will miss out opportunities to create some forgotten extenders for manual melismata, but it is crucial to leave non-trivial divisi lyrics in a reasonable shape (see my mails from 2016-12-14 2:39pm and 2016-12-15 1:04am UTC+1). Gute Nacht! 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/*
> What I meant is that I do believe that it is impossible to > mechanically translate an old score to give exactly the same result > with the new code. `Exactly the same' should not be the goal IMHO – we have to freeze the sources (similar to TeX) to achieve that. The output should rather be `reasonable'. > We do not need "__", so eliminate it: sed -e "s/__//g" > > Ok, that looks good. But wait: There is a melisma, and it would be > longer than minimum-length, the new engraver adds an extender line. > But there is no "__", so the old code did not engrave an extender > line. Ok, add an override to be sure there is no extender with the > new code. Is convert.ly intelligent enough to handle that problem > correctly? I doubt that although I admit that I never had a look at > the code. Well, we had similar, incompatible updates already. The usual route was to make `convert-ly' try the best and emit a message Not smart enough to convert foo. Please refer to the manual for details, and update manually. Werner ___ 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 15.12.2016 um 19:29 schrieb Werner LEMBERG: We have convert-ly exactly for such changes. I doubt that all corner cases like the Issue 1006 update given in lyrextest.ly can be handled automatically ... ??? s/LyricExtender.minimum-length/LyricExtender.whatever-you-want/ Yes, that would be easy. What I meant is that I do believe that it is impossible to mechanically translate an old score to give exactly the same result with the new code. Let's try to start. We do not need "__", so eliminate it: sed -e "s/__//g" Ok, that looks good. But wait: There is a melisma, and it would be longer than minimum-length, the new engraver adds an extender line. But there is no "__", so the old code did not engrave an extender line. Ok, add an override to be sure there is no extender with the new code. Is convert.ly intelligent enough to handle that problem correctly? I doubt that although I admit that I never had a look at the code. There is one way we could stay compatible: Keep the old code and use it for every score with a \version < X , enable the new code for \version >= X. cu, 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/*
On December 15, 2016 8:41:14 PM GMT+01:00, Simon Albrecht wrote: >On 15.12.2016 17:45, Alexander Kobel wrote: >> (1) You can put the lyrics to all voices, as extenders are only >> printed on melismata (unless explicitly enforced). >> (2) You don't have to add __ in your lyrics anymore - it's done >> automagically (unless explicitly disabled). >> (3) minimum-length (or some other name) is used to control appearance > >> (right now, you "abuse" it to fake semantics). > >This is a _huge_ improvement and new feature! I’ll be thrilled to see >it >in the code base. > >Best, Simon +1. And the most surprising thing about it is that I had a (slightly less elegantly scheme-d, but still working) solution in my toolbox and posted on the list years ago, and never noticed its potential. So a big thanks to Joram! Usability-wise, that's the most drastic improvement for my typical Lilypond work I can imagine... 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/*
Knut Petersen wrote Thursday, December 15, 2016 6:08 PM >> Another common use case occurs when the lyrics in several verses have >> melismata in different places. This is usually indicated with dashed slurs, >> occasionally even with two such slurs starting on the same note. When >> there are many of these the easiest way is simply to turn off auto-melismata >> with \set melismaBusyProperties = #'() and indicate them with __ and _ >> manually in the lyrics. Presumably this behaviour will not change with your >> proposed patch? > > You would leave out the "__" part everywhere. > > Have a look at lyrextest.ly and lyrextest.pdf I sent to the list a few hours > ago. > That should answer most of your questions. > > The "__" is still understood, but it is not needed. Great! I'm looking forward to a much easier time setting choral pieces for my choir! Many thanks to you and Alexander for all your work and the prompt replies! 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 15.12.2016 17:45, Alexander Kobel wrote: (1) You can put the lyrics to all voices, as extenders are only printed on melismata (unless explicitly enforced). (2) You don't have to add __ in your lyrics anymore - it's done automagically (unless explicitly disabled). (3) minimum-length (or some other name) is used to control appearance (right now, you "abuse" it to fake semantics). This is a _huge_ improvement and new feature! I’ll be thrilled to see it in the code base. Best, Simon ___ 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/*
>> We have convert-ly exactly for such changes. > > I doubt that all corner cases like the Issue 1006 update given in > lyrextest.ly can be handled automatically ... ??? s/LyricExtender.minimum-length/LyricExtender.whatever-you-want/ Werner ___ 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 15.12.2016 um 16:46 schrieb Werner LEMBERG: We have convert-ly exactly for such changes. I doubt that all corner cases like the Issue 1006 update given in lyrextest.ly can be handled automatically ... cu, 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 Urs! I'd suppose that within words hyphens are implicitly created like before? Yes. Nothing in this patch touches the hyphen engraver ... cu, 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 Trevor, Another common use case occurs when the lyrics in several verses have melismata in different places. This is usually indicated with dashed slurs, occasionally even with two such slurs starting on the same note. When there are many of these the easiest way is simply to turn off auto-melismata with \set melismaBusyProperties = #'() and indicate them with __ and _ manually in the lyrics. Presumably this behaviour will not change with your proposed patch? You would leave out the "__" part everywhere. Have a look at lyrextest.ly and lyrextest.pdf I sent to the list a few hours ago. That should answer most of your questions. The "__" is still understood, but it is not needed. cu, 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 15. Dezember 2016 18:58:13 MEZ, schrieb Knut Petersen : >Am 15.12.2016 um 17:17 schrieb Francisco Vila: >> >> Excuse my brevity for now, but I think lyrics extenders are meant >only for the last syllable of a word. What does Gould say, for example? >I can check later, @home. >> >I don't know what Gould says, but you are right. Nothing else is >proposed. I'd suppose that within words hyphens are implicitly created like before? Urs > >Knut > > >___ >lilypond-devel mailing list >lilypond-devel@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-devel -- 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/*
Am 15.12.2016 um 17:17 schrieb Francisco Vila: Excuse my brevity for now, but I think lyrics extenders are meant only for the last syllable of a word. What does Gould say, for example? I can check later, @home. I don't know what Gould says, but you are right. Nothing else is proposed. 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/*
Alexander Kobel and Knut Petersen wrote Thursday, December 15, 2016 4:45 PM OK, thanks for your explanations. Clearly the patch is an improvement for this use case: > On 2016-12-15 17:19, Trevor Daniels wrote: > > Currently, I set minimum-length = 0 in all Lyric contexts so that I > can place identical lyrics in several voices, all with extenders, but > the extenders appear in the score only when they correspond to melismata. > In other words the extender is permitted to reduce in size to 0, which > seems pretty well what "minimum-length" means. Another common use case occurs when the lyrics in several verses have melismata in different places. This is usually indicated with dashed slurs, occasionally even with two such slurs starting on the same note. When there are many of these the easiest way is simply to turn off auto-melismata with \set melismaBusyProperties = #'() and indicate them with __ and _ manually in the lyrics. Presumably this behaviour will not change with your proposed patch? 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-15 17:19, Trevor Daniels wrote: Knut Petersen wrote Thursday, December 15, 2016 1:55 PM minimum-length in my patch means: - Don't generated automatic extenders if it's impossible to give them minimum-length. - Use minimum-length for forced extenders at unusual places (single note) if possible. I think the most reasonable way is to keep that traditional name. I don't understand what you mean for the proposed behaviour. Currently, I set minimum-length = 0 in all Lyric contexts so that I can place identical lyrics in several voices, all with extenders, but the extenders appear in the score only when they correspond to melismata. With the effect that sometimes you'll have extenders that are merely flyspecks, yes. In other words the extender is permitted to reduce in size to 0, which seems pretty well what "minimum-length" means. Will this behaviour change with your proposed patch? Yes: it will improve. (1) You can put the lyrics to all voices, as extenders are only printed on melismata (unless explicitly enforced). (2) You don't have to add __ in your lyrics anymore - it's done automagically (unless explicitly disabled). (3) minimum-length (or some other name) is used to control appearance (right now, you "abuse" it to fake semantics). Explanation for (3): On short melismata you'll often want to hide extenders if the syllable has (almost) the same horizontal extent as the music. That's dependent on line breaks etc., so you'll optimally want a minimum-length /strictly/ larger than 0 (to ensure that you don't have the previously mentioned flyspecks), but smaller than, say, 2 staff spaces. So extenders that have a natural length of 2 units are printed, shorter ones aren't. IMHO, setting minimum-length to 0 is an ingenious workaround for a missing functionality (namely, disabling extenders on non-melismata), but it means that you lose the functionality it is intended for. AFAICS, nothing will change for your existing scores. 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 15.12.2016 um 17:19 schrieb Trevor Daniels:
Currently, I set minimum-length = 0 in all Lyric contexts so that I
can place identical lyrics in several voices, all with extenders, but
the extenders appear in the score only when they correspond to melismata.
In other words the extender is permitted to reduce in size to 0, which
seems pretty well what "minimum-length" means.
Will this behaviour change with your proposed patch?
Yes.
If you need an extender after "X" in one place and an extender after "Y" in
another place,
you could use your method and define
foo = \lyricmode { xx X __ yy Y __ zz }.
With my patch you would simply use
foo = \lyricmode { xx X yy Y zz } to get
the same result, an extender after "X" in one place and after "Y" in another
place.
___
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/*
Excuse my brevity for now, but I think lyrics extenders are meant only for the last syllable of a word. What does Gould say, for example? I can check later, @home. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue311430043by perpeduumimmob...@gmail.com)
Alexander, you wrote Thursday, December 15, 2016 3:51 PM > On 2016-12-15 13:34, Trevor Daniels wrote: > >> Adding you to the dev list is very little work, but you do have to >> get a SourceForge id and tell me what it is for me to do that. >> >> James probably is willing to undertake the work of creating an >> issue and servicing it on your behalf, but if you yourself are not >> known to Allura you will not be able to contribute to any discussion >> on _any_ issue - including those James has created on your behalf. > > Okay, makes sense. In this case, I guess it's reasonable to add me no > matter how much (or little) I will participate. I created an SF account > with username akobel. Added, giving you Developer status. Now you can update and create issues as well as read them. 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/*
Knut Petersen wrote Thursday, December 15, 2016 1:55 PM > minimum-length in my patch means: > - Don't generated automatic extenders if it's impossible to give them > minimum-length. > - Use minimum-length for forced extenders at unusual places (single note) if > possible. > > I think the most reasonable way is to keep that traditional name. I don't understand what you mean for the proposed behaviour. Currently, I set minimum-length = 0 in all Lyric contexts so that I can place identical lyrics in several voices, all with extenders, but the extenders appear in the score only when they correspond to melismata. In other words the extender is permitted to reduce in size to 0, which seems pretty well what "minimum-length" means. Will this behaviour change with your proposed patch? 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 15.12.2016 17:17, Francisco Vila wrote: I think lyrics extenders are meant only for the last syllable of a word. Of course they are. That’s why the proposed code checks for any hyphens before adding an extender. Any syllable which is not the last of a word must have a hyphen. Best, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue311430043by perpeduumimmob...@gmail.com)
On 2016-12-15 13:34, Trevor Daniels wrote: Alexander, you wrote Wednesday, December 14, 2016 11:49 PM 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. Adding you to the dev list is very little work, but you do have to get a SourceForge id and tell me what it is for me to do that. James probably is willing to undertake the work of creating an issue and servicing it on your behalf, but if you yourself are not known to Allura you will not be able to contribute to any discussion on _any_ issue - including those James has created on your behalf. Okay, makes sense. In this case, I guess it's reasonable to add me no matter how much (or little) I will participate. I created an SF account with username akobel. 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/*
>> What about `minimum-space' or `show-length'? > > minimum-length has been a property of the engraver for a long > time. It never implemented the functionality you would expect from > a minimum-length property at other places of lilypond. Removing it > would break older scores more than necessary, so I strongly feel the > need to keep it. I disagree. We have convert-ly exactly for such changes. But maybe it's only me who think that the property name is confusing... Werner ___ 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 everybody.
On 2016-12-15 13:34, Knut Petersen wrote:
Hi Alexander, hi everybody!
And we might need to offer a way to remove a LyricExtender event.
Unless we go the radical route and ...
After a bit of thinking I'd say: go the radical route.
Attached is a patch against current master that implements it that way.
Beautiful. I was afraid of the amount of work this requires, but it's
also my preferred approach. And it looks like the issue popped up at the
right time, with a capable person taking care of the dirty details... :-)
An additional no-extender property
is added that can only be overridden by the force-extender property.
If a user doesn't want it, we need to provide a function \extenderOff
(that translates, e.g., to \override LyricExtender.stencil = ##f).
\layout {
\Lyrics
\override LyricExtender.no-extender = ##t
}
I like that.
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.
"" and \markup\null are usefull, see 5th exampled in attached
lyrextest.ly/pdf
Works like a charm. If "" is to be recommended in the docs (and I think
\markup\null is too verbose for that purpose), we should make sure that the
warning: LyricText has empty extent and non-empty stencil.
is not issued in that case.
I know that the documentation would need some work, but there is no
reason to start with that until it is known that the changed code
would be accepted.
Makes sense. I'm perfectly happy with that patch. Let's wait for some
more opinions.
Thanks and 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 15.12.2016 01:34, Alexander Kobel wrote: any use case for hyphen + extender? No. Best, Simon ___ 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 15.12.2016 13:34, Knut Petersen wrote: After a bit of thinking I'd say: go the radical route. Attached is a patch against current master that implements it that way. I like it, and I’d say: go ahead. 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
>> 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 I've noticed that smart-autogen.sh has "set -ux" and it is invoked from GUB. If I understand correctly, "set -u" and "set -x" etc. do not carry over into child processes. However, at least in your log file, "set -x" seems to be carried over to the child process. >From smart-autogen.sh through autogen.sh to autoconf, all scripts are setted trace mode. Your log file: *** Stage: autoupdate (lilypond, freebsd-x86) invoking cd /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master && ./smart-autogen.sh --noconfigure ++ cat /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/configure.ac /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/aclocal.m4 ++ md5sum ++ cut -b 1-32 + AUTOGEN_INPUT_CHECKSUM=6d044a282ff778474007c3d61d131ebc + CHECKSUM_FILE=autogen.checksum ++ cat autogen.checksum cat: autogen.checksum: No such file or directory + test '' = 6d044a282ff778474007c3d61d131ebc + set -e + /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/autogen.sh --noconfigure ++ dirname /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/autogen.sh + srcdir=/home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master + case $1 in + NOCONFIGURE=true + for i in '$srcdir/configure.ac' ++ dirname /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/configure.ac + dir=/home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master + echo processing /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master processing /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master + cd /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master + echo 'Running autoconf ...' Running autoconf ... + autoconf + DUALCASE=1 [...snip...] In my log file, "set -x" does not seem to be carried over to the child process. Only smart-autogen.sh is setted tracemode. autogen.sh and autoconf are not setted trace mode. My log file: *** Stage: autoupdate (lilypond, freebsd-x86) invoking cd /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master && ./smart-autogen.sh --noconfigure + cat /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/configure.ac /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/aclocal.m4 + cut -b 1-32 + md5sum + AUTOGEN_INPUT_CHECKSUM=6d044a282ff778474007c3d61d131ebc + CHECKSUM_FILE=autogen.checksum + cat autogen.checksum cat: autogen.checksum: No such file or directory + test = 6d044a282ff778474007c3d61d131ebc + set -e + /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/autogen.sh --noconfigure processing /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master Running autoconf ... Skipping configure process. + printf %s 6d044a282ff778474007c3d61d131ebc [...snip...] Perhaps, also "set -u" is carried over in your environment and it is not carried over in my environment. I have no idea. But, in CentOS, /bin/sh is symbolic link to bash, whereas in Ubuntu, /bin/sh is dash. I think that this difference is influenced. ___ 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 Werner! Nice! However, I'm not happy with the name `minimum-length': It implies that this value sets the minimum length of extender lines, which is not true. What about `minimum-space' or `show-length'? minimum-length has been a property of the engraver for a long time. It never implemented the functionality you would expect from a minimum-length property at other places of lilypond. Removing it would break older scores more than necessary, so I strongly feel the need to keep it. minimum-length in my patch means: - Don't generated automatic extenders if it's impossible to give them minimum-length. - Use minimum-length for forced extenders at unusual places (single note) if possible. I think the most reasonable way is to keep that traditional name. cu, 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/*
> Attached is a patch against current master that implements it that > way. An additional no-extender property is added that can only be > overridden by the force-extender property. Nice! However, I'm not happy with the name `minimum-length': It implies that this value sets the minimum length of extender lines, which is not true. What about `minimum-space' or `show-length'? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue311430043by perpeduumimmob...@gmail.com)
Alexander, you wrote Wednesday, December 14, 2016 11:49 PM > 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. Adding you to the dev list is very little work, but you do have to get a SourceForge id and tell me what it is for me to do that. James probably is willing to undertake the work of creating an issue and servicing it on your behalf, but if you yourself are not known to Allura you will not be able to contribute to any discussion on _any_ issue - including those James has created on your behalf. Trevor > 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 ___ 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, hi everybody!
And we might need to offer a way to remove a LyricExtender event. Unless we go
the radical route and ...
After a bit of thinking I'd say: go the radical route.
Attached is a patch against current master that implements it that way. An
additional no-extender property
is added that can only be overridden by the force-extender property.
If a user doesn't want it, we need to provide a function \extenderOff (that
translates, e.g., to \override LyricExtender.stencil = ##f).
\layout {
\Lyrics
\override LyricExtender.no-extender = ##t
}
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.
"" and \markup\null are usefull, see 5th exampled in attached lyrextest.ly/pdf
I know that the documentation would need some work, but there is no reason to
start with that until
it is known that the changed code would be accepted.
Please test ...
cu,
Knut
>From 53e80c9c17cfa2b11deb15ccfef4587b82c06d52 Mon Sep 17 00:00:00 2001
From: Knut Petersen
Date: Thu, 15 Dec 2016 12:52:06 +0100
Subject: [PATCH] Automated lyric extenders
Automatically add lyric extenders whenever they are
appropriate.
Add new property no-extender to forbid all extenders
unless overridden by the 2nd new boolean property
force-extender.
Enabled by default.
Signed-off-by: Knut Petersen
---
lily/lyric-extender.cc| 44 +--
scm/define-context-properties.scm | 2 ++
scm/define-grob-properties.scm| 6 ++
scm/define-grobs.scm | 2 ++
scm/music-functions.scm | 12 ---
5 files changed, 43 insertions(+), 23 deletions(-)
diff --git a/lily/lyric-extender.cc b/lily/lyric-extender.cc
index 8afe2c5569..f7d49ac916 100644
--- a/lily/lyric-extender.cc
+++ b/lily/lyric-extender.cc
@@ -45,51 +45,53 @@ Lyric_extender::print (SCM smob)
common = common->common_refpoint (me->get_system (), X_AXIS);
Real sl = me->layout ()->get_dimension (ly_symbol2scm ("line-thickness"));
+ bool at_start_of_line = !left_edge->internal_has_interface (ly_symbol2scm ("lyric-syllable-interface"));
+ bool at_end_of_line = me->get_bound (RIGHT)->break_status_dir ();
+ bool force_extender = to_boolean (me->get_property ("force-extender"));
+ bool no_extender = to_boolean (me->get_property ("no-extender"));
+
+ if (!force_extender && no_extender)
+return SCM_EOL;
extract_grob_set (me, "heads", heads);
- if (!heads.size ())
+ if (!heads.size () || (!force_extender && !at_start_of_line && !at_end_of_line && heads.size () < 2))
return SCM_EOL;
common = common_refpoint_of_array (heads, common, X_AXIS);
Real left_point = 0.0;
- if (left_edge->internal_has_interface (ly_symbol2scm ("lyric-syllable-interface")))
+ if (!at_start_of_line)
left_point = left_edge->extent (common, X_AXIS)[RIGHT];
- else if (heads.size ())
-left_point = heads[0]->extent (common, X_AXIS)[LEFT];
else
-left_point = left_edge->extent (common, X_AXIS)[RIGHT];
+left_point = heads[0]->extent (common, X_AXIS)[LEFT];
if (isinf (left_point))
return SCM_EOL;
- /* It seems that short extenders are even lengthened to go past the
- note head, but haven't found a pattern in it yet. --hwn 1/1/04 */
- SCM minlen = me->get_property ("minimum-length");
- Real right_point
-= left_point + (robust_scm2double (minlen, 0));
-
- right_point = min (right_point, me->get_system ()->get_bound (RIGHT)->relative_coordinate (common, X_AXIS));
-
- if (heads.size ())
-right_point = max (right_point, heads.back ()->extent (common, X_AXIS)[RIGHT]);
-
Real h = sl * robust_scm2double (me->get_property ("thickness"), 0);
Drul_array paddings (robust_scm2double (me->get_property ("left-padding"), h),
robust_scm2double (me->get_property ("right-padding"), h));
+ Real minlen = robust_scm2double (me->get_property ("minimum-length"), 0);
+
+ Real right_point = heads.back ()->extent (common, X_AXIS)[RIGHT];
+
+ if (force_extender)
+right_point = max (heads.back ()->extent (common, X_AXIS)[RIGHT], left_point + minlen);
+
if (right_text)
right_point = min (right_point, (robust_relative_extent (right_text, common, X_AXIS)[LEFT] - paddings[RIGHT]));
- /* run to end of line. */
- if (me->get_bound (RIGHT)->break_status_dir ())
+ if (at_end_of_line)
right_point = max (right_point, (robust_relative_extent (me->get_bound (RIGHT), common, X_AXIS)[LEFT] - paddings[RIGHT]));
- left_point += paddings[LEFT];
+ if (!at_start_of_line)
+left_point += paddings[LEFT];
+
Real w = right_point - left_point;
- if (w < 1.5 * h)
+ if (w < minlen && !at_start_of_line && !at_end_of_line && !force_extender)
return SCM_EOL;
Stencil mol (Lookup::round_filled_box (Box (Interval (0, w),
@@ -111,4 +113,6 @@ ADD_INTERFACE (Lyric_extender,
"next "
