Re: 2.18 release notes
Quoting James :
The original diff is here:
https://codereview.appspot.com/11328043/diff/40001/Documentation/notation/vocal.itely
This gives an example I suppose we could add to the changes doc.
Actually, there are several examples there.
I don't really understand this function to be able to come up with
something else, but if you do feel free to email it and we can add a
patch to the changes.tely or something like that.
NullVoice is a voice that is not shown but that can accept lyrics. I
really like that I can reuse an existing melodic line for the lyrics
and it won't conflict with any visible voice.
The documentation shows examples with \partcombine, but both of them
use a separate aligner variable, which may be good for advanced stuff,
but doesn't show how simple things become in the common case.
I suggest something like this:
A new context called NullVoice has been added. It doesn't appear in
the printed output, but it can be used to align lyrics. It can be
used with the partcombine function.
soprano = \relative c' {
c e g c
}
alto = \relative c' {
a c e g
}
verse = \lyricmode {
This is my song
}
\score {
\new Staff <<
\partcombine \soprano \alto
\new NullVoice = "aligner" \soprano
\new Lyrics \lyricsto "aligner" \verse
>>
\layout {}
}
--
Regards,
Pavel Roskin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
2.18 release notes
Hello! It have been a while since I touched Lilypond because of new job, moving home etc. I'm excites version 2.18 is coming! I looked at the release notes at http://lilypond.org/doc/v2.17/Documentation/changes/index.html I don't see any mention of NullVoice http://lilypond.org/doc/v2.17/Documentation/internals/nullvoice For me, it's the feature I'm most excited about. Writing choral music with older versions of Lilypond was not a pleasant experience. I didn't have a chance to try NullVoice yet, but I'll try to test it. Could someone please write an example for the release notes? Also, this needs to be rephrased: The LilyPond syntax of dot-separated words Voice.Accidental has been made interchangeable with #'(Voice Accidental), a Scheme list of symbols. The change is not about accidentals, it's about everything! The example should be split from the summary: "The LilyPond syntax of dot-separated words has been made interchangeable with a Scheme list of symbols." The example for accidentals could be added to the examples for TextSpanner or omitted. Sorry for not being able to provide a proper patch at this time. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Conflicting dots and rests with partcombine and lyrics
Hello!
I'm typesetting a SATB score on two staves. I want to use partcombine
so that I can write the parts for each voice the way they supposed to
be sung. It's well known that partcombine doesn't work with the
lyrics, so I tried this workaround by Daniel E. Moctezuma
http://comments.gmane.org/gmane.comp.gnu.lilypond.general/73934
It turns out that the dots are positioned incorrectly, as the
transparent dots still take place and push the visible dots away. I
asked in lilypond-user but got no answer:
http://article.gmane.org/gmane.comp.gnu.lilypond.general/79243
So I implemented an engraver that kills transparent dots. It's good
enough for my purpose so far
(http://gitorious.org/lilypond-music/lilypond-music/blobs/c69aea3ddeecb92227544cf6c83a0fb513657a14/Popular/MyCountry.ly)
#(define-public (Hidden_dots_engraver ctx)
(make-engraver
(acknowledgers
((dots-interface trans dot source)
(if (eq? (ly:grob-property dot 'transparent) #t)
(ly:grob-suicide! dot))
\layout {
\context {
\Staff
\consists #Hidden_dots_engraver
}
}
However, it appears that rests need this treatment as well.
#(define-public (Hidden_voice_engraver ctx)
(make-engraver
(acknowledgers
((rest-interface trans rest source)
(if (eq? (ly:grob-property rest 'transparent) #t)
(ly:grob-suicide! rest)))
((dots-interface trans dot source)
(if (eq? (ly:grob-property dot 'transparent) #t)
(ly:grob-suicide! dot))
If there is a rest with dot, I get an error message:
programming error: unknown grob in dot col support
The result still looks good. Hopefully I can suppress the error
message by killing the dots before the rests, but I haven't tried it.
I just want to ask advice from the community whether I'm going in the
right direction. I dealt with engravers before, so it was a natural
choice for me. But maybe there is a better approach? Maybe it's
possible to write a music function that would turn the melody into a
rhythm that could be suppressed from the output? Or may it's possible
to do something to the dots and the rests to make the layout engine
ignore them completely?
I could make a snippet and post it to LSR. There is already a snippet
for the partcombine:
http://lsr.dsi.unimi.it/LSR/Snippet?id=653
But it lacks the comments and seems to deal with some other issues.
Also, it's not transparent. Some expressions need to be added to the
voice parts. I don't feel good about adding my code to the snippet I
don't understand.
--
Regards,
Pavel Roskin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Outdated help2man; avoiding needing to "build" help2man.pl
On Thu, 13 Sep 2012 14:51:53 -0700 Don Armstrong wrote: > In stepmake/stepmake/help2man-rules.make, I ran across the following: > > # We must invoke the generated $(outdir)/help2man script instead of > # the help2man.pl source, which means that the scripts/build directory > # must be built first. > # > # From the perlrun man-page: > # > # If the #! line does not contain the word "perl", the > # program named after the #! is executed instead of the Perl > # interpreter. This is slightly bizarre, but it helps > # > # Indeed it is. Perl sucks. > # > # Two screenfulls explaining that the otherwise standard #! is broken > # for perl, and arguing that this broken magic is better in some > # cases. Four more explaining what a line comment is, and that it may > # be parsed, same here. > > While it's correct, you can trivially work around this problem by > changing > > #!@PERL@ -w > > to > > #!@PERL@ -w > #! perl -w Considering the subsequent discussion, it's probably irrelevant to LilyPond. However, it's a bad idea to use an executable name without full path. See http://www.cyberciti.biz/tips/finding-bash-perl-python-portably-using-env.html So it should be #!/usr/bin/env perl -w -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stems
On Mon, 2 Jul 2012 16:45:12 +0100 "Phil Holmes" wrote: > http://code.google.com/p/lilypond/issues/detail?id=2427 links to an > example implementation of cross-staff stems done by Pavel. It's now > sort-of delivered as part of lilypond code, as a snippet in > snippets/new. AFAICS it's an almost perfectly workable > implementation. I think that an enhancement would be to remove the > flags for the crossing stems - they're never there (AFAICS) in real > music, and Gould shows the stems without flags. It's trivial to do > this by adding an override/revert to the crossStaff function. Sounds good to me. Perhaps we want to hide beams as well. > I don't see why this isn't implemented as a standard feature of > lilypond, instead of just being an example in a snippet that's not > even in the documentation. We have an issue for that: http://code.google.com/p/lilypond/issues/detail?id=2270 -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable release.
Quoting David Kastrup : For a source-only release, we are strictly restricted to problems occuring only with newer compiler versions. Other fixes would require a full rerelease including binaries. OK, that makes sense. It might be confusing for users to choose between an older binary and a newer source. So it's important to make it clear on the download page. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable release.
On Mon, 25 Jun 2012 17:07:38 +0200 David Kastrup wrote: > Since 2.14 is no longer able to compile on current versions of GCC, we > are getting to the situation where current GNU/Linux distributions are > no longer able to release _any_ stable version of LilyPond with > corresponding source code unless they patch the source themselves > (which kinda defeats the purpose of using a stable upstream version) > and/or juggle with compiler flags. That's a good idea. > It is a reasonably safe bet that we won't have a stable release 2.16 > in the next two months given our current release policies and policy > change policies and their past effects on release candidates. So it > is also a reasonably safe bet that we'll miss the respective freeze > windows of the autumn GNU/Linux releases. I believe it means that the policies should be adjusted. Maybe there should be a stable branch that would become 2.16. It's frustrating not to see the results of contributions for months or even years. > As a sort of emergency measure, I would consider it sensible if we > did a source-only release of 2.14.3 or, if you want to, 2.14.2a, the > same as 2.14.2 plus cherry-picked compilation fixes. Namely just > what it takes to get 2.14.2 through the current compilers. Let's not play games with the version numbers. 2.14.3 is what it should be. I believe there was a case when a GNU package was released with packaging problems (missing files or something). Then the fixed package was released with a letter "a" attached. But this would be a real maintenance release, so an incremented number would be appropriate. Please also consider including issue 2030, later re-reported as 2562. The fix is a straightforward backport. Perhaps there are more issues of that kind. We could include a couple of fixes. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond miscompiled on Fedora 17
On Sat, 9 Jun 2012 21:19:31 +0200 Frédéric Bron wrote: > I just installed fedora 17 x86_64. > After update, it comes with g++ 4.7.0-5 and lilypon 2.15.39. > Please find attached the output which looks good to me. Yes, it looks good. > Any idea why it does not come with a stable release (i.e. 2.14)? There was some minor issue with compiling Lilypond 2.14.2 with the latest gcc, so the Fedora maintainer decided to go with the unstable release, hoping that 2.16 would be released before Fedora 17. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Substitute for s1*0
On Sun, 06 May 2012 10:34:24 +0200
David Kastrup wrote:
> Quick: tell me what you would expect without too much thinking
> (imagine you are a naive user) from the following:
>
> \new Staff <<
> \relative c'' { c4 d e f s1*0-\markup Oops c d e f g1 } \\
A spacer 1 unit wide and 0 units high.
> \relative c' { c4 d e f <>-\markup Wow c d e f g1 }
A rhombus.
I'm fine with whatever works for now, but please keep in mind that
Lilypond it written not just for programmers.
--
Regards,
Pavel Roskin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Substitute for s1*0
Quoting Graham Percival : On Sun, May 06, 2012 at 08:58:11AM +0100, Trevor Daniels wrote: David Kastrup wrote Sunday, May 06, 2012 2:57 AM >In fact, isn't <> generally prettier than s1*0? Should we be using it >in code and documentation rather than s1*0? Definitely prettier, but maybe not so transparent as s1*0. +1 What about defining a null or n "note name"? Then we could write c4 n\footnote My preference is "z". There are fewer words that start with "z" than with "n" and it's easy to remember "z" as shorthand for "zero". Reusing symbols like "<" and ">" for new meanings would turn Lilypond sources into something like Perl. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond miscompiled on Fedora 17
Quoting David Kastrup : We can probably use yes:400600[0-2]) here: 4.6.3 is supposed to contain the fix. Thank you for opening a separate ticket for it (2514) and reviewing my ticket (2513)! -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond miscompiled on Fedora 17
Quoting David Kastrup : The optimizer does not appear interested in the result of the comparison when calculating the minimum value! There is no conditional path entered. That does not make all too much sense. That's a truly sharp eye! A diff between the i386 assembly without -fno-tree-vrp and with -fno-tree-vrp has following telltale lines: <->call<-->_ZN6Moment7compareERKS_S1_@PLT<># -.LVL11: -.LBE73: +.LVL9: .LBE72: .LBE71: +<->testl<->%eax, %eax<># D.35568 +<->movl<-->%esi, %eax<># , D.35564 +<->cmovns<>%edi, %eax<># tmp88,, D.35564 cmovns is "conditional move if not sign", exactly what we want. There is no similar code in the plain -O2 version. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond miscompiled on Fedora 17
Quoting David Kastrup : Now we just need to figure out which of the gazillion optimization options (listed in the assembly file) from O2 as compared to O1 makes the compilation go bad, and then we can add appropriate compiler options. We had to do this sort of $&!# already for gcc 4.6, so our configure tests are straightforward to fix once we know the option to switch off. That's it: `-ftree-vrp' Perform Value Range Propagation on trees. This is similar to the constant propagation pass, but instead of values, ranges of values are propagated. This allows the optimizers to remove unnecessary range checks like array bound checks and null pointer checks. This is enabled by default at `-O2' and higher. Null pointer check elimination is only done if `-fdelete-null-pointer-checks' is enabled. -fno-tree-vrp disables the optimization. Here's the preliminary patch. I'll submit it as an issue if you don't mind. Add -fno-tree-vrp to CXXFLAGS for gcc 4.7.0 That optimization breaks min() call in simultaneous-music-iterator.cc leading to bogus barcheck errors and incorrect output. --- stepmake/aclocal.m4 |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/stepmake/aclocal.m4 b/stepmake/aclocal.m4 index 8be2cab..42c65a5 100644 --- a/stepmake/aclocal.m4 +++ b/stepmake/aclocal.m4 @@ -287,12 +287,16 @@ AC_DEFUN(STEPMAKE_CXXTEMPLATE, [ ]) AC_DEFUN(STEPMAKE_GXXCODEGENBUG, [ -AC_MSG_CHECKING([options for known g++ tail call bug]) +AC_MSG_CHECKING([options for known g++ bugs]) case "$GXX:$CXX_VERSION" in yes:400600?) - AC_MSG_RESULT([-fno-optimize-sibling-calls]) + AC_MSG_RESULT([-fno-optimize-sibling-calls (tail call bug)]) CXXFLAGS="$CXXFLAGS -fno-optimize-sibling-calls" ;; + yes:400700?) + AC_MSG_RESULT([-fno-tree-vrp (comparison bug)]) + CXXFLAGS="$CXXFLAGS -fno-tree-vrp" + ;; *) AC_MSG_RESULT([none]) esac AC_SUBST(CXXFLAGS) -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond miscompiled on Fedora 17
Quoting David Kastrup :
Pavel Roskin writes:
Quoting David Kastrup :
That would have been my most likely guess. Probably the "min" function
call.
You are absolultely right! I was able to work around the gcc bug by
making a separate function for Moment comparison and using it instead
of min():
Moment
min_moment (Moment m1, Moment m2)
{
return min (m1, m2);
}
What happens if you declare this
(Moment const &m1, Moment const &m2)
The bug is present ("moving back in time")
I tried all combinations:
(Moment m1, Moment m2) - OK
(Moment m1, Moment const &m2) - OK
(Moment const &m1, Moment m2) - Bad
(Moment const &m1, Moment const &m2) - Bad
Maybe the produced code is not interested in the result because the
original value of next is infinite and gcc think that the comparison
only happens once per call? But then it would not call the compare
method.
Let me try to find the exact optimization flag responsible for the breakage.
--
Regards,
Pavel Roskin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond miscompiled on Fedora 17
Quoting David Kastrup :
That would have been my most likely guess. Probably the "min" function
call.
You are absolultely right! I was able to work around the gcc bug by
making a separate function for Moment comparison and using it instead
of min():
Moment
min_moment (Moment m1, Moment m2)
{
return min (m1, m2);
}
That's x64_64 assembly. Please let me know if you want i386 assembly.
Would definitely help with my limited vocabulary. This is enough of a
headacher without secondguessing the instruction set.
OK, I made files with -O1 and -O2 from the files that only differ in
that the "original" uses min() and the "workaround" uses min_moment().
Of the four files, simultaneous-music-iterator-O2-original.s is the
only one broken (I tested).
Please let me know it you need anything else.
--
Regards,
Pavel Roskin
simultaneous-music-iterator.tar.bz2
Description: application/bzip
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond miscompiled on Fedora 17
Quoting Pavel Roskin : Fedora 17 i386 has exactly the same problem. Let me try to find the file that needs to be compiled with -O1. I have some ideas how to bisect the problem. I want to write a wrapper around g++ that starts adding -O1 to the command line after N invocations. The problematic file is simultaneous-music-iterator.cc I'll try to identify the function tomorrow. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond miscompiled on Fedora 17
Quoting David Kastrup : Any chance to compile using i386? If the problem persisted, it would strongly point to the language frontend of g++ being involved. If it vanishes, it can be either the backend or a general 32/64 bit architecture problem. Fedora 17 i386 has exactly the same problem. Let me try to find the file that needs to be compiled with -O1. I have some ideas how to bisect the problem. I want to write a wrapper around g++ that starts adding -O1 to the command line after N invocations. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond miscompiled on Fedora 17
Quoting David Kastrup : Pavel Roskin writes: Hello! I mentioned in passing that Fedora 17 (currently in beta) ships Lilypond 2.15.29 that reports bogus bar checks. It turns out that both the current Lilypond from git and Lilypond 2.14.2 are miscompiled on the up-to-date Fedora 17 so they exhibit the same problem. What compiler version are they using? It's gcc 4.7.0. I'm using x86_64. I just checked that Lilypond compiled without optimization or with -O1 instead of -O2 has no problem with that file. An update for gcc was released this morning (gcc 4.7.0-3), and I compiled Lilypond with it with all defaults. Unfortunately, the problem persists. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond miscompiled on Fedora 17
Hello!
I mentioned in passing that Fedora 17 (currently in beta) ships
Lilypond 2.15.29 that reports bogus bar checks.
It turns out that both the current Lilypond from git and Lilypond
2.14.2 are miscompiled on the up-to-date Fedora 17 so they exhibit the
same problem.
That's the minimal example. It doesn't report a bar check, but it
shows an error:
\version "2.14.2"
\score {
<<
\new Staff { b2 }
\new Staff { b1 }
>>
\layout {}
}
$ lilypond barcheck.ly
GNU LilyPond 2.15.38
Processing `barcheck.ly'
Parsing...
Interpreting music...
programming error: moving backwards in time
continuing, cross fingers
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `barcheck.ps'...
Converting to `./barcheck.pdf'...
Success: compilation successfully completed
Attached is the output converted to png format.
Lilypond 2.14.2 reports the same error.
I tried compiling Lilypond with compat-gcc (version 3.4), but it
doesn't understand some compiler flags needed by Python.
--
Regards,
Pavel Roskin
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
add-grob-definition (was: measure counter engraver)
On Mon, 23 Apr 2012 21:01:10 -0500 David Nalesnik wrote: > Hi all, > > I've been experimenting with a way to create a measure-counter (issue > 2445), and I've come up with the attached Scheme engraver. The music > within a count doesn't need to be repeated to use it. > > This creates a new grob, MeasureCounter, which you can override in > various familiar ways. I was surprised that it's possible to create new grobs in Scheme! I looked for that functionality while writing cross-staff stem support and could not find it. I see that you copied add-grob-definition from scheme-text-spanner.ly. I believe add-grob-definition is so important that it should be a part of the Lilypond core. That's the only way to define a new grob in Scheme, and it gets copied from one snippet to another! I think the best place for add-grob-definition would be scm/translation-functions.scm next to make-engraver. I've opened an issue for that: http://code.google.com/p/lilypond/issues/detail?id=2503 -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
Quoting Carl Sorensen : Ordinarily something like this would go in the regression tests: input/regression/cross-staff-stem-engraver.ly And then you would add it to your git repository, and post it on Rietveld for a review. OK, I'll do it. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
Hello, Janek! Quoting Janek Warchoł : I'm attaching the Scheme code with a convoluted example (3 staves with 3 voices on each). I don't have the time to dive into details, but the output looks good! Be sure to post it on Rietveld for a review when you come back. Thank you for your appreciation! Sorry for delay - too little time and slow Internet here. Could you please explain how I can put a standalone file to Rietveld? I guess you mean that it should be added to Lilypond source? You mean the ly directory or some place in the documentation? -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
Hello! On Tue, 28 Feb 2012 15:14:29 -0800 Joe Neeman wrote: > Don't use ly:axis-group-interface::add-element, because stems don't > implement the axis-group-interface. (Removing this will also remove > the axes warning.) Instead, use ly:grob-set-parent!. You'll probably > want to set both the X parent and the Y parent. Then the X and Y > offsets of new-stem will be measured relative to stem (instead of > relative to the whole system, which is the default). OK, this is what I have now. I think it's a pretty good solution. The code is capable of creating multiple cross-staff stems per moment. It's possible to connect more than two stems as long as they lie on the same line. There is a workaround for a problem with Lilypond 2.14 that has a flag as part of the stem. I spent way too much time on the issue, but it helped me learn Scheme and Lilypond. I'll be on vacation next two weeks, so I'm not sure I'll be able to work on Lilypond. So I want to post my results. I tried posting this on LSR, but it won't accept it. I get a popup message saying "empty output from Lilypond" or something like that. I guess it's because LSR still runs Lilypond 2.12.x. Unfortunately, I have no time for backports. I'm attaching the Scheme code with a convoluted example (3 staves with 3 voices on each). The Scheme part is already used here: https://gitorious.org/lilypond-music/lilypond-music/blobs/master/Schubert/Die_Forelle.ly -- Regards, Pavel Roskin \version "2.14.2" % Values are close enough to ignore the difference #(define (close-enough? x y) (< (abs (- x y)) 0.0001)) % Combine a list of extents #(define (extent-combine extents) (if (pair? (cdr extents)) (interval-union (car extents) (extent-combine (cdr extents))) (car extents))) % Workaround for Lilypond 2.14 - calculate X-extent without the flag #(define (stem-x-extent stem) (let* ((extent (ly:grob-extent stem stem X)) (layout (ly:grob-layout stem)) (thickness (ly:grob-property stem 'thickness)) (thickness-unit (ly:output-def-lookup layout 'line-thickness))) (cons (car extent) (+ (car extent) (* thickness thickness-unit) % Check if the stem is connectable to the stem span #(define ((stem-connectable? ref anchor) stem) (cond ((inf? (car (ly:grob-extent stem ref X))) #f) ((not (close-enough? (car (ly:grob-extent anchor ref X)) (car (ly:grob-extent stem ref X #f) ((< 0 (* (ly:grob-property anchor 'direction) (- (car (ly:grob-extent anchor ref Y)) (car (ly:grob-extent stem ref Y) #f) (else #t))) % Connect stems if we have at least two visible stems and the anchor stem % is one of them #(define (stem-span-stencil span) (let* ((system (ly:grob-system span)) (anchor (ly:grob-parent span X)) (stems (filter (stem-connectable? system anchor) (ly:grob-object span 'stems (if (and (pair? stems) (pair? (cdr stems)) (memq anchor stems)) (let* ((yextents (map (lambda (st) (ly:grob-extent st system Y)) stems)) (yextent (extent-combine yextents)) (layout (ly:grob-layout anchor)) (blot (ly:output-def-lookup layout 'blot-diameter))) ; Hide spanned stems, but only if it won't hide flags (map (lambda (st) (if (close-enough? (cdr (stem-x-extent st)) (cdr (ly:grob-extent st st X))) (set! (ly:grob-property st 'transparent) #t))) stems) (ly:round-filled-box (stem-x-extent anchor) yextent blot)) #f))) % Create a stem span as a child of the cross-staff stem (the anchor) #(define ((make-stem-span! stems trans) anchor) (let* ((span (ly:engraver-make-grob trans 'Stem '( (ly:grob-set-parent! span X anchor) (set! (ly:grob-object span 'stems) stems) (set! (ly:grob-property span 'X-offset) 0) (set! (ly:grob-property span 'stencil) stem-span-stencil))) % Create stem spans for cross-staff stems #(define (make-stem-spans! ctx stems trans) (if (and (pair? stems) (pair? (cdr stems))) (let* ((anchors (filter (lambda (st) (ly:grob-property st 'cross-staff)) stems))) (map (make-stem-span! stems trans) anchors % Connect cross-staff stems to the stems above in the system #(define (Span_stem_engraver ctx) (let ((stems '())) `((acknowledgers (stem-interface . ,(lambda (trans grob source) (set! stems (cons grob stems) (process-acknowledged . ,(lambda (trans) (make-stem-spans! ctx stems trans) (set! stems '())) \layout
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
Quoting Joe Neeman :
I'm getting a message "Weird stem", and I don't see how to avoid it.
Perhaps I should create a totally new grob with a unique name, such as
StemSpan. Is that possible? What would be needed?
It would be nice to do this eventually, because having a different grob
name would make it easier for the users to tweak it. I think it would
involve editing scm/define-grobs.scm, but there may be a way to do it from
an .ly file also
It turn out the message comes from ly:stem::offset-callback and can be
suppressed by redefining X-offset.
Don't use ly:axis-group-interface::add-element, because stems don't
implement the axis-group-interface. (Removing this will also remove the
axes warning.) Instead, use ly:grob-set-parent!. You'll probably want to
set both the X parent and the Y parent. Then the X and Y offsets of
new-stem will be measured relative to stem (instead of relative to the
whole system, which is the default).
That was it! I have a working solution now! It will need to be
improved to ignore rests and other invisible stems, check the
cross-staff property, avoid connecting incompatible stems and so on.
The old stems should be made transparent. But all that should be
simple. Once I have something easy to use, I plan to submit it to the
LSR.
Actually, it looks like System is a better Y-parent for the new stem.
Perhaps I'll try to use the common reference of the stems to be
connected.
Here's what I have now (attached).
Thank you for your help!
--
Regards,
Pavel Roskin
\version "2.14.2"
#(define (extent-combine extents)
(if (pair? (cdr extents))
(interval-union (car extents) (extent-combine (cdr extents)))
(car extents)))
#(define (stemSpanExtent grob)
(let* ((yref (ly:grob-parent grob Y))
(stems (ly:grob-object grob 'spanned-stems))
(extents (map (lambda (x) (ly:grob-extent x yref Y)) stems))
(maxextent (extent-combine extents)))
maxextent))
#(define (stemSpanStencil grob)
(let* ((stem (car (ly:grob-object grob 'spanned-stems)))
(xextent (ly:grob-extent stem stem X))
(yextent (stemSpanExtent grob)))
(make-filled-box-stencil xextent yextent)))
#(define (reparentStems ctx stems trans)
(if (and (pair? stems)
(pair? (cdr stems)))
(let* ((stem (car stems))
(new-stem (ly:engraver-make-grob trans 'Stem '(
(ly:grob-set-parent! new-stem X stem)
(set! (ly:grob-object new-stem 'spanned-stems) stems)
(set! (ly:grob-property new-stem 'X-offset) 0)
(set! (ly:grob-property new-stem 'stencil) stemSpanStencil
#(define (Cross_staff_stem_engraver ctx)
(let ((stems '()))
`((acknowledgers
(stem-interface
. ,(lambda (trans grob source)
(set! stems (cons grob stems)
(process-acknowledged
. ,(lambda (trans)
(reparentStems ctx stems trans) (set! stems '()))
\layout {
\context {
\PianoStaff
\consists #Cross_staff_stem_engraver
}
}
\new PianoStaff <<
\new Staff { \stemUp g'4 a' \stemDown c' }
\new Staff { \stemUp f'4 e' \stemDown c''' }
>>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
Hello, Joe!
> In case it wasn't clear from what I said before, engravers in lilypond
> don't do the actual layout. Instead, they build the grobs and set up
> the connections between them. Most of the layout is done in callback
> functions.
Yes, I realize it now. Your suggestion to create a new stem worked
fine. I can get the relative coordinates of themes on different staves.
The attached file shows where I am now. There are many minor issues,
and I hope I can solve most of them, but I'll certainly appreciate help.
I'm getting a message "Weird stem", and I don't see how to avoid it.
Perhaps I should create a totally new grob with a unique name, such as
StemSpan. Is that possible? What would be needed?
How do I make the new stem start at the same point as the original
one. I tried this:
(set! (ly:grob-property stem 'axes) (list X))
I don't understand how it works. Not setting axes leads to:
programming error: axes should be nonempty
Maybe I should use some other parent for the new stem?
The new stems are offset horizontally on purpose to see where they
are. But the vertical position is wrong and I don't see how to fix it.
I'll appreciate if you have a look at the code.
--
Regards,
Pavel Roskin
\version "2.14.2"
#(define (grobParentByInterface grob intf axis)
(if (memq intf (ly:grob-interfaces grob))
grob
(grobParentByInterface (ly:grob-parent grob axis) intf axis)))
#(define (extent-combine extents)
(if (pair? (cdr extents))
(interval-union (car extents) (extent-combine (cdr extents)))
(car extents)))
#(define (crossStaffLength grob)
(let* ((papercolumn (grobParentByInterface grob 'paper-column-interface X))
(elementarray (ly:grob-object papercolumn 'elements))
(yref (ly:grob-common-refpoint-of-array grob elementarray Y))
(elements (ly:grob-object grob 'spanned-stems))
(extents (map (lambda (x) (ly:grob-extent x yref Y)) elements))
(foo (ly:message "extents: ~a" extents))
(maxextent (extent-combine extents))
(foo (ly:message "maxextent: ~a" maxextent))
(length (- (car maxextent) (cdr maxextent
length))
#(define (stemSpanStencil grob)
(let* ((length (crossStaffLength grob)))
(make-filled-box-stencil '(0.2 . 0.4) (cons 0 length
#(define (reparentStems ctx stems trans)
(if (and (pair? stems) (pair? (cdr stems)))
(let* ((stem (car stems))
(parent (ly:grob-parent stem Y))
(new-stem (ly:engraver-make-grob trans 'Stem '(
(ly:message "stems: ~a" stems)
(ly:message "new-stem: ~a" new-stem)
(set! (ly:grob-property stem 'axes) (list X))
(ly:axis-group-interface::add-element stem new-stem)
(set! (ly:grob-object new-stem 'spanned-stems) stems)
(set! (ly:grob-object new-stem 'Y-offset) 5)
(set! (ly:grob-property new-stem 'stencil) stemSpanStencil)
(set! (ly:grob-property new-stem 'length) crossStaffLength
#(define (Cross_staff_stem_engraver ctx)
(let ((stems '()))
`((acknowledgers
(stem-interface
. ,(lambda (trans grob source)
(set! stems (cons grob stems)
(process-acknowledged
. ,(lambda (trans)
(reparentStems ctx stems trans) (set! stems '()))
\layout {
\context {
\PianoStaff
\consists #Cross_staff_stem_engraver
}
}
\new PianoStaff <<
\new Staff { \stemUp g' a' b' c'' }
\new Staff { \stemUp f' e' r }
>>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
Quoting Joe Neeman :
The problem is where you ask for the stem Y-extent relative to yref (the
VerticalAlignment): in order to calculate the vertical distance between the
various staves and the VerticalAlignment, line breaking needs to be done
first. (And line breaking doesn't happen until after all the engravers are
done.)
I see. It means that using an engraver it not a solution per se.
Good to know.
I guess I'll need to redefine the stencil for stems. Or maybe you mean
some other callback?
You could redefine stencil, but I think redefining length would be easier.
Of course, that's why I tried it first :)
Can you be more specific about the Y-extent not being calculated yet? When
you ask for the Y-extent, the calculation should be triggered if it hasn't
already happened.
Now I understand what's going on! Apparently this triggering is not
transitive (which is reasonable). I'm attaching the minimal example
when I get
grob Y-extent: (+inf.0 . -inf.0)
I think it should be possible to work around. I'll be perfectly fine
if my code doesn't work with chords spanning three and more staves if
that limitation needs to exist.
As a general approach, setting length sounds like a reasonable way forward.
In addition, I'd suggest creating a new stem in process-acknowledged, then
doing
(set! (ly:grob-object new-stem 'spanned-stems) old-stems)
(set! (ly:grob-property new-stem 'length) your-length-callback)
In your length callback, you read back the spanned-stems object and do your
calculations. Is this similar to what you tried?
I never used an engraver and the length override at the save time.
When doing the length override, I tried this approach:
- find PaperColumn among the grob parents
- scan its elements for stems
- use stems extents to find stems connectable to the given stem
- find the closest stem
- use the length that would extend the given stem to the closest stem
It actually worked, except some corner cases. Now I understand why.
Using an engraver to catch the stems sounds like a good approach. I
could even do some filtering in the engraver. And it should be
possible to replace stems with one rather than connect them together.
It would simplify SVG output, and I suspect the connect point could be
seen in some renderings of the postscript output.
Thank you for your help! I'm getting really close!
--
Regards,
Pavel Roskin
\version "2.14.2"
#(define (grobParentByInterface grob intf axis)
(if (memq intf (ly:grob-interfaces grob))
grob
(grobParentByInterface (ly:grob-parent grob axis) intf axis)))
#(define (crossStaffLength grob)
(let* ((papercolumn (grobParentByInterface grob 'paper-column-interface X))
(elementarray (ly:grob-object papercolumn 'elements))
(elements (ly:grob-array->list elementarray)))
(map (lambda (x)
(ly:grob-extent x x Y)) elements)
(ly:message "grob Y-extent: ~a" (ly:grob-extent grob grob Y))
3))
\score {
\new StaffGroup <<
\new Staff = "staffone" <<
\new Voice {
c'
}
>>
\new Staff = "stafftwo" <<
\new Voice {
\clef bass
\override Stem #'cross-staff = ##t
\override Stem #'length = #crossStaffLength
c
}
>>
\new Staff = "staffthree" <<
\new Voice {
\override Stem #'cross-staff = ##t
\override Stem #'length = #crossStaffLength
\clef bass
g,
}
>>
>>
\layout { }
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
Quoting Joe Neeman :
On Fri, Feb 24, 2012 at 3:04 PM, Pavel Roskin wrote:
I tried writing an engraver that could be added to the StaffGroup
context. Collecting stems is not a problem. The problem is that even
the finalize handler is called to early. I'm getting a warning:
programming error: vertical alignment called before line breaking
continuing, cross fingers
It's a little hard to guess what's going wrong without knowing exactly what
you've tried. Are you trying to do layout logic in the engraver (ie. by
collecting stems, reading their properties, doing calculations and then
setting more properties)?
Yes, except that I'm not setting anything yet. The current file is attached.
If you are, the first step is to move the layout
logic into grob callbacks.
I guess I'll need to redefine the stencil for stems. Or maybe you
mean some other callback?
I did a similar thing before. I put all the logic into a function
that was used to redefine the length property of the stem. It worked
for a simple case of two stems, but failed when three stems needed to
be connected. The Y-extent for at least one of the stems wasn't
calculated yet.
I also tried setting Y-extent, but it's read-only.
--
Regards,
Pavel Roskin
\version "2.14.0"
#(define ((connectableStem? xref yref stemone dir below?) stemtwo)
(cond
((not (memq 'stem-interface (ly:grob-interfaces stemtwo))) #f)
((equal? stemone stemtwo) #f)
((inf? (car (ly:grob-extent stemtwo xref X))) #f)
((not (equal? (ly:grob-extent stemone xref X) (ly:grob-extent stemtwo xref X))) #f)
((not (equal? dir (ly:grob-property stemtwo 'direction))) #f)
((below? (car (ly:grob-extent stemtwo yref Y)) (car (ly:grob-extent stemone yref Y))) #f)
(else #t)))
#(define ((lowerStem? ref below?) lower upper)
(below? (car (ly:grob-extent lower ref Y)) (car (ly:grob-extent upper ref Y
#(define (crossStaffLength grob ctx stems)
(let* ((papercolumn (ly:context-property ctx 'currentMusicalColumn))
(foo (ly:message "papercolumn: ~a" papercolumn))
(xref (ly:grob-common-refpoint grob (car stems) X))
(foo (ly:message "xref: ~a" xref))
(yref (ly:grob-common-refpoint grob (car stems) Y))
(foo (ly:message "yref: ~a" yref))
(dir (ly:grob-property grob 'direction))
(below? (if (= dir UP) < >))
(foo (ly:message "stems: ~a" stems))
(goodstems (filter (connectableStem? xref yref grob dir below?) stems))
(foo (ly:message "stems1: ~a" stems))
(beststems (sort goodstems (lowerStem? yref below?)))
(foo (ly:message "stems2: ~a" stems))
(peer (car (append beststems (list grob
(foo (ly:message "peer: ~a" peer)))
(ly:message "grob: ~a" (ly:grob-extent grob yref Y))
(ly:message "peer: ~a" (ly:grob-extent peer yref Y))
(if (equal? grob peer)
(begin (ly:programming-error "No suitable stem to connect to") 4)
(if (> dir 0)
(* 2 (- (car (ly:grob-extent peer yref Y))
(car (ly:grob-extent grob yref Y
(* 2 (- (cdr (ly:grob-extent grob yref Y))
(cdr (ly:grob-extent peer yref Y
#(define (connectStems ctx stems)
(ly:message "stems: ~a" stems)
(if (and (pair? stems) (pair? (cdr stems)))
(let ((stem (car stems))
(otherstems (cdr stems)))
(ly:message "otherstems: ~a" otherstems)
(ly:message "length: ~a"
(crossStaffLength stem ctx otherstems)
#(define (Cross_staff_stem_engraver ctx)
(let ((stems '()))
`((acknowledgers
(stem-interface
. ,(lambda (trans grob source)
(ly:message "acknowledger: ~a" grob)
(set! stems (cons grob stems
(note-column-interface
. ,(lambda (trans grob source)
(ly:message "acknowledger: ~a" grob
(process-music
. ,(lambda (trans) (ly:message "process-music") (connectStems ctx stems)))
(process-acknowledged
. ,(lambda (trans) (ly:message "process-acknowledged")))
(stop-translation-timestep
. ,(lambda (trans) (ly:message "stop-translation-timestep") (connectStems ctx stems)))
(finalize
. ,(lambda (trans) (ly:message "finalize") (connectStems ctx stems))
\layout {
\context {
\StaffGroup
\consists #Cross_staff_stem_engraver
}
}
\new StaffGroup <<
\new Staff { g' }
\new Staff { c' }
>>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Cross-staff stem engraver (was: New frog in an empty pond?)
Hello! I'm moving the thread to lilypond-devel and changing the subject. I hope it's OK. On Thu, 23 Feb 2012 15:37:02 + Neil Puttock wrote: > On 23 February 2012 15:18, Pavel Roskin wrote: > > > I actually wanted to make a stopgap solution in Scheme. I wrote > > some code that looks for other stems and sets the stem length so it > > would touch the stem above (attached). But the code is unreliable. > > Some stems are not calculated yet. > > I'd love to be proven wrong, but I don't think you'll have much > success with this approach. At the very least, you'll need a Scheme > engraver at the correct context level to collect the stems at the > right time. If a simple length override were possible with the > current infrastructure, we wouldn't need a Span_arpeggio_engraver to > typeset cross-staff arpeggios. I tried writing an engraver that could be added to the StaffGroup context. Collecting stems is not a problem. The problem is that even the finalize handler is called to early. I'm getting a warning: programming error: vertical alignment called before line breaking continuing, cross fingers Even though the common reference for the Y axis for the stems is a valid grob of type VerticalAlignment, the Y-extents don't reflect the distance between staves. The code for cross-staff arpeggios (span-arpeggio-engraver.cc) only collects data about stems and lets the standard arpeggio code (arpeggio.cc) draw the cross-staff arpeggio. If I understand correctly, an equivalent of that for stems would require modification to the stem engraver so that it would draw cross-staff stems. As for the grid lines, there are actually two engravers. One makes the points (GridPoint) and the other connects them (GridLine). GridPoint should be hopefully irrelevant, as we have stems for that. Printing grid lines is implemented in grid-line-interface.cc. As I understand, it's not an engraver (that would be grid-line-span-engraver.cc), it's an interface. I checked the Scheme implementation of ambitus engraver. It relies on existing implementations of AmbitusLine and other grobs. The placement is done in finalize, but ambitus is not cross-staff, so there is no issue with undefined staff-staff spacing. I guess I need to rely on an existing grob that supports cross-staff placement to draw the stem if I want to keep my modification in Scheme. Perhaps I'll try GridLine, as Arpeggio would need bogus stems and bogus noteheads to appear where I want it to be. BarLine also seems to be too sophisticated for the job. Maybe there is an example of grob definition in Scheme? I'll appreciate comments that would steer me away from dead ends. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: recommend setting ragged-last-bottom to false for large scores(issue 5651077)
Quoting Phil Holmes : - Original Message - From: To: Cc: ; Sent: Friday, February 17, 2012 12:21 PM Subject: Doc: recommend setting ragged-last-bottom to false for large scores(issue 5651077) This has been accepted; Pavel, please send the final patch to somebody (not me) for pushing. Hopefully you have a mentor? Maybe Janek? http://codereview.appspot.com/5651077/ I have no mentor and I could not figure out from CG how to get one (I didn't read the whole CG). I've just subscribed to the frogs list. Perhaps that's the place to look for mentors? As a side effect of reading the CG, I found a simplified procedure for submitting trivial documentation changes, and I'm going to use it from now on. Janek is away until after Sunday. Pavel - please feel free to send it to me if you want it pushed sooner. I'm not in a hurry at all. I'm not sure what needs to be sent. It's a one word change after all. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dubious recommendation about ragged-last-bottom in spacing.itely
Quoting David Kastrup : Pavel Roskin writes: Speaking of the defaults, the default system-to-system distance is too short for my taste. It may be OK it would save a page turn. However, it's used on the last page with ragged-last-bottom=#t even if there is enough space on the page to use the same system-to-system distance as on the previous page. Often the last page has the worst layout compared to previous pages. Huh? http://code.google.com/p/lilypond/issues/detail?id=1377> Fixed_2_15_23 Indeed, I confirm it. I still use Lilypond 2.14.2 for scores I intend to submit to Mutopia, so I remembered that the last pages didn't look good. So I checked the documentation about ragged bottom and found that it should be true. It just occurred to me recently that the documentation likely meant "false". By the way, the documentation still needs to be updated: http://lilypond.org/doc/v2.15/Documentation/notation/flexible-vertical-spacing-_005cpaper-variables If a page has a ragged bottom, the resulting distance is the largest of: basic-distance, minimum-distance, and padding plus the smallest distance necessary to eliminate collisions. Not anymore, and it's a good thing! -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dubious recommendation about ragged-last-bottom in spacing.itely
Quoting David Kastrup : 2012/2/10 Pavel Roskin : I believe the opposite should be suggested. Large scores should set ragged-last-bottom to false. For a large score, it's easy to fill a whole number of pages without much distortion. Doing so increases readability of the piece without increasing the number of the page turns. It depends on how well our penalty system works. If you fill three pages anyway, you want your breaks at places where a page turn makes good sense. Even if one page is short. If LilyPond has no way to figure out one page break being better than another, it might as well spread the material evenly over pages. But other than that, I don't see that filling the last page should necessarily "increase readability". Just having choices #f and #t is also not really optimal. I agree that having more choices would be good. But since there is a suggestion in the documentation, let's suggest the best of what we can offer. Now that the issue 2102 has been fixed, ragged-last-bottom=#f can be a reasonable suggestion for large pieces with no manual page breaks. It's still a suggestion; it can be safely ignored. It's not even the default. Speaking of the defaults, the default system-to-system distance is too short for my taste. It may be OK it would save a page turn. However, it's used on the last page with ragged-last-bottom=#t even if there is enough space on the page to use the same system-to-system distance as on the previous page. Often the last page has the worst layout compared to previous pages. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Dubious recommendation about ragged-last-bottom in spacing.itely
Hello! There is a strange suggestion in Documentation/notation/spacing.itely: @item ragged-last-bottom @funindex ragged-last-bottom If set to false, systems will spread vertically down the last page. Pieces that amply fill two pages or more should have this set to true. I believe the opposite should be suggested. Large scores should set ragged-last-bottom to false. For a large score, it's easy to fill a whole number of pages without much distortion. Doing so increases readability of the piece without increasing the number of the page turns. I checked some scores on imslp.org, and I don't see many "ragged bottoms" at the end of many serious works. I suggest changing "true" to "false". I believe it was meant that way by the author of the text. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Documentation about unpure-pure containers is unclear
Hello!
The issue 2275 has "Patch-needs_work" now. I guess the needed work is
asking some questions in the list, so that the documentation becomes
easier to understand and the example would actually illustrate it.
This is the page I'm taking about:
http://lilypond.org/doc/v2.15/Documentation/notation/unpure_002dpure-containers
Quote:
"When a function overrides a Y-offset and/or Y-extent it is assumed that
this will trigger line breaking calculations too early during
compilation. So the function is not evaluated at all"
squareLineCircleSpace doesn't override Y-offset or Y-extent, yet the
output is ugly. Why?
Why do stems have to be hidden? Do they force calculations that would
otherwise be delayed? Or do they reserve horizontal space that the
noteheads with overridden stencil won't reserve?
Why is this showing correct output?
roundNotes = {
\override NoteHead #'stencil = #(make-circle-stencil 0.5 0.1 #f)
}
smartRoundNotes = {
\roundNotes
\override NoteHead #'Y-extent =
#(ly:make-unpure-pure-container
ly:grob::stencil-height
(lambda (grob start end) (ly:grob::stencil-height grob)))
}
\new Voice
\relative c'' {
\time 4/1
\roundNotes
cis1 ces cisis c
\smartRoundNotes
cis1 ces cisis c
}
And why does the output break if roundNotes is rewritten with a
lambda?
roundNotes = {
\override NoteHead #'stencil =
#(lambda (grob) (make-circle-stencil 0.5 0.1 #f))
}
What's so different between the above stencil definitions? Does
Lilypond actually try to classify functions as pure and unpure by
parsing them?
--
Regards,
Pavel Roskin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Spelling fixes
On Fri, 20 Jan 2012 17:58:47 +0100 Stefan Weil wrote: > Hi, > > my last two patches were sent inline (with git send-email), > but I just learned that they should have been appended instead. > > So here are both patches again. Both fix some spelling issues. By the way, somebody please run codespell on the Lilypond sources: http://git.profusion.mobi/cgit.cgi/lucas/codespell/ It find so much stuff that perhaps somebody with commit access and good knowledge of the code could do it more effectively without bothering others. It's funny that codespell even found a mistake in German text (Probelm). There are some false positives, such as upto, portugues and \openin. Also, we probably don't want to fix old changelogs. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: suggestion - increase default beam thickness
On Tue, 10 Jan 2012 22:36:41 +0100 Janek Warchoł wrote: > Good point, your concerns are valid. However, the difference between > current Lily default beam thickness and average calculated from > samples is so big (almost 0.1 staffspace), that i think we don't have > to worry about this. Also, the change i suggest is small - only 0.03 > staffspace thicker. You may want to go all the way to the measured values if your measurement are based on valid methods. Even thickness of 0.6 looks reasonable to my eyes. But what really matters is the eyes of musicians, and I'm not one (even though I'm taking voice lessons). > Of course, i invite you all to print Lily-engraved scores with default > settings and with beam thickness changed to 0.51. I only want to warn > you that these results might be prone to similar problems: when some > time ago i compared a printout of Lily-made pdf with an older > printout, i was surprised to see significant difference in thickness > of everything (i estimate it was something like 0.04-0.06 ss). And > both copies were printed with the same printer, the only difference > was the cartridge! Thicker beams look better for me, both on screen and when printed. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc search: update to version 2.15, use it in the "site:" part (issue 5530043)
Quoting Graham Percival : On Mon, Jan 09, 2012 at 02:10:24PM +, plros...@gmail.com wrote: I totally share your sentiment, but we depend on an external entity here, which we cannot control. Suppose we go from 2.15.x to 2.17.x and put the documentation under "v2.17". For some time, Google won't have the new location in its index, so the search would get nothing. It would be better to keep "v2.15" in the search for a while and have a redirection from "v2.15" to "v2.17". Great point! Could you add a comment to this effect to the top of this file? there's no way that I'll remember otherwise. I believe the comment belongs to some other file that describes the release process. If we keep things as is, the version change in the search would need to be done some time after the release. I don't know how fast Google would index the new pages. In the ideal case (which means changing the site layout), everything should be done at the time of the release and no "alarms" should be needed for additional changes. Speaking of redirections, I would prefer that Lilypond had just two versions of its documentation online - latest "stable" and latest "development". "v2.12" and "v2.14" shoould redirect to "stable", "v2.15" should redirect to "development". We want to keep all stable docs available for historical reasons, but I'm not opposed to directing people to /doc/stable/ /doc/development/ rather than vX.Y. If you feel like looking into this, the htaccess is in Documentation/web/server/ When searching for Lilypond related topics on Google, I constantly get directed to v2.12 unless I add "v2.15" to the search line. But I often want to find information both on the Lilypond site and elsewhere, so adding "v2.15" would lose the external links. I'm not against hosting historic documentation, but it would be nice to "deemphasize" is somehow. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: suggestion - increase default beam thickness
On Sat, 7 Jan 2012 01:54:06 +0100 Janek Warchoł wrote: > W dniu 7 stycznia 2012 01:40 użytkownik Carl Sorensen > napisał: ... > > Are you measuring staff space in pixels from the top of one staff > > line to the top of the next staff line? > > Yes, exactly like that. I was often measuring one sample in several > places (and estimating an average) because the shapes are not perfect. Comparing scanned data to internal numbers is not a fair comparison. When scanning, the lines can get blurred and then they are converted to black-and-white based on the darkness settings. Lines can get thicker or thinner. The most fair comparison would be between the original score on paper and the score produced by Lilypond, also printed on paper. You may need a microscope to measure the widths. As an alternative to the microscope, you can compare scanned scores, but only if both scores were scanned by the same scanner with the same settings. Also, the scans should be grayscale or better, not black-and-white, so that you can measure the human-perceived width rather than a computer-calculated boundary that can be affected by the color of the paper and the ink. This way, you would be using the same method to measure the original and the new data. Lilypond should imitate printed scores, not scanned scores. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Need real cross-staff chords
Quoting Carl Sorensen : Oops, no. I forgot to mention that you should also set padding to be something like -minimum-distance, or in your example -9. That works! The staves will now be fixed, but you will need to makesure to leave enough space for dynamics, etc. Absolutely. I just don't want to replace something that is glued together, albeit in an ugly way, with something that is not glued together at all. I'm sorry I forgot about the negative padding value that is also needed. No problem. I'll be able to finish my conversion now. I'm also going to file a bug report, as using negative padding is very counterintuitive. How ironic is that I participated yesterday in the naming context for non-negative integers :) -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Need real cross-staff chords
Quoting Janek Warchoł : Hi Pavel, 2012/1/7 Pavel Roskin : I believe it would be nice to have support for cross-staff chords. Perhaps it could be done as another snippet. I'm a beginner in Scheme and Lilypond, so it takes me quite a lot of effort. I'll appreciate some help. I envision having a Scheme function that would apply to some notes in the chord: I wish that i could help you doing this, but it's beyond my knowledge. I have a suggestion for the future syntax, though - i think it would be best to define cross-staff chords like cross-staff voices, i.e. use \change Staff = StaffName inside chord construct: I actually tried it and it didn't work. I think implementing this approach in Scheme may be harder, as I would need to redefine \change (or catch for staff change events or something as hairy as that) rather than write a new function. You may consider writing a brief feature request that would be added to our tracker (http://code.google.com/p/lilypond/issues/list), so that this issue doesn't get lost. (send the feature request to bug-lilypond) I will. We have a good reason to want cross-staff chords rather than a fragile imitation that can only be held together by hacks involving negative padding :) -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Need real cross-staff chords
Quoting Carl Sorensen :
There is no "forced-distance" now. I can use "minimal-distance", but
there is no guarantee that Lilypond won't increase the distance between
staves. And Lilypond may do it because of something in another measure.
You can get a fixed distance by setting minimal-distance = basic-distance,
and stretchability = 0.
Thank you, Carl! It would be an acceptable solution, even though not
the best one. However, it's not working for me. Even simple dynamics
can break everything. This is the "snippet" approach for a change.
The gap between staves is wider and the stems are broken in the second
measure. Perhaps I misunderstood your suggestion?
\version "2.14.2"
\score {
<<
\new PianoStaff <<
\new Staff = right {
\override Stem #'length = #22
\override Stem #'cross-staff = ##t
\override Stem #'Y-offset = #-6
b4 b4 b4 b4 \break |
b4_\< b4\! b4 b4 |
}
\new Staff = left {
\override Stem #'stencil = ##f
\clef bass c4 c4 c4 c4 |
c4 c4 c4 c4 |
}
>>
>>
\layout {
\context {
\Staff
\override VerticalAxisGroup #'staff-staff-spacing =
#'((basic-distance . 9)
(minimum-distance . 9)
(padding . 1)
(stretchability . 0))
}
}
}
--
Regards,
Pavel Roskin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Need real cross-staff chords
Hello!
I just wanted to update one song (Schubert's "Die Forelle") on Mutopia
from Lilypond 2.4 to 2.14.2.
Most stuff could be updated easily. It's great that some overrides
could even be removed. However, there is one "regression" when I cannot
do something with the new Lilypond.
In some places, there are cross-staff chords, i.e. chords with
noteheads placed on both piano staves.
Lilypond documentation suggests making the stems on the lower
staff longer so they meet the stems on the upper staff:
http://lilypond.org/doc/v2.15/Documentation/notation/common-notation-for-keyboards#cross_002dstaff-stems
There is also a snippet that suggest lowering the stems:
http://lsr.dsi.unimi.it/LSR/Snippet?id=770
The problem is that both approaches depend on the ability to fix the
distance between staves, which existed in Lilypond 2.4 both doesn't
seem to exist now. The original file used:
\context {
\PianoStaff
\accepts Dynamics
\override VerticalAlignment #'forced-distance = #7
}
There is no "forced-distance" now. I can use "minimal-distance", but
there is no guarantee that Lilypond won't increase the distance between
staves. And Lilypond may do it because of something in another measure.
I can typeset the score, but I'll make it more fragile. I'm guilty of
omitting some niceties from other scores, but in this case I'm going to
update the existing score, so I don't want any regressions, even
potential ones.
This file illustrates the problem:
\version "2.14.2"
\score {
<<
\new PianoStaff
<<
\new Staff = right {
b4 b4 b4 b4 \break |
c,4 b4 b4 b4 |
}
\new Staff = left {
\override Stem #'length = #16
\override Stem #'cross-staff = ##t
\clef bass c4 c4 c4 c4 |
r4 c4 c4 c4 |
}
>>
>>
\layout { }
}
A low note breaks the stems apart. I used extra length for the stems
to have some overlap, but it created another problem. It can be seen
that the stems below F on the upper staff are slightly thicker than
above. It's seen in the PDF viewer only with some zoom settings. I
believe the stem is drawn twice, so if any antialiasing is used to
display it, the antialiased pixels get darker where they overlap.
The overlap problem can be solved by lowering the stems as in the LSR
snippet. However, the snippet uses some calculations that are based on
staff-staff distance, so stems would get detached from the lower notes
if that distance increases.
I believe it would be nice to have support for cross-staff chords.
Perhaps it could be done as another snippet. I'm a beginner in Scheme
and Lilypond, so it takes me quite a lot of effort. I'll appreciate
some help.
I envision having a Scheme function that would apply to some notes in
the chord:
The crossStaff function would thus get the note grob as the argument.
One approach would be to "reparent" the notehead to another staff
context. I have no idea if that's possible. I would need to find the
PianoStaff (or GrandStaff) context from the grob, find the other Staff
and tell Lilypond that the notehead should sit there. Hopefully, no
voices on the other staff would need to be used.
Another approach would be to do more manual work, namely hide the
notehead, draw it on the other staff (considering the middle C
position) and extend the beam downwards. I'll need a way to find
the actual distance between staves in the given point. I've been
struggling to get that number, but I only managed to get the default
numbers and obscure functions (probably not to be called by my
snippet). I believe I need to find the grob for the staff, but I don't
see any way to do it starting from the grob for the note.
I'll appreciate any suggestions.
--
Regards,
Pavel Roskin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Documentation search - update version and Google syntax
On Thu, 5 Jan 2012 07:04:22 + James wrote: > Thanks, I figured it was something like that, but the gmail web client > doesn't seem to let me save this off separately (i've not worked out > how so far) so I was reluctant to cut/paste. OK, I'm sending the patch as an attachment, and I'll send attachments from now on. Thanks for the link! It's pretty impressive to have such a long guide for contributors! I'll use it if I ever contribute something less trivial. -- Regards, Pavel Roskin Doc search: update to version 2.15, use it in the "site:" part From: Pavel Roskin site:lilypond.org/doc/v2.15 means that we want to look only under that directory. Leading plus doesn't force the exact search anymore. --- Documentation/search-box.ihtml |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/search-box.ihtml b/Documentation/search-box.ihtml index d789109..1c9ceb4 100644 --- a/Documentation/search-box.ihtml +++ b/Documentation/search-box.ihtml @@ -1,11 +1,11 @@ http://google.com/search"; method="get" name="search" - onSubmit="search.q.value='site:lilypond.org +v2.14 ' + onSubmit="search.q.value='site:lilypond.org/doc/v2.15 ' + search.brute_query.value" - onMouseMove="search.q.value='site:lilypond.org +v2.14 ' + onMouseMove="search.q.value='site:lilypond.org/doc/v2.15 ' + search.brute_query.value" - onKeyUp="search.q.value='site:lilypond.org +v2.14 ' + onKeyUp="search.q.value='site:lilypond.org/doc/v2.15 ' + search.brute_query.value"> ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Documentation search - update version and Google syntax
Hello! There are two issues with the search box in the online documentation. One is that search in v2.15 documentation adds +v2.14 to the Google search, so it look in the older documentation. The other is that "+" doesn't have the old meaning since the introduction of Google Plus. To ensure that "v2.15" appears on the page or in the URL, it should be added in quotes. A simpler alternative would be to use this in the search: site:lilypond.org/doc/v2.15 That would tell Google to search documents only under lilypond.org/doc/v2.15, which is probably our intention. Here's the patch. Please let me know if a sign off or something like that is needed. It's my first ever patch for LilyPond. Doc search: update to version 2.15, use it in the "site:" part site:lilypond.org/doc/v2.15 means that we want to look only under that directory. Leading plus doesn't force the exact search anymore. --- Documentation/search-box.ihtml |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/search-box.ihtml b/Documentation/search-box.ihtml index d789109..1c9ceb4 100644 --- a/Documentation/search-box.ihtml +++ b/Documentation/search-box.ihtml @@ -1,11 +1,11 @@ http://google.com/search"; method="get" name="search" - onSubmit="search.q.value='site:lilypond.org +v2.14 ' + onSubmit="search.q.value='site:lilypond.org/doc/v2.15 ' + search.brute_query.value" - onMouseMove="search.q.value='site:lilypond.org +v2.14 ' + onMouseMove="search.q.value='site:lilypond.org/doc/v2.15 ' + search.brute_query.value" - onKeyUp="search.q.value='site:lilypond.org +v2.14 ' + onKeyUp="search.q.value='site:lilypond.org/doc/v2.15 ' + search.brute_query.value"> -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
