Re: table-of-contents page links
Hello Harm,
thanks alot! This seems to do the trick.
I will have a deeper look at it next days.
Cheers, Jan-Peter
On 28.04.2012 01:53, Thomas Morley wrote:
\version 2.15.36
#(define (book-first-page layout props)
(define (ancestor layout)
Return the topmost layout ancestor
(let ((parent (ly:output-def-parent layout)))
(if (not (ly:output-def? parent))
layout
(ancestor parent
(ly:output-def-lookup (ancestor layout) 'first-page-number))
#(define-markup-command (with-link layout props label arg)
(symbol? markup?)
(let* ((arg-stencil (interpret-markup layout props arg))
(x-ext (ly:stencil-extent arg-stencil X))
(y-ext (ly:stencil-extent arg-stencil Y)))
(ly:make-stencil
`(delay-stencil-evaluation
,(delay (ly:stencil-expr
(let* ((table (ly:output-def-lookup layout 'label-page-table))
(first-page-number (book-first-page layout props))
(orig-page-number (if (list? table)
(assoc-get label table)
#f))
(p-nr (ly:output-def-lookup layout 'first-page-number))
(page-number (+ orig-page-number (+ 1 (* -1
first-page-number) )))
(link-expr (list 'page-link page-number
`(quote ,x-ext) `(quote ,y-ext
(newline)(display first-page-number__)(display first-page-number)
(newline)(display p-nr___)(display p-nr)
(ly:stencil-add (ly:make-stencil link-expr x-ext y-ext)
arg-stencil)
x-ext
y-ext)))
% Test
\paper {
first-page-number = #-2
}
mus = \relative c'' {
\repeat unfold 10 { c1 \break }
}
\book {
\bookpart {
\markup \bold \fontsize #10 \fill-line { TITLE }
}
\bookpart {
\markup \fontsize #2 \fill-line { Some Text }
\paper {
oddHeaderMarkup = \markup { \null }
evenHeaderMarkup = \markup { \null }
}
}
\bookpart {
\markuplist \table-of-contents
\paper {
oddHeaderMarkup = \markup { \null }
evenHeaderMarkup = \markup { \null }
}
}
\bookpart {
\tocItem \markup { Piece 1 }
\score {
\mus
\header { piece = Piece 1 }
}
}
\bookpart {
\tocItem \markup { Piece 2 }
\score {
\transpose c cis \mus
\header { piece = Piece 2 }
}
}
\bookpart {
\tocItem \markup { Piece 3 }
\score {
\transpose c d \mus
\header { piece = Piece 3 }
}
}
}
The lines with p-nr and (display ...) should be deleted. I let them in
for testing-purpose.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Notation of french horn
Josiah Boothby josi...@gmail.com writes: You're not far off, actually, and Wagner did this for his horns and trumpets (and Wagner tubas). He knew he was writing extraordinarily difficult horn parts for players who were playing technologically new instruments, and he knew that early adopters of the valves were very accustomed to transposing. So not only did he end up eschewing key signatures (they would only confuse the poor horn players!), but he took advantage of our little mind games: writing for Horn in A or Bb doesn't actually make the high notes easier for a valved horn, but horn players seem less likely to choke on the high notes when they don't have ledger lines to scare them. How do you get a violist to play tremolo? Write Solo above the passage. Thank you, thank you, you are so kind. What a great audience. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
The Ensemble 101, Kickstarter and free LilyPond music/knowledge
Hey LilyPond users, I'd like to tell you all about a tour of France and Ireland that my group, the Ensemble 101, is planning. Aside from using beautifully typeset scores courtesy of GNU LilyPond, we'll be doing several workshops with composition students in France and Ireland on contemporary creation with LilyPond. One big goal of the tour is to show that free software, freely downloadable music and free pedagogy is a viable model in the arts. Instead of locking things up and having people pay to access them, we believe in a world where we make things freely available (music, knowledge on LilyPond, etc.) and people who appreciate our work make donations so that it can continue. It's obviously not a widespread model, but we're all passionate about it and we hope it can succeed. So check it out! The website is: http://www.kickstarter.com/projects/751757415/ensemble-101 Kickstarter works best when many people chip in a few bucks. The minimum donation is $1. So, in addition to giving what you can, make sure to pass the link along to anyone you think would be interested! I'm passing the link along to everyone I know who likes vocal music and who supports the free diffusion of culture, software and knowledge. I hope you'll like what we're doing and that you'll do the same! All the best, Mike P.S. Many thanks to Stan Sanderson and Janek WarchoĊ for the very nice quotes about our music! We feature them on the Kickstarter site.___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
programming error: cyclic dependency
Hi list, After updating my system to Ubuntu 11.10 (although I can't see why this is relevant but this is the only change I've made to the system recently), code which previously output no error is full of these errors: warning: programming error: cyclic dependency: calculation-in-progress encountered for #'positions (Beam) I don't see anything strange in the final pdf file so is this warning to be ignored? Many thanks, Peter -- //= - Peter O'Doherty - http://www.peterodoherty.net - m...@peterodoherty.net - https://joindiaspora.com/people/70716 //= ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond bug 2368
On 28 avr. 2012, at 19:19, Mark Mathias wrote: Karol, I hope someone can help you do what you wish. It's definitely beyond my level of expertise. From my point of view on the bug squad, this doesn't look like something that needs to be handled by us, so I'm going to suggest that future correspondence on this issue not be sent to the bug squad. Thanks, Mark 2012/4/24 Karol Majewski karol.majew...@gmail.com Thank you Phil. Dear LilyPond friends: Janek, Phil, Colin, I have another big problem now. I'm trying to find a global setting that would allow to ignore collisions between ties and accidentals. For me, a tie-accidental collision looks a way better than a shifted tie - especially in tied chords in which one of the ties is unnaturaly shifted horizontaly. I'm almost sure that it is possible to achieve this, but I don't know how. Best wishes PS Janek, I saw that report. I really appreciate your contribution :) Hey Karol, One difficult-to-document feature of LilyPond ties is the details list. For example, if you do: \override Tie #'details #'vertical-distance-penalty-factor = #1000 it'll make certain vertical shifts very unlikely. I've copied the details from define-grobs.scm below. There are a couple other details that for the moment are just used internally. There's been a lot of back and forth on a few LilyPond lists about improving ties. I'm of the opinion that the system in place is sound (it is a similar system as that of slurs and beams), but what needs improvement is an understanding of how much factors are worth and where they make the difference. We've made some headway in slurs in 2.15 by removing unnecessary factors and decorolating them but we haven't been able to do the same yet for ties. So, my advice to everyone would be to play around with this details list. The more we know how the details list functions in real music, the better we can make it. User input matters: if you exhaust all combinations of details and it still doesn't work, then it's much easier for a developer to know how to modify the infrastructure. Furthermore, if you find a cocktail of details setting that leads to a result that, in your opinion, should be out-of-the-box, then it's helpful to know that as well. Cheers, MS (details . ( ;; for a full list, see tie-details.cc (ratio . 0.333) (center-staff-line-clearance . 0.6) (tip-staff-line-clearance . 0.45) (note-head-gap . 0.2) (stem-gap . 0.35) (height-limit . 1.0) (horizontal-distance-penalty-factor . 10) (same-dir-as-stem-penalty . 8) (min-length-penalty-factor . 26) (tie-tie-collision-distance . 0.45) (tie-tie-collision-penalty . 25.0) (intra-space-threshold . 1.25) (outer-tie-vertical-distance-symmetry-penalty-factor . 10) (outer-tie-length-symmetry-penalty-factor . 10) (vertical-distance-penalty-factor . 7) (outer-tie-vertical-gap . 0.25) (multi-tie-region-size . 3) (single-tie-region-size . 4) (between-length-limit . 1.0)))___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: programming error: cyclic dependency
On 28 avr. 2012, at 19:48, Peter O'Doherty wrote: Hi list, After updating my system to Ubuntu 11.10 (although I can't see why this is relevant but this is the only change I've made to the system recently), code which previously output no error is full of these errors: warning: programming error: cyclic dependency: calculation-in-progress encountered for #'positions (Beam) I don't see anything strange in the final pdf file so is this warning to be ignored? Many thanks, Peter Lots of work was done in beams in 2.13 and 2.15. If you could send a minimal example (of one beam, say) and the version number, it'll be easy to ID if the problem has been fixed in more recent versions. But this is a problem - it means that beam positions are being calculated to early in the LilyPond compilation process. Cheers, MS ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hi Urs, On Fri, Apr 27, 2012 at 6:05 PM, Urs Liska li...@ursliska.de wrote: Am 27.04.2012 19:30, schrieb David Nalesnik: Hi Urs, On Fri, Apr 27, 2012 at 11:46 AM, Urs Liska li...@ursliska.de wrote: Hi David, thank you for now. I'll look into it. But isn't it very likely that I have to reshape a slur anyway when it changes from broken to unbroken? In that case I'd even say the errors are a 'feature' so you notice it ... Provided it is documented enough not to drive you crazy ... Sure, that's true. Presumably when you're looking for that fine control, you've settled on the layout in all but the tiny details! it's not only this. I think that with any slur that one might decide to shape manually a change in line break will spoil it anyway. So I'm not so sure it's a useful goal to make such a function fool-proof in this respect. Without the modification, though, the error would cause the file to fail and the error message is a little opaque. (Well, it's quite exact, but it takes some study to figure out how it happened.) Well, the file fails (at least lilypond says so), but it actually compiles, it's only the function that isn't applied. But you're right to assume that the normal user can't cope with the error messages ;-) I could create a warning here, something like: slur is not broken anymore. If that's possible in such functions, I'd find it very useful. Even better: tell the user: The slur has now X parts, please adapt the function call One thing you can do is \shapeSlur #'( ... list of offsets ...) or \shapeSlur #'(( ... list of offsets ...)) without the file failing. Since this function has come up again, I wonder if I could get your (and other people's) opinion on syntax. When I first wrote the offsetting function (http://lsr.dsi.unimi.it/LSR/Item?id=639)I thought that alists were a bother to type. But 'control-pojnts _is_ an alist '((x1 . y1) (x2 . y2) ... )) , so shouldn't we have something like this? \shapeSlur #'((dx1 . dy1) (dx2 . dy2) ...) I realize that there's more to type, but wouldn't this be clearer to use? (As well as being more consistent with how LilyPond represents this type of data)? First: I think this is a _very_ useful function that should even be made more widely known. I'm very glad that you think so! Second: your syntax suggestion looks very good to me. Of course it is more to type. But that is more than outweighed by the advantages. it's easier to write and it's especially much easier to read. When changing the offsets (which you do multiple times until you get a good result ...) I'm always finding me counting params (in order to find the right item to change) which surely takes more time and concentration than typing (once) a few brackets and points. Yes, I also find it very easy to make mistakes when typing in lists separated only by spaces. Trying out examples for the attached file, I was pleasantly surprised at how much easier-- and faster! -- it is to use the alist notation. Certainly, it is easier to read. Plus, I think it makes the offsetting function a bit less ugly. Third: I suggest to add support for PhrasingSlurs and Ties in order to make it more general. For PhrasingSlurs it's just a matter of writing a new entrance function, but for Ties you need new shape-ties and alter-tie-curve subroutines. See the attached file that is the result of an earlier enquiry on this mailing list. The functions themselves don't incorporate your newest additions (sorry, it's still a bit over my head), but you'll see what I mean. One solution is to use a syntax like this: \shapeCurve #Tie #'( ((dx1 . dy1) . . . )) and then to let the functions choose the right control-points callback from a list based on the name of the grob you're overriding. (Dmytro used this in a variant of his adaptation which I saw off-list.) I thought it might be nice to have \shapeSlur, \shapeTie, etc. To avoid duplicating so much code, I pass the relevant 'control-points callback to the functions which need it. Of course, you can extend this list to whatever takes control-points. As you mention, \shapePhrasingSlur would be the same as \shapeSlur. You can do \shapeTupletBracket in 2.14.2, but it looks like 'control-points is gone in 2.15. to sum up what I said: If you'd volunteer to do the following it would be a very valuable contribution to LilyPond's usability ;-) I'd be delighted to do whatever I can. - let the function check the number of arguments and give meaningful warnings instead of errors (count arguments and compare against number of slur siblings) It will do this. In the attached examples, some warnings will appear, and you can add elements and comment them out (with ; inside of the Scheme expression instead of the ordinary %) Tell me what you think! - don't try to make the function robust so that it accepts wrong input. This may be trivial from a programmer's perspective but I
Override of fingering font is ignored by \finger
See attached. Overriding the fingering font works fine for fingering
attached to a note but is ignored when using \finger in a markup, where
the default fingering font is still used.
\version 2.15.37
\relative c'' {
\override Staff.Fingering #'font-name = #'Arial Black
e-44 cis d\prall^\markup { \concat { \finger 4 \hspace #0.15 \tiny { /
} \finger 2 } }
}
attachment: test.png___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
\tempo sticks out to the right
Folks,
consider this example:
\version 2.15.37
\relative c'' {
c4 c c c |
c4 c c c |
c4 c c c |
c4 c c c |
c4 c c c |
c4 c c c |
\tempo a very long tempo string c4 c c c |
c4 c c c |
c4 c c c |
c4 c c c |
c4 c c c |
c4 c c c |
c4 c c c |
c4 c c c |
c4 c c c |
c4 c c c |
}
Attached is its output. How can I avoid that the \tempo string sticks
out to the right?
Werner
inline: tempo.png___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
