Re: NR 1.2.3 Upbeats: confusing explanation of measurePosition
On 2012-12-30 23:59, Federico Bruni wrote: In NR 1.2.3, Upbeats: So \partial 8 becomes: \time 3/4 \set Timing.measurePosition = #(ly:make-moment -1 8) e8 | a4 c8 b c4 | _The property measurePosition contains a rational number indicating how much of the measure has passed at this point_. Note that this is set to a negative number by the \partial command: i.e., \partial 4 is internally translated to -4, meaning “there is a quarter note left in the measure.” IMO the first sentence is a bit confusing. I agree about confusion, but not in the first sentence, but in the last: -4 actually means it needs one quarter note until the measure even starts. (\partial inserts a partial measure 0 before the measure 1, and measure 1 is the first measure where counting starts) Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Documentation figured-bass
On 2012-10-23 00:13, Noeck wrote: Hi, the last two snippets on this page are identical, aren't they? http://lilypond.org/doc/v2.16/Documentation/notation/figured-bass Is that a problem that only occurs in older versions? Yes, that was one problem that I fixed a while ago... Should the documentation be adapted? Apparently, yes. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: modern-straight-flag
On 2012-09-05 18:15, David Kastrup wrote: Karim Haddad karim.had...@ircam.fr writes: Apparently, in the new stable version 2.16, the \override Stem #'flag = #modern-straight-flag is broken. , i.e this has no effect, the flags stay traditional. or maybe i missed something. Anyhow, Thank you a lot to all developers who contributed and to all of you. Maybe we should hammer home the existence of convert-ly right in our stable release announcements. Its discoverability is likely not sufficient for making people pick the smoothest upgrade path. This is a particularly nasty example, since lilypond seems to work fine without any warning or error. Some functionality simply silently stopped working and suddenly produces a different output without any indication! If we really need to change the lilypond language [1] (and I also count changes to overrides as an relevant change in the lilypond language), then at least we should make sure that either the old syntax keeps working (via a compatibility layer or by keeping some old definitions), or make sure that lilypond FAILS with the old syntax (or at least give a warning!). Giving the user the impression that everything worked, even though things have changed, is the worst case and a good way to make professionals loose confidence in lilypond. And you can't really require all users to run convert-ly on any file for any small lilypond update (with the package systems in the various Linux distributions, the users might not even be aware when a new minor version of lilypond was installed!) I have been badly burnt such a situation a while ago. Just before sending one of my scores to the print office (thank god it was before, not after!), I noticed that lilypond had silently discarded most of the text crescendos! The compilation didn't print out any warning, it simply didn't print cresc. in certain cases, because the way text crescendo were implemented had changed meanwhile. Cheers, Reinhold [1] Note, however, that ANY change, even a very small, subtle change, is a really grave argument for a music publisher against using lilypond. I wrote a huge piece (~95 pages full score, 23 orchestra instruments, choir, etc) a few years ago. I didn't count the hours it took me last month to bring it up to date with the latest lilypond version (I had to visually compare the whole full score and all instruments to make sure that nothing had been lost). At that time, I really, really, really cursed lilypond and its frequent syntax changes. -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Beams of grace notes collide with tie in staff size5 1
I have a staff with two voices (actually, two part-combinedvoices).
In the attached example, the beam of the grace in the second voice
collides with the tie in the first voice, but only if I use staff size
15. In any other staff size, no collision occurs.
Also, the stems of the grace notes are way too long.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
\version 2.17.0
% With staff-size 15 the beam of the grace notes collides with
% the tie of the first voice. With the default staff-size, no
% collision occurs:
#(set-global-staff-size 15)
\new Staff {
% \time 2/4
\partcombine
\relative c'' { f2~ f }
\relative c'' { b2 \grace { c16[ b] } a2 }
}
lilypond-grace-beam-collision.preview.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Warning with line spanner for text cresc, even though DynamicTextSpanner #'style = #'none
The attached minimal example turns off the line spanner for the text
crescendo, but at linebreaks still gives a warning that the left point
of the line spanner is after the right point.
If I turn off the line spanner (i.e. set style=#none), then no line
spanner should be generated at all, and thus this warning should not be
triggered, either.
reinhold@zweistein:~/temp$ lilypond -dpreview lilypond-text-spanner-bound.ly
GNU LilyPond 2.17.0
»lilypond-text-spanner-bound.ly« wird verarbeitet
Analysieren...
Interpreting music...
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
lilypond-text-spanner-bound.ly:12:3: Warnung: Line spanner's left point
is to the right of its right point.
c
\cresc |\break
Layout nach »lilypond-text-spanner-bound.ps« ausgeben...
Konvertierung nach »./lilypond-text-spanner-bound.pdf«...
Layout nach »lilypond-text-spanner-bound.preview.eps« ausgeben...
Konvertierung nach »./lilypond-text-spanner-bound.preview.pdf«...
Konvertierung nach PNG...
Kompilation erfolgreich beendet
Cheers,
Reinhols
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
\version 2.17.0
\paper {
ragged-right = ##t
}
\relative c'' {
\override Score.DynamicTextSpanner #'style = #'none
% a cresc that ends in the same line is okay
c1\cresc | c c\! |
% but a cresc immediately before a line break will trigger a
% warning about the line-spanner ending before it started, even
% though we don't use any visible spanner:
c\cresc |\break
c\!
}
lilypond-text-spanner-bound.preview.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
partcombine detects Solo II, even though I force it to use separate voices with \partcombineApart
In the attached minimal example I explicitly call \partcombineApart to
force two separate voice. However, the partcombiner still detects the
second quarter as SoloII. The correct solution would be to use
automatically forced separate voices.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
\version 2.17.0
% in this example, the part-combiner detects the second beat as SoloII, even
though we force it to use separate voices:
IVDuettFagIMusic = \relative f'' {
\partcombineApart R2
\partcombineAutomatic f2
}
IVDuettFagIIMusic = \relative f'' {
\partcombineApart f4( es4)
d2
}
\new Staff {
\partcombine \IVDuettFagIMusic \IVDuettFagIIMusic
}
% WORKAROUND: Explicitly force the second quarter as Apart, too. This is
cumbersome and should NOT be required:
IVDuettFagIIMusicWorkaround = \relative f'' {
\partcombineApart f4( \partcombineApart es4)
d2
}
\new Staff {
\partcombine \IVDuettFagIMusic \IVDuettFagIIMusicWorkaround
}
lilypond_partcombine_beginrest.preview.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug? with Choir Staff
On 2012-08-21 17:56, Aaron wrote: I used a Choir Staff to typeset http://sdrv.ms/SNz2VO (if you need the code, let me know). My friend also used Choir Staff at a different size in a different score with the same result. The problem is that the vertical bar at the left of the system is not seamlessly attached to the flanges at the top and bottom. I'm accustomed to this type of problem on screen due to aliasing issues or whatever else, but the problem persisted after printing. A much smaller issue is that after printing, the barlines are slightly taller and shorter than the staff. I cannnot see the problem here on a Linux machine with the okular PDF viewer. Here the vertical line and the flanges are perfectly attached and the barlines do not exceed the staff lines. I would guess that this is a problem with your PDF viewer rather than with lilypond. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: landscape mode in lilypond-book doesn't calculate line length correctly
On 2012-08-11 21:57, David Kastrup wrote:
Laura Conrad lcon...@laymusic.org writes:
Laura == Laura Conrad lcon...@laymusic.org writes:
Laura When run on the attached file, lilypond-book sets the line
Laura length of the music to be much less than the actual width of
Laura the page that latex is using (which you can see by where it
Laura puts the footers.)
I think I have a clue as to the source of this problem. I did
some investigation, since this is a blocking bug for a project with a
tight deadline in early September.
I looked at the lilypond-book python code, and it does indeed seem to be
setting the width wider for a landscape page than for a portrait page.
However, at some point when lilypond-book is running lilypond, I get the
following warning:
warning: systems run off the page due to improper paper settings,
setting default values
It looks like whatever code writes this warning thinks that no page
should ever be more than about 9 inches wide. This might be good enough
for my purposes, although I was thinking about using smaller than 1 inch
margins, and certainly there are some purposes for which you would
definitely want minimal margins.
So can someone who understands where that message comes from check
whether there's some inappropriate hard coding of the maximum width of a
page which is too small for a letter paper in landscape?
No such luck, it is in LilyPond itself that you have
if (to_boolean (c_variable (check-consistency)))
{
// Consistency checks. If values don't match, set defaults.
if (abs (paper_width - line_width - left_margin - right_margin) 1e-6)
{
line_width = line_width_default;
left_margin = left_margin_default;
right_margin = right_margin_default;
warning (_ (margins do not fit with line-width, setting default
values));
}
else if ((left_margin 0) || (right_margin 0))
{
line_width = line_width_default;
left_margin = left_margin_default;
right_margin = right_margin_default;
warning (_ (systems run off the page due to improper paper settings,
setting default values));
}
}
Have you tried setting the paper type in your lilypond-book snippets?
LilyPond-book only siphons off
# Retrieve dimensions from LaTeX
LATEX_INSPECTION_DOCUMENT = r'''
\nonstopmode
%(preamble)s
\begin{document}
\typeout{textwidth=\the\textwidth}
\typeout{columnsep=\the\columnsep}
\makeatletter\if@twocolumn\typeout{columns=2}\fi\makeatother
\end{document}
so it does not bother getting/setting paper info.
Ah, good point. It actually took me a while to see what you mean: This
snippet correctly extracts the actual line width for the snippet, but
the snippet uses the default lilypond paper size rather than the paper
size implied by the latex document... Nice Catch!
When I worked on these parts of lilypond-book, I tested with various
page settings, but apparently forgot to check with larger page sizes
than A4 portrait...
The apparent solution is to also print out the paper page width/height
and all the margins (to avoid e.g. too much vertical stretching of staff
groups)...
I'll try to come up with a patch.
Cheers,
Reinhold
Fragments may use the
`papersize=STRING'
Where STRING is a paper size defined in `scm/paper.scm' i.e.
`a5', `quarto', `11x17' etc.
Values not defined in `scm/paper.scm' will be ignored, a warning
will be posted and the snippet will be printed using the default
`a4' size.
option. Embarrassingly, there is no way to get a4 landscape in
LilyPond-book right now, but a3 should do the trick I guess, at some
loss of performance.
Inside of LilyPond, #(set-default-paper-size a4 'landscape) would
work.
Hmm, to make life for .ly file generators easier, maybe it would be a
good idea to additionally define paper sizes a4landscape and the like...
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Fwd: scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof
According to David's response (which I will also forward from -devel),
the problem is that the addQuote (and the part-combiner) use a Global
context from the moment the part-combiner is initialized rather than
when addQuote is called. Thus the Global context is missing information
about the new grob...
We had a similar problem with the RemoveEmptyStaff context, which we
fixed by turning it into a context mod instead, which can later be
inserted into the current context. I suppose a similar solution could
fix this problem, too.
Cheers,
Reinhold
Original Message
Subject: scheme spanner in input/regression/scheme-text-spanner.ly not
quote-proof
Date: Thu, 26 Jul 2012 20:10:13 +0200
From: Reinhold Kainhofer reinh...@kainhofer.com
Organization: FAM, TU Wien
To: LilyPond Development lilypond-de...@gnu.org
The text spanner implemented in scheme (which is also used as a basis
for David's measure counter engraver) seems to work fine in the regtest,
but apparently it is not quote-proof.
In particular, if you try call \addQuote on some music that contains
\schemeTextSpannerStart or \schemeTextSpannerEnd, then you get the
following warnings and the text spanner is not quoted:
scheme-text-spanner.ly:210:5: warning: Event class should be a list
a4
b\schemeTextSpannerStart c d |
scheme-text-spanner.ly:212:7: warning: Event class should be a list
a4 b
c\schemeTextSpannerEnd d |
So apparently the scheme way to add new event classes is not entirely
correct...
Sample file (regtest adapted to quote the music) is attached.
Any idea about the correct fix to this?
Thanks,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
\version 2.15.31
\header {
texidoc = Use @code{define-event-class}, scheme engraver methods,
and grob creation methods to create a fully functional text spanner
in scheme.
}
#(define my-grob-descriptions '())
#(define my-event-classes (ly:make-context-mod))
defineEventClass =
#(define-void-function (parser location class parent)
(symbol? symbol?)
(ly:add-context-mod
my-event-classes
`(apply
,(lambda (context class parent)
(ly:context-set-property!
context
'EventClasses
(event-class-cons
class
parent
(ly:context-property context 'EventClasses '()
,class ,parent)))
\defineEventClass #'scheme-text-span-event #'span-event
#(define (add-grob-definition grob-name grob-entry)
(let* ((meta-entry (assoc-get 'meta grob-entry))
(class(assoc-get 'class meta-entry))
(ifaces-entry (assoc-get 'interfaces meta-entry)))
(set-object-property! grob-name 'translation-type? list?)
(set-object-property! grob-name 'is-grob? #t)
(set! ifaces-entry (append (case class
((Item) '(item-interface))
((Spanner) '(spanner-interface))
((Paper_column) '((item-interface
paper-column-interface)))
((System) '((system-interface
spanner-interface)))
(else '(unknown-interface)))
ifaces-entry))
(set! ifaces-entry (uniq-list (sort ifaces-entry symbol?)))
(set! ifaces-entry (cons 'grob-interface ifaces-entry))
(set! meta-entry (assoc-set! meta-entry 'name grob-name))
(set! meta-entry (assoc-set! meta-entry 'interfaces
ifaces-entry))
(set! grob-entry (assoc-set! grob-entry 'meta meta-entry))
(set! my-grob-descriptions
(cons (cons grob-name grob-entry)
my-grob-descriptions
#(add-grob-definition
'SchemeTextSpanner
`(
(bound-details . ((left . ((Y . 0)
(padding . 0.25)
(attach-dir . ,LEFT)
))
(left-broken . ((end-on-note . #t)))
(right . ((Y . 0)
(padding . 0.25)
))
))
(dash-fraction . 0.2)
(dash-period . 3.0)
(direction . ,UP)
(font-shape . italic)
(left-bound-info . ,ly:line-spanner::calc-left-bound-info)
(outside-staff-priority . 350)
(right-bound-info . ,ly:line-spanner::calc-right-bound-info)
(staff-padding . 0.8)
(stencil . ,ly:line-spanner::print)
(style . dashed-line)
(meta . ((class . Spanner)
(interfaces . (font-interface
line-interface
line-spanner-interface
Fwd: Re: scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof
Original Message Subject: Re: scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof Date: Sat, 28 Jul 2012 07:32:20 +0200 From: David Kastrup d...@gnu.org Organization: Organization?!? To: lilypond-de...@gnu.org Reinhold Kainhofer reinh...@kainhofer.com writes: The text spanner implemented in scheme (which is also used as a basis for David's measure counter engraver) seems to work fine in the regtest, but apparently it is not quote-proof. In particular, if you try call \addQuote on some music that contains \schemeTextSpannerStart or \schemeTextSpannerEnd, then you get the following warnings and the text spanner is not quoted: Well, scheme-text-spanner changes the \Global context, and quote environments uses the layout definition partCombineListener in ly/declarations-init.ly with an unchanged Global context. Change its Global context similarly, and you should be set. -- David Kastrup ___ lilypond-devel mailing list lilypond-de...@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: subtlety or remainder from other times?
On 2012-07-30 19:43, Trevor Daniels wrote: Eluze wrote Monday, July 30, 2012 4:01 PM to me both \larger and \smaller are obsolete. or is there a subtlety I can't see? \markup \markup \larger shows a clear difference in size here. Why do you think they are obsolete? The example had both \larger and \smaller in the same markup. It seems that their effects really cancel: \markup \markup \larger \smaller Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Fwd: [Feature request] attach lilypond code in pdf.
On 2012-07-09 10:49, Phil Holmes wrote: -Eluze elu...@gmail.com wrote in message news:34131686.p...@talk.nabble.com... Bernard Hurley-2 wrote: On Sun, Jul 08, 2012 at 11:12:40PM +0100, Colin Hall wrote: Hi, I'm a pretty much new user of lilypond and I have an idea for a almost dummy new feature: automatically attach lilypond code in pdf. With pdf files it is possible to attach a file into it. What a great idea! the basic function in LilyPond is given with \include test.ly \markup \verbatim-file #test.ly now I don't know what you mean with automatically - should it be attached every time? on a new page, in another (pdf) file? or did you mean something else? I do think this would do what the user wants, if we did not need to put the filename in explicitly. Is there any way of getting the filename into a variable? Actually, I don't think this is what the OP wanted. A pdf file can have other files attached (which are not displayed) and even signed for authenticity. These files are not included as text, but the PDF viewer typically displays a message that other files are attached to the PDF file and can be extracted and stored on disk. Attached is a sample file, created by pdftk (test.pdf is created by lilypond, and the test.ly file is attached to it, and everything is output as test_attached.pdf): pdftk test.pdf attach_files test.ly output test_attached.pdf If you open it in acroread (in okular the file name of the attached file seems messed up), you'll see that the test.ly file is attached to the pdf and can be opened from acroread. You'll probably need to look at the tab with the paper clip to list the attached files. I don't know if ps2pdf supports attaching files to the resulting pdf files, though... Cheers, Reinhold PS: While IMSLP.org does not allow upload of source files directly, it allows/encourages contributors to attach the source files to the output pdf file. -- -- Reinhold Kainhofer,reinh...@kainhofer.com, http://reinhold.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org test_attached.pdf Description: Adobe PDF document ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: IR: unclear definition of middleCClefPosition?
On 12/06/2012 16:00, pls wrote: The position of the clef is two half spaces (-2) below the center of the staff. The position of the middle C is 6 half spaces below the center of the staff. I looked at various clefs (treble, alto, tenor, bass) and middleCClefposition is always determined by the number of half staff spaces from the center of the staff. It never refers to the position of the clef. But then I'd say middleCClefposition is a misnomer and should rather be called middleCPosition. Unfortunately middleCPosition already exists. What's the difference? Am I barking up the wrong tree? middleCClefPosition is in most cases equal to middleCPosition. Only if you have cue notes in a different clef, they are different (since the notes need to use the middleCPosition of the cue clef, while the key signature needs to use the middle-C position of the original clef). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: http://lsr.dsi.unimi.it/LSR/Item?id=606 out of date
On 2012-04-29 12:21, Phil Holmes wrote: Richard Shann richard.sh...@virgin.net wrote in message news:loom.20120429t120522...@post.gmane.org... http://lsr.dsi.unimi.it/LSR/Item?id=606 says figures are not printed above rests, which they weren't in 2.12 but they are in the version being used (2.14 I guess), so the image and text conflict Thanks. Looks like this should be deleted then? Figures on rests are now printed by default, but this can be turned off by setting ignoreFiguredBassRest to ##t. So the logic in the snippet should simply be changed to show the opposite (i.e. they are printed by default, but can be turned off). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: new lilypond-auto mailing list
On 2012-03-20 00:28, Graham Percival wrote: On Tue, Mar 20, 2012 at 12:11:46AM +0100, David Kastrup wrote: So instead of surprising volunteers by giving them more information than expected we give them less information than expected? Bug squad members shouldn't be reading tracker messages anyway. It's not about bug squad, but about all developers. The comment of the lilypond users to the bug reports are *extremely* important for development. On the other hand, all those hundreds of automated comments to the bug reports are totally unnecessary. To me the main problem is that we have so many automated comments to a bug report that the bug-lilypond list is swamped with those notifications and the relevant human responses are hard to detect (I now typically ignore all bug mails, since it simply takes to long to find out which of the ~50-70 mails per day are automated and which are relevant). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Ledger lines in PNG output have white interior
On 12/02/2012 22:39, Werner LEMBERG wrote: Which PS viewer? Which OS? Which platform (32 or 64 bit)? Which gs version? gs 9.00 on GNU/Linux, using gv 3.7.0. [...] Looks like a bug in the anti-aliasing device of gs: If I switch to B/W, the ledger line is just fine. Are you reporting this to the ghostscript folks? Any idea for a workaround? I urgently need to generate the png files (~50 examples) before the weekend to insert them into a thesis (.doc file) and send the draft to the advisor. Using -dpixmap-format=pngmono creates ugly pixelated images, everything else (even inserting the eps file into libreoffice) creates those white rectangles inside the ledger lines. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1967 in lilypond: Concurrent slurs that start and end at the same moment should not produce a warning
On 15/02/2012 17:01, lilyp...@googlecode.com wrote:
Updates:
Labels: Patch-new
Comment #21 on issue 1967 by d...@gnu.org: Concurrent slurs that start
and end at the same moment should not produce a warning
http://code.google.com/p/lilypond/issues/detail?id=1967#c21
Allow multiple identical slurs (issue 1967).
It allows also non-identical slurs, e.g. { c4(( c) d f) }, which is a
common error for ties. This example will silently discard the outer
slur. See the attached proposed regtest.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.15.30
\header {
texidoc = LilyPond does not support multiple concurrent slurs. However,
parallel voices can create chords with identical slurs, which shall only
create one slur grob and not print a warning. If the slurs are not
identical, a warning is expected.
}
% Should NOT create a warning, we have identical slurs
\relative c'' {
c4(( d e f))
}
% Should create a warning, we don't have identical slurs.
#(ly:expect-warning (_ already have slur))
% OR: #(ly:expect-warning (_ cannot end slur))
\relative c'' {
c4(( d e) f)
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1967 in lilypond: Concurrent slurs that start and end at the same moment should not produce a warning
On 2012-02-15 19:18, David Kastrup wrote: Reinhold Kainhoferreinh...@kainhofer.com writes: This example will silently discard the outer slur. The number of times where I have to contradict you today is impressive. No, it won't. Both get typeset. Oops, you are right. Your patch not only fixes the warning, but also implements concurrent slurs that start at the same moment... LGTM. I'm currently trying to clean up the backlog of lilypond messages of the last 10 days (~800 mails), so I spend hardly any time cross-checking... I simply saw that the message was no longer printed for that case, and I assumed that concurrent slurs were still disallowed and the second slur discarded. Thanks for pointing that out. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1967 in lilypond: Concurrent slurs that start and end at the same moment should not produce a warning
On 2012-02-15 16:12, lilyp...@googlecode.com wrote: I have decided to tackle this with a simplistic patch that simply does not complain if several slurs start at the same time, while still dropping any slur with the same id starting later while warning. I have not looked at phrasing slurs, though. Copy'n'paste from slurs (minus melisma handling). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
bar number collides with staff bracket when bass-clef is used
If the first staff of a score a group bracket uses a bass clef, the bar
number (when center-aligned) collides with the bracket. Attached is an
example.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.15.30
\score {
\new StaffGroup
\new Staff \relative c {
\override Score.BarNumber #'self-alignment-X = #CENTER % center-aligned
% \bar
\clef bass
c1 | c1 | c | c | \break
c1 | c1 | c | c | \break
c1 | c1 | c | c | \break
c1 | c1 | c | c | \break
}
\new Staff \relative c {
% \bar
\clef bass
c1 | c1 | c | c | \break
c1 | c1 | c | c | \break
c1 | c1 | c | c | \break
c1 | c1 | c | c | \break
}
}
barnumber-bracket-bassclef.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bar number collides with staff bracket when bass-clef is used
On 2012-02-12 17:39, Colin Hall wrote:
On Sun, Feb 12, 2012 at 04:36:26PM +0100, Reinhold Kainhofer wrote:
If the first staff of a score a group bracket uses a bass clef, the
bar number (when center-aligned) collides with the bracket. Attached
is an example.
\version 2.15.30
\score {
I've forwarded your bug report to the developer list, Reinhold, as we can only
accept bug reports against released versions.
Simply change 2.15.30 to 2.12.3 and run it with 2.12... The same problem
was still there in 2.12.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Ledger lines in PNG output have white interior
I'm using lilypond on Ubuntu oneiric (both self-compiled 2.15.30 as well
as ubuntu's 2.12.3).
When converting to PNG rather than PDF, all ledger lines show artefacts
in that the interior of the ledger lines is white rather than black.
Simply compile the attached file ledger-png.ly with the command line:
lilypond --png -dpreview -dresolution=600 ledger-png.ly
(The output file ledger-png.preview.png is attached to this report, too).
The problem appears with 2.15.30 and with ubuntu's stock lilypond 2.12.3.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.12.3
\relative c''' { c2 }attachment: ledger-png.preview.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Ledger lines in PNG output have white interior
On 2012-02-12 21:52, Werner LEMBERG wrote: When converting to PNG rather than PDF, all ledger lines show artefacts in that the interior of the ledger lines is white rather than black. very strange. Doesn't happen on Windows 7 with 2.15.25 nor on Ubuntu 10.04 Lucid Lynx with current (18cfd801fa7fcd698e924f3b530862714f3e3013) master. It happens for me also (with current git) if you produce output with --ps. Which PS viewer? Which OS? Which platform (32 or 64 bit)? Which gs version? Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
On 22/01/2012 20:58, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1933 in lilypond: Lilypond-book requires msvcrt again
On 2012-01-04 22:48, m...@apollinemike.com wrote: Question for Reinhold: In 55aad8c485e14d29d78eddc0782a5e9901c6bf2c, you added a command to set LC_ALL. This seems like POSIX-friendly syntax - are you sure it works on Windows? No idea, I have never tried lilypond on Windows. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: (De)Crescendo hairpin touching vertical bar of the last measure in the line
On 2011-11-26 00:01, Xavier Scheuer wrote:
On 25 November 2011 17:50, PrzemysławPawełczykprze...@gmail.com wrote:
I'm lilypond newbie (it's my first mail to ML) and looking for a
solution to a bad looking (de)crescendo hairpin ending at the end of
the last measure, i.e. grossly touching vertical bar (in case of many
staves per system). It doesn't happen for non-last-in-line measures.
Looks like a bug to me (hence the Cc to bug-lilypond, so it will be
added to the issue tracker).
Reinhold fixed issue #1433 but AFAICS the related reg test only shows
the effect of a _textual_ *broken* DynamicTextSpanner, not a _Hairpin_
*to-barline* at a line break.
Actually, my fix has nothing to do with the padding between the hairpin
and the barline. Bug 1433 was about being able to break text crescendi
at all.
This bug report is about missing padding between a broken hairpin and
the succeeding barline. This only affects the broken hairpin, while the
padding at the real end of the hairpin is correct. \score { \new
StaffGroup \new Staff { \music } \new Staff { \music } }
Cheers, Xavier
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: CRASH
On 2011-10-30 10:41, Arno wrote: Lilypond crashes while compiling one of my scores very ungracefully: [...] This is on Ubuntu oneiric 32bit. It does not happen on my PC's oneiric 64bit installation. (Not sure this migth be related...) It probably is. FWIW, I'm also experiencing random crashes with current master (reproducible, but not tracked to a single input file. I.e. if I compile lilypond input/regression/a*.ly, it crashes reliably on the same file file; but lilypond running on that file alone does not crash). Those crashes mostly appear inside guile's protected areas, and I have no idea what causes them. For now, even a make check doesn't work. This happens on both machines I upgraded to Ubuntu oneiric 32-bit, but does not happen in a newly installed oneiric 64-bit system. Cheers, Reinhold ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: CRASH
On 2011-10-30 11:17, Reinhold Kainhofer wrote: On 2011-10-30 10:41, Arno wrote: Lilypond crashes while compiling one of my scores very ungracefully: [...] This is on Ubuntu oneiric 32bit. It does not happen on my PC's oneiric 64bit installation. (Not sure this migth be related...) It probably is. FWIW, I'm also experiencing random crashes with current master (reproducible, but not tracked to a single input file. I.e. if I compile lilypond input/regression/a*.ly, it crashes reliably on the same file file; but lilypond running on that file alone does not crash). Those crashes mostly appear inside guile's protected areas, and I have no idea what causes them. For now, even a make check doesn't work. This happens on both machines I upgraded to Ubuntu oneiric 32-bit, but does not happen in a newly installed oneiric 64-bit system. Yes, it also crashes in --disable-optimising in make check: Converting MusicXML file `group-symbol_none.xml'... Writing snippets... Processing... Running lilypond...GNU LilyPond 2.15.17 Processing ./snippet-map--60970532 Processing a9/lily-f0f9564f Processing 9e/lily-cd338506 Processing d4/lily-78b73203 Segmentation fault command failed: /home/reinhold/lilypond/lilypond/out/bin/lilypond -I ./ -I ./out-test -I ../../../input -I /home/reinhold/lilypond/lilypond/Documentation -I /home/reinhold/lilypond/lilypond/Documentation/snippets -I ../../../input/regression/ -I /home/reinhold/lilypond/lilypond/Documentation/included/ -I /home/reinhold/lilypond/lilypond/mf/out/ -I /home/reinhold/lilypond/lilypond/mf/out/ -I /home/reinhold/lilypond/lilypond/Documentation/pictures -I /home/reinhold/lilypond/lilypond/Documentation/pictures/./out-test -dbackend=eps --formats=ps -dseparate-log-files -dinclude-eps-fonts -dgs-load-lily-fonts --header=texidoc -I /home/reinhold/lilypond/lilypond/Documentation/included/ -ddump-profile -dcheck-internal-types -ddump-signatures -danti-alias-factor=1 -I /home/reinhold/lilypond/lilypond/out/lybook-testdb -I /home/reinhold/lilypond/lilypond/input/regression/musicxml -I /home/reinhold/lilypond/lilypond/input/regression/musicxml -I /home/reinhold/lilypond/lilypond/input/regression/musicxml/out-test -I /home/reinhold/lilypond/lilypond/input -I /home/reinhold/lilypond/lilypond/Documentation -I /home/reinhold/lilypond/lilypond/Documentation/snippets -I /home/reinhold/lilypond/lilypond/input/regression -I /home/reinhold/lilypond/lilypond/Documentation/included -I /home/reinhold/lilypond/lilypond/mf/out -I /home/reinhold/lilypond/lilypond/mf/out -I /home/reinhold/lilypond/lilypond/Documentation/pictures -I /home/reinhold/lilypond/lilypond/Documentation/pictures/out-test --formats=eps --loglevel=INFO -deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir /home/reinhold/lilypond/lilypond/out/lybook-testdb/snippet-names--60970532.ly Child returned 139 make[2]: *** [out-test/collated-files.texi] Fehler 1 make[2]: Verlasse Verzeichnis '/home/reinhold/lilypond/lilypond/input/regression/musicxml' make[1]: *** [local-test] Fehler 2 make[1]: Verlasse Verzeichnis '/home/reinhold/lilypond/lilypond/input/regression/musicxml' make: *** [test] Fehler 2 reinhold@curie:~/lilypond/lilypond$ Running all musicxml snippets manually through lilypond does NOT crash... Cheers, Reinhold ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: musicxml2ly: group-symbol none leads to bus error
Am Saturday, 22. October 2011, 11:33:56 schrieb pls:
Am 22.10.2011 um 07:16 schrieb Colin Campbell:
I'm not sure what sort of error to look for, Patrick. When I run your
file on my system, I don't see any errors reported on the console,
either from musicxml2ly or lilypond itself. The resulting .ly compiles
with only one error: the lack of any graphic output, by way of .pdf or
.ps. Is this the error you are reporting?
Hi Colin,
hm, there aren't any errors reported from musicxml2ly but when I try to
compile the file with v2.15.14 I get:
Interpreting music... Bus error
With v2.15.15 I get:
Interpreting music... Segmentation fault
The culprit is:
[...]
% The score definition
\new StaffGroup \with { systemStartDelimiter = #'f }
\new Staff
[...]
Setting systemStartDelimiter to #'f is just plain wrong (it's the symbol f,
not the boolean value, and even that wouldn't work). No idea why I missed that
case when I wrote the code...
I suppose the proper fix would be to set it to #'SystemStartBar.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: musicxml2ly: group-symbol none leads to bus error
Am Wednesday, 19. October 2011, 17:45:23 schrieb Patrick Schmidt: Hey all, The value 'none' of the element 'group-symbol' (group-symbolnone/group-symbol) leads to a bus error when the converted .ly-file is compiled with LilyPond v2.15.14. The compilation fails. There is no problem with the conversion and compilation of the other group-symbols (brace, line and bracket). (The MusicXML-Code of the minimal example is valid.) Hmm, it should probably set #'SystemStartBar instead of #'f Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: musicxml2ly: single words with punctuation marks in score header lead to compilation failure
Am Thursday, 20. October 2011, 12:15:10 schrieb pls: Compilation with LilyPond v2.15.14 fails when an element of the score header of a converted MusicXML-file contained a single word directly followed by a punctuation mark (I tested it with '.', '!', ','. There is no problem with question marks.). Solution: musicxml2ly should automatically enclose all titles and headers in quotation marks. (Currently only the ones containing white spaces and/or question marks are enclosed in quotation marks.) IIRC, I'm reusing the function for lyrics. While lyrics allow those punctuation marks without quotes, the header fields do not. Your suggestion sounds fine... Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1110 in lilypond: Wrong octave of repetition chord with \relative and #{ #} syntax
Am Sonntag, 16. Oktober 2011, 12:29:14 schrieb Werner LEMBERG: It is extremely helpful in writing keyboard music. Typing aids are the kind of thing that editor macros should do rather than the music processor. Here I strongly disagree. There must be means to make LilyPond's `source code' readable by people also which don't use an editor's special lilypond mode. Compare this: [...] I'm not sure that you can beat the q notation w.r.t. readability. +1 Until yesterday, I never thought that the q notation was really that useful, but yesterday I had to typeset the piano part of Schubert's Nachthelle: http://imslp.org/wiki/Nachthelle,_D.892_(Op.134)_(Schubert,_Franz) The right-hand part consists entirely of repeated 16th chords, played through 157 measures! It took me just 3 hours to write the whole piano part with the q notation, but I would still be writing the piece without it. And using editor macros is no real solution, because that makes later editing almost impossible, when you want to fix a typo in the first chord, which is repeated for 10 measures (i.e. you'll have 80 chords to fix! and if you miss fixing one of them, good luck finding the wrong one in the sea of ...!). And readibility with the q notation is simply unbeatable. FWIW, I don't think it's really worth to have q work through nested relative. That's simply unsupported (and might be documented as such). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crashes in Windows with Gregorian music
Am Montag, 3. Oktober 2011, 17:05:53 schrieb Phil Holmes:
\include gregorian.ly
\score {
\new VaticanaVoice = cantus {
c'
}
}
Windows Vista 64 bit.
Lilypond allocates memory like it's going out of fashion, getting to about
a Gig after 14 seconds. It then crashes. The output is:
GNU LilyPond 2.14.2
Processing `D:/Music/BAMusic/Gregorian.ly'
Parsing...
D:/Music/BAMusic/gregorian.ly:1:9: error: out of dynamic memory in
yy_create_buffer()
\include
gregorian.ly
Did you notice that your input file is called Gregorian.ly, which in windows
is the same as gregorian.ly. So here you are actually including the input
file over and over again, rather than LilyPond's gregorian chant
definitions...
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Apparently bogus warning with 2.15.12
Am Monday, 26. September 2011, 22:40:00 schrieb Nick Payne:
I haven't been able to create a small example that gets the bogus
warning in the log, but while trying to do so I managed to reproduce
what looks like a related/similar problem.
Thanks a lot, it is your very problem (you just happen to have to b's in the
first displayed measure, so the spurious tie can be applied without warning).
Attached is a minimal example of this bug. It seems that with showLastLength,
a tie in the hidden parts will be carried over to the first displayed note!
Cheers,
Reinhold
PS: The console output of the example is:
reinhold@einstein:~/lilypond/lilypond$ LANGUAGE=C lilypond showlastlength-
tie.ly
GNU LilyPond 2.15.13
Processing `showlastlength-tie.ly'
Parsing...
Interpreting music...
showlastlength-tie.ly:8:2: warning: unterminated tie
b2 c
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `showlastlength-tie.ps'...
Converting to `./showlastlength-tie.pdf'...
Success: compilation successfully completed
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.15.12
showLastLength = R1
\relative c'' {
% This tie will be applied to the next measure, despite being hidden by showLastLength!
e2~ e |
b2 c
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 824 in lilypond: Enhancement: anchors in the music stream
Am Friday, 23. September 2011, 09:31:00 schrieb lilyp...@googlecode.com: Comment #11 on issue 824 by d...@gnu.org: Enhancement: anchors in the music stream http://code.google.com/p/lilypond/issues/detail?id=824 lilyp...@googlecode.com writes: No stable yet. Wasn't it Fixed when fixed in the development version, Fixed_xxx when fixed in a certain release? Nope, fixed_2_15_xx is a tag that you should add to tell the testers which release to check. You are the only one who knows in which version the bug is supposed to be fixed... Let me check the CG: * Fixed: a contributor claims to have fixed the bug. The Bug Squad should check the fix with the next official binary release (not by compiling the source from git). Owner should be set to that contributor. Well, I claim to have fixed the bug. Nothing more, nothing less. Working regtest is there, user level documentation is there, no word from the bounty offerers. No bad conscience here on my part. You'll have to add fixed_2_15_xx, so the testers know when you supposed fixed the bug. Maybe this needs to be added to the CG more explicitly? Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 824 in lilypond: Enhancement: anchors in the music stream
Am Friday, 23. September 2011, 11:27:33 schrieben Sie: Reinhold Kainhofer reinh...@kainhofer.com writes: You'll have to add fixed_2_15_xx, so the testers know when you supposed fixed the bug. Maybe this needs to be added to the CG more explicitly? Since the issue tracker offers just Fixed as a default, I see no way a contributor can really guess differently given the current state of tracker and documentation. fixed_2_15_xx is not a status, but a custom tag that you inserts in the tag text boxes at the bottom. It makes the life of the bug squad much easier, and you are already aware of the version number (since it's the version that you put into the regtest ;-) ) Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Horizontal spacing depends on stem 'direction
Am Donnerstag, 22. September 2011, 12:55:47 schrieb Janek Warchoł: 2011/9/22 David Kastrup d...@gnu.org: I see James already added the message. I don't always figure out what kind of reply ends up in the tracker automatically (probably just those sent directly by Rietveld's tracker) and what not. I also have this problem. I can only say that nothing sent to Rietveld - eiter directly or indirectly - never goes to google tracker automatically. Rietveld: All replies cc'ed to re...@codereview.appspotmail.com will be appended to the patch as a comment. Issue tracker: NO email replies will be appended to the tracker at all. Also, no replies to code reviews on rietveld will ever be added as a comment. You'll have to add any comment there manually (which means all email replies to bug-lilypond will be lost). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: possible bad output in mensural-ligatures.ly
Am Donnerstag, 22. September 2011, 18:07:42 schrieb David Kastrup: Graham Percival gra...@percival-music.ca writes: On Thu, Sep 22, 2011 at 02:11:53PM +0300, Dmytro O. Redchuk wrote: On Thu 22 Sep 2011, 13:01 Janek Warchoł wrote: However, according to Benko Pal we shouldn't worry about it: 2011/9/19 Benkő Pál benko@gmail.com: this is an impossible ligature, LilyPond should (but never did) refuse it (with an explanation). I wouldn't say refuse it, I would propose to print a warning and continue processing (like we do with all other kinds of wrong input) If lilypond should refuse it (with an explanation) -- please, can anyone prepare a tiny example? If somebody says this is a regression test, then you can skip the tiny example and just add it directly. All our developers know what the regression tests are. :) I don't think we can currently employ regression tests that have _failure_ as the desired behavior. We can. Look at input/regression/safe.ly Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1008 in lilypond: Some warning/error messages are not prefixed with 'warning:'/'error:'
Am Sunday, 18. September 2011, 07:58:39 schrieb m...@apollinemike.com: Just a heads up - in current master, my compilations now look like: Processing `span-bar.ly' Parsing... Interpreting music... Preprocessing graphical objects... Finding the ideal number of pages... Fitting music on 1 page... Drawing systems... Layout output to `span-bar.ps'...Converting to `./span-bar.pdf'... Success: compilation successfully completed (the Layout and Converting are now on the same line) Is this a result of b551257a9d5d4bd1b57d32ac0cea4684260dfd83 ? Fixed, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: No pf dynamic marking in dynamic-scripts-init.ly
Am Saturday, 17. September 2011, 15:29:45 schrieb Werner LEMBERG: I added the variable definition pf = #(make-dynamic-script pf) to my ly source, but is there any reason why this should not be added to dynamic-scripts-init.ly? That already contains fp as a dynamic marking, why not pf? I don't see why it couldn't contain more permutations of 'p', 'f' and even 'z' (I seem to remember that I had to manually create a dynamic for a few pieces that had things like szfp or sfffp (or similar - I cannot remember). IMHO, this unnecessarily pollutes the macro namespace. Just imagine that someone wants to define a macro which prints `Pianoforte' in some way, and she decides to call it \pf just to discover that this name is already taken... Where's the problem? You can always override already used command names... BTW, in my orchestrallily package I have two new dynamic scripts, which I need regularly: \fp and \sffz And I have \pdolce, and some bracketed / parenthesized dynamics. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: multiple fret-diagram-x markup commands and lilypond safe-mode
Am Friday, 16. September 2011, 23:05:49 schrieb Julien Rioux:
After dumping guile 1.8.7 provided by the official ubuntu repository, I
downloaded, compiled and installed the latest stable guile 1.8.8 and
recompiled latest lilypond git. I still get the failure.
I simplified the test case by taking lilypond-book out of the process.
The attached contains two lilypond snippets which compile correctly with
independent calls
lilypond -dbackend=eps snippet-1.ly
lilypond -dbackend=eps snippet-2.ly
, but combining them in a single call with
lilypond -dbackend=eps -dread-file-list snippet-names.ly
exits with an error when processing the second snippet. It's as if some
state has changed inbetween processing the two snippets, and the parsing
goes awry on the second one.
I can reproduce the problem on a ubuntu machine with current head (optimized
build), guile 1.8 (standard ubuntu package). I stripped down the test cases to
minimal files (attached). To reproduce the problem, simply compile them as:
lilypond s1.ly s2.ly
The error message here is:
reinhold@einstein:~/temp/safe-mode-bug$ lilypond s1.ly s2.ly
GNU LilyPond 2.15.12
Processing `s1.ly'
Parsing...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `s1.ps'...
Converting to `./s1.pdf'...
Processing `s2.ly'
Parsing...
s2.ly:5:21: error: GUILE signaled an error for the expression beginning here
\fret-diagram-terse #
x;x;o;2;3;2;
Wrong type argument in position 1 (expecting module): #freed cell 0xb6d06880;
GC missed a reference
/home/reinhold/lilypond/lilypond/out/share/lilypond/current/scm/fret-
diagrams.scm:886:17: In procedure string-split in expression (string-split
definition-string #\;):
/home/reinhold/lilypond/lilypond/out/share/lilypond/current/scm/fret-
diagrams.scm:886:17: Wrong type argument in position 1 (expecting string):
#unspecified
So it seems like some guile Garbage Collection messup...
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.15.12
#(ly:set-option 'safe #t)
\markup{
\fret-diagram-terse #x;3;2;o;1;o;
}
\version 2.15.12
#(ly:set-option 'safe #t)
\markup{
\fret-diagram-terse #x;x;o;2;3;2;
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: multiple fret-diagram-x markup commands and lilypond safe-mode
Am Saturday, 17. September 2011, 18:00:50 schrieb Julien Rioux:
On 17/09/2011 5:48 PM, Reinhold Kainhofer wrote:
So, I think we can rule out any backend-cause.
I just checked all the banckends I got ('eps, 'null, 'ps, 'scm, 'socket,
'svg), and with guile 1.8.8 it only happens with the eps backend.
Finding any cause here is a real bugger.
In guile 1.8.7 (Ubuntu stock package) it happens with any backend.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Staves with StaffSymbol #'line-count = #1 produce not a number warnings and wrongly cropped images
The attached minimal example sets the staff's StaffSymbol #'line-count = #1
which causes several NaN warnings. Furthermore, the preview image is cropped
way too much (apparently only the staff lines and the note heads are taken
into account for the height of the image).
Error output is:
reinhold@einstein:~/lilypond/lilypond$ LANG=C lilypond -dpreview staff-one-
line-NaN.ly
GNU LilyPond 2.15.12
Processing `staff-one-line-NaN.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
programming error: insane spring min_distance requested, ignoring it
continuing, cross fingers
programming error: Infinity or NaN encountered
continuing, cross fingers
Layout output to `staff-one-line-NaN.ps'...
warning: Found infinity or nan in output. Substituting 0.0
warning: Found infinity or nan in output. Substituting 0.0
Converting to `./staff-one-line-NaN.pdf'...
Layout output to `staff-one-line-NaN.preview.eps'...
warning: Found infinity or nan in output. Substituting 0.0
warning: Found infinity or nan in output. Substituting 0.0
Converting to `./staff-one-line-NaN.preview.pdf'...
Converting to PNG...
Success: compilation successfully completed
cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.15.12
\new Staff \with { \override StaffSymbol #'line-count = #1 }
{
c''1
}
staff-one-line-NaN.pdf
Description: Adobe PDF document
attachment: staff-one-line-NaN.preview.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
scheme engravers cause Warnung: Attempting to remove nonexisting listener.
If one uses a scheme engraver that instantiates itself for each context, i.e.
\consists #(lambda (context) ...)
then using listeners will cause the warning:
Warnung: Attempting to remove nonexisting listener.
Minimal test case attached. Output on the console is:
reinhold@curie:~$ LANGUAGE=C lilypond Issue_RemovingNonExistingListener.ly
GNU LilyPond 2.15.12
Processing `Issue_RemovingNonExistingListener.ly'
Parsing...
Interpreting music...
warning: Attempting to remove nonexisting listener.
warning: Attempting to remove nonexisting listener.
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `Issue_RemovingNonExistingListener.ps'...
Converting to `./Issue_RemovingNonExistingListener.pdf'...
Success: compilation successfully completed
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.15.12
\layout {
\context {
\Voice
\consists
#(lambda (context) `((listeners . ((note-event . ,(lambda (eng ev) #t))
% This works, because it does not create a copy for each voice:
% \consists
% #'((listeners . ((note-event . ,(lambda (eng ev) #t)
}
}
\relative c'' {
{ c4 } \\ { c4 }
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Setting Score.voltaSpannerDuration to shorten a volta bracket causes warning
The attached minimal example (taken from an LSR snippet) cause the volta
engraver to print a warning, although the file is perfectly fine and should
work without a warning:
reinhold@einstein:~/lilypond/lilypond$ LANGUAGE=C lilypond volta-bracket-
shortening.ly
GNU LilyPond 2.15.12
Processing `volta-bracket-shortening.ly'
Parsing...
Interpreting music...
warning: cannot end volta spanner
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `volta-bracket-shortening.ps'...
Converting to `./volta-bracket-shortening.pdf'...
Success: compilation successfully completed
The Volta_engraver::process_music checks for each ongoing repeat whether a
bracket exists. if it doesn't it prints that warning, even though the bracket
might have been ended earlier legally.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.15.12
\header {
texidoc =
By default, the volta brackets will be drawn over all of the
alternative music, but it is possible to shorten them by setting
@code{voltaSpannerDuration}.
}
\relative c'' {
\time 3/4
\set Score.voltaSpannerDuration = #(ly:make-moment 3 4)
\repeat volta 2 { d2. }
\alternative {
{
e2.
f2.
}
{ g2. }
}
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Seting staff-staff-spacing in a \with block causes type check error
The attached minimal testcase (stripped down from an example in our docs)
prints a type-check warning for a nested property:
reinhold@einstein:~/lilypond/lilypond$ LANGUAGE=C lilypond staff-staff-
spacing-list.ly
GNU LilyPond 2.15.12
Processing `staff-staff-spacing-list.ly'
Parsing...
Interpreting music...
warning: type check for `staff-staff-spacing' failed; value `((stretchability
. 5) . #primitive-procedure ly:axis-group-interface::calc-staff-staff-
spacing)' must be of type `list'
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `staff-staff-spacing-list.ps'...
Converting to `./staff-staff-spacing-list.pdf'...
Success: compilation successfully completed
This should actually not happen, so I guess the type check is not general
enough to handle nested context props.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.15.12
\new Staff \with {
\override VerticalAxisGroup #'staff-staff-spacing #'stretchability = #5
} \relative c' {
c1
}___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: programming error: no solution found for Bezier intersection
Am Wednesday, 14. September 2011, 06:47:50 schrieb Colin Campbell:
On 11-09-13 09:29 PM, Nick Payne wrote:
Ok, the following small example reproduces the error on my system with
2.15.11:
The minimal example is (the normal fingering -1 does not have any influence,
so it should be removed, too, and the language is also not relevant):
%==
\version 2.15.11
\relative c'' {
\set strokeFingerOrientations = #'(up)
\override StrokeFinger #'avoid-slur = #'outside
a-\rightHandFinger #2 16( b)
}
%==
This example shows clearly that StrokeFinger is to blame here.
The warning appears only with #'avoid-slur=#'outside, not with 'inside.
However, the actual value of strokeFingerOrientations is not relevant (as long
as you set it to some value), the warning appears both with #'(up) and with
#'(down).
If I get rid of the right hand fingering then the error goes away, and
if I comment out the override for StrokeFinger #'avoid-slur then the
error also goes away but the log contains the warning:
/home/nick/lilypond/examples/test.ly:14:13: warning: Ignoring grob for
slur: StrokeFinger. avoid-slur not set?
as-1
-\rightHandFinger #2 16( b)
That's definitely a bug. The StrokeFinger seems to be missing the avoid-slur
property (and there seems to be a regtest missing for StrokeFinger).
Nick, one of our developers is working on Bezier range calculations:
there is an open tracker item
(http://code.google.com/p/lilypond/issues/detail?id=1784
http://code.google.com/p/lilypond/issues/detail?id=1784) which sounds
like your problem.
I guess only Mike Solomon can answer that question, since he didn't describe
which problem he tries to solve with the patch...
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1887 in lilypond: Doc: adding doc strings for \...DashPattern and \harmonicBy...
Am Wednesday, 14. September 2011, 20:42:04 schrieb lilyp...@googlecode.com: while working on issue 1135 (which is closed now!) I found out that some functions still lack a proper doc string. Attached is a patch which adds the missing (_i ...) to four of them. Here's a patch that changes make to print out a warning for each undocumented music function and each undocumented context modifier: http://codereview.appspot.com/5003051 Unfortunately, lilypond is called with --verbose in Documentation/GNUmakefile, so these warnings are hidden inside hundreds of useless string lines :( Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1776 in lilypond: Doc: NR - Polymetric Notation \compoundMeter isn't documented
Am Saturday, 10. September 2011, 21:22:30 schrieb lilyp...@googlecode.com: Comment #32 on issue 1776 by percival.music.ca: Doc: NR - Polymetric Notation \compoundMeter isn't documented http://code.google.com/p/lilypond/issues/detail?id=1776 2.14.2, and then clear out everything in Documentation/snippets/new/ that can live on 2.14. Feel free to recruit volunteers to add those snippets. By the time you (and/or volunteers) have finished that, it'll probably be time to bump it up to 2.16.1 or so. I don't recommend waiting; the task is less daunting if you do it in increments. And ideally, you should add instructions on upgrading LSR to a new version to the CG, and then we could try to get somebody else to do the 2.16 upgrade (following those instructions). Reinhold has some effort to build LSR locally, but I don't have the url handy, and in any case that's still weeks away so I think it's worth upgrading the current LSR. http://lsr.kainhofer.at http://wiki.kainhofer.com/lilypond/lsr_setup Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: musicxml2ly does not recognize clef elements containing number attributes
Am Freitag, 9. September 2011, 21:31:01 schrieb Patrick Schmidt: here is a tiny example to demonstrate the issue: the musicxml2ly-conversion results in a common treble clef instead of a bass clef when the XML-clef-element contains a number attribute and a value, [..] P.S.: my first email probably got lost so I sent another one. Just in case: Sorry for double posting. Nope, it wasn't lost. There's even already a patch in our code review system to fix the problem: http://code.google.com/p/lilypond/issues/detail?id=1876 http://codereview.appspot.com/4991044 Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: tests for flower appear to miss instantiations of classes
Am Donnerstag, 8. September 2011, 14:13:12 schrieb David Kastrup: When configured with ./configure CXXFLAGS=-fkeep-inline-functions (which does not optimize unused functions away) make test fails in the flower subdirectory in the linking stage with quite inscrutable error messages. I'm able to reproduce this (with ./configure CXXFLAGS=-fkeep-inline-functions --disable-optimising). If I do cd flower; make clean; make test, I get the following error: g++ -o out/test-flower ./out/test-file-name.o ./out/test-file-path.o ./out/test-std.o ./out/test-string.o ./out/../../flower/out/library.a ./out/test-file-name.o: In function `recursive_init_error': /usr/include/c++/4.5/cxxabi.h:623: undefined reference to `vtable for __gnu_cxx::recursive_init_error' collect2: ld returned 1 exit status make: *** [out/test-flower] Fehler 1 A quick google search for the error message brings this up: http://www.daniweb.com/software-development/cpp/threads/114299 http://gcc.gnu.org/faq.html#vtables The problem appears to be in flower/include/yaffut.hh, because if I strop down test-file-name.cc to only include that file (instead of yaffuf-parameters.hh) and remove all other code there, I still get the linker error... Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: musicxml2ly does not recognize clef elements containing number attributes
Am Donnerstag, 8. September 2011, 18:29:21 schrieb Patrick Schmidt: here is a tiny example (see file attached) to demonstrate the issue: the musicxml2ly-conversion results in a common treble clef instead of a bass clef. Without the number attribute everything works as expected. MusicXML allows number attributes in clef elements, so it's valid XML-code. Patch is up at http://codereview.appspot.com/4991044 Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Whole measure rest is too narrow (compared to whole measure note)
In the attached example, the full-bar rests are way too narrow, compared to
measures with multiple note, and even to measures with one full-measure note.
This is not just ugly, musicians have real problems playing from these notes,
as I experienced with some friends (professional string musicians!). The rest
simply does not look long enough!
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.15.10
\relative c' {
\time 3/4
\repeat unfold 3 {
f g b | d r4 r4 | R2. | c,2. |
}
}attachment: full-bar-rest-too-narrow.preview.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Presence of a bar number changes whole-measure rest width significantly
If there is bar number printed after a measure, a full measure rest will be
much longer than if there is no bar number printed. Simple example attached.
A bar number should not have an influence on horizontal spacing!
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.15.10
\layout {
\context {\Score
\override BarNumber #'break-visibility = #end-of-line-invisible
barNumberVisibility = #(every-nth-bar-number-visible 3)
% barNumberVisibility = #all-bar-numbers-visible
}
}
\relative c'' {
\set Score.currentBarNumber = #183
\time 3/4
c2. |
R2. |
R2. |
R2.
\repeat volta 2 {
c4\p^arco r r
c4 r r
c4 r r
c4 r r
c4 r r
}
}attachment: full-bar-rest-bar-number.preview.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \tempo indication not printed
Am Monday, 5. September 2011, 09:41:58 schrieb Dmytro O. Redchuk:
On Thu 01 Sep 2011, 16:06 Reinhold Kainhofer wrote:
BTW, this is a really minimal example:
\version 2.15.9
{
s1
\tempo Waldo
s1
}
Neil mentioned issue 1276. What do you think, should this one be a separate
issue?
AFAICS, it's a separate issue. 1276 wrongly aligns on the note, even if it
should align on other grobs, while this issue does not print the mark at all,
because there is no column to attach that survives.
cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Explicit fingering direction (^3) has no effect if Fingering #'direction is set
Am Sunday, 4. September 2011, 08:50:47 schrieb -Eluze: Reinhold Kainhofer wrote: If the Fingering grob has an explicit direction set, it is NOT possible to override it with an explicit direction in the input: \override Fingering #'direction = #DOWN c'4-3 c'4^3 c'4_3 c'4-3 | using \set fingeringOrientations = #'(…) to set directions you can override its behavior ad hoc (with _ or ^)! Unfortunately, \voiceOne sets the 'direction, so inside \voiceOne you CANNOT override the behaviour with ^ or _. That's how I found that problem. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
dynamics on chords with notehead to left and right of stem are wrongly aligned
Dynamics on chords with a notehead to the left and to the right of the
stem align differently than when there are only noteheads to the right.
Simple test case is attached. The two \pp don't line up as they should.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
attachment: dynamics-alignment-twonoteheads.preview.png\version 2.15.10
% Dynamics on chords with a notehead to the left and to the right of the
% stem align differently than when there are only noteheads to the right
\score {
\new Staff \relative c'' { c d2\pp }
\new Staff \relative c'' { c e2\pp }
}___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1295 in lilypond: Support for Mac OSX 10.3.9 Panther is broken
Am Saturday 03 September 2011, 19:28:08 schrieb Dmytro O. Redchuk: On Fri 02 Sep 2011, 21:42 lilyp...@googlecode.com wrote: Updates: Status: Verified Comment #8 on issue 1295 by percival.music.ca: Support for Mac OSX 10.3.9 Panther is broken http://code.google.com/p/lilypond/issues/detail?id=1295 Every item in issues to be verified should be verified. Yes. However I was not so wrong this time .) For some reason Invalid issues need not to be verified, please compare: http://code.google.com/p/support/issues/detail?id=2612 However, duplicate reports are still in the list to verify, which they shouldn't... Cheers, Reinhold -- -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * Edition Kainhofer Music Publishing, http://www.edition-kainhofer.com/ * LilyPond music typesetting software, http://www.lilypond.org/ signature.asc Description: This is a digitally signed message part. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Explicit fingering direction (^3) has no effect if Fingering #'direction is set
If the Fingering grob has an explicit direction set, it is NOT possible to
override it with an explicit direction in the input:
\override Fingering #'direction = #DOWN
c'4-3 c'4^3 c'4_3 c'4-3 |
In this example, all fingerings will be below the staff, but the second one
should still be above, since ^ is explicitly given. Full example is attached.
The only way to override is with an explicit
\once\override Fingering #'direction = #UP
Cheers,
Reinhold
PS: For other grobs, like DynamicText or DynamicLineSpanner an explicit
direction (^ or _) overrides the Grob's direction.
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
fingering-direction-override.pdf
Description: Adobe PDF document
\version 2.15.10
\paper { line-width = 9\cm tagline =##f}
\markup\wordwrap { Fingering direction is set to DOWN, but explicit
directions should override. The given directions here are: default, UP, DOWN, default
}
\score{
\new Staff {
\override Fingering #'direction = #DOWN
c'4-3 c'4^3 c'4_3 c'4-3 |
}
}___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \tempo indication not printed
Am Donnerstag, 1. September 2011, 14:26:02 schrieb Neil Puttock:
On 1 September 2011 13:06, Valentin Villenave valen...@villenave.net
Unless *anyone* can explain what's going on therebelow, that is.
I think this is to do with the way barlines are treated by the
engraver. We have a special case for full-bar rests which ensures the
tempo mark is aligned on the barline. Unfortunately, it looks like
it's preventing the mark from appearing in an empty bar.
BTW, this is a really minimal example:
\version 2.15.9
{
s1
\tempo Waldo
s1
}
The issue is that the moment after the \tempo command does not have any grobs
where the tempo could be attached to. As soon as you change the s1 to a note
or rest, or if you have clef/key/timesig change at the same moment as the
\tempo, the tempo mark can be reparented. But it seems that the engraver
misses the case that there are no other grobs at the same moment as the \tempo
change. In that case, the tempo mark should be reparented to the barline...
The check currently is:
if ([check for MM rest])
...
else if (!support_)
{
if (Grob *mc = unsmob_grob (get_property (currentMusicalColumn)))
text_-set_parent (mc, X_AXIS);
else if (Grob *cc = unsmob_grob (get_property (currentCommandColumn)))
text_-set_parent (cc, X_AXIS);
}
So, the mark is always assigned the currentMusicalColumn as parent (confirmed
by some debug statements). I think I read somewhere that later on the
currentMusicalColumn is deleted if it does not contain any grobs... Am I
wrong?
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Fix 1821: Write pathes for ly-to-tely to a separate file rather than passing as cmd line args (issue 4950053)
Am Mittwoch, 31. August 2011, 06:26:59 schrieb percival.music...@gmail.com: sweet mao that's disgusting. I love it. :) If you can make doc from scratch, then push. Actually, with my test setup, I can't even build lilypond, because metafont already fails with some long pathes: I created the path /data/lilypond/This-is-a-very-long-path-to-the-lilypond- source-directory/And-it-contains-several-long-sub-directories/Which-should- break-the-makefile/Because-the-call-to-lys-to-telys-will-be-longer-than-the- allowed-13-characters/ and symlinked my lilypond sourcedir there. Then I configured an out-of-source build in /data/lilypond/build1 and ran make. The binary built fine, but metapost fails with a memory corruption in glibc! In particular: lilypond@curie:~/build1/mf/out$ mpost -progname=mpost -ini /data/lilypond/This-is-a-very-long-path-to-the-lilypond-source-directory/And- it-contains-several-long-sub-directories/Which-should-break-the- makefile/Because-the-call-to-lys-to-telys-will-be-longer-than-the- allowed-13-characters/lilypond/mf/mf2pt1.mp \\dump This is MetaPost, version 1.208 (kpathsea version 5.0.0) (INIMP) (/data/lilypond/This-is-a-very-long-path-to-the-lilypond-source-directory/And- i t-contains-several-long-sub-directories/Which-should-break-the- makefile/Because -the-call-to-lys-to-telys-will-be-longer-than-the-allowed-13- characters/lil ypond/mf/mf2pt1.mp*** glibc detected *** mpost: double free or corruption (!prev): 0x0a0ebab0 *** === Backtrace: = /lib/i386-linux-gnu/libc.so.6(+0x6b961)[0x17b961] /lib/i386-linux-gnu/libc.so.6(+0x6d28b)[0x17d28b] /lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0x18041d] mpost[0x80625f1] mpost[0x8062686] mpost[0x8077f90] mpost[0x808c08b] mpost[0x804ad3d] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x126e37] mpost[0x80495f1] === Memory map: 0011-0026a000 r-xp 08:01 1097937/lib/i386-linux- gnu/libc-2.13.so 0026a000-0026b000 ---p 0015a000 08:01 1097937/lib/i386-linux- gnu/libc-2.13.so 0026b000-0026d000 r--p 0015a000 08:01 1097937/lib/i386-linux- gnu/libc-2.13.so [...] Any idea? Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1783 in lilypond: Spaces in filenames don't work with -danti-alias-factor option
Am Mittwoch, 31. August 2011, 15:28:23 schrieb lilyp...@googlecode.com: Comment #3 on issue 1783 by brownian.box: Spaces in filenames don't work with -danti-alias-factor option http://code.google.com/p/lilypond/issues/detail?id=1783 I have got this warning: Converting to PNG...pngtopnm: /home/dor/lilypond/usr/lib/libpng12.so.0: no version information available (required by pngtopnm) This means that the lilypond build of the release didn't compile libpng with version info included. Since that library is not installed system-wise, I don't see a problem there. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org signature.asc Description: This is a digitally signed message part. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1767 in lilypond: Feta font - change breve vertical lines
Am Mittwoch, 31. August 2011, 16:56:10 schrieb Dmytro O. Redchuk: On Sat 13 Aug 2011, 14:56 lilyp...@googlecode.com wrote: Updates: Labels: fixed_2_15_9 I can not change it to Verified, because of Issue owner must be a project member -- what's wrong? Nothing. Graham or someone with admin rights on the bug tracker needs to add janek to the project members on code.google.com... Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1756 in lilypond: architecture diagram image is missing
Am Sunday, 28. August 2011, 16:26:47 schrieb lilyp...@googlecode.com: you'll see this. There are lots and lots of other images/lines that are too long and I will fix these, but am waiting for the lilypond-book changes to get committed so that the bars created by -book disappear. Sorry, I haven't yet found the time to commit all those patches that already went through the countdown... I hope to get it done tomorrow. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: grace synchronization
Am Friday, 26. August 2011, 22:59:47 schrieb Hans Aberg: My impression is that there is a mixture of code, sometimes putting the grace-note before the bar, and sometimes after. A fix might allow one to fine-tune that. Actually, lilypond's handling is way more abstract. There are no checks for grace notes or whether something should come before or after a barline. Rather, lilypond simply sorts every music event (note, time sig, barline, etc.) according to when they appear (their moment). Events that are between notes (like a time signature change, a clef, a barline etc. are assigned to the begin of the moment of the next note. LilyPond then simply goes through all the events in time order. Now, the problem with grace notes is that they introduce a second counter (an 8th before the beat, a 16th before the beat etc.). LilyPond still goes through everything in the correct order, grace notes will simply be handled before the actual beat. However, things start going wrong if one voice has a grace note, while another one does not. Let us look at the following very simple example (remember, in lilypond the first beat is numbered 0, not 1!): -) Voice 1: c4 c4 In voice 1, the first c4 is at the moment 0/4, the second at 1/4. The grace moment of each is 0 (i.e. no grace, at the beat). -) Voice 2: c4 \grace e8 c4 In voice 2, the first c4 is again at moment 0/4, grace moment 0. The grace e8 belongs the second quarter, so it's moment is 1/4, but the grace moment is -1/8 (i.e. 1/8 grace before the second quarter). The c4 is again at 1/4. -) Voice 3: c4 \clef bass c4 c4 is at 0 (grace 0), the clef at 1/4 (grace 0) (same moment as the following c4), the c4 is at 1/4 (grace 0) -) Voice 4: c4 \clef bass \grace e8 c4 c4 is at 0 (grace 0). As I wrote above, all events between notes are assigned the time of the next note, which for the \clef is the grace. The grace has a moment of 1/4 (grace -1/8) like in voice 2. So the clef also has a moment of 1/4 (grace -1/8). Now, all four voices separately give correct results. However, if you combine them in one score, you see that in voice 3 you have a clef at moment 1/4 (grace 0), while in voice 4 you have a clef at moment 1/4 (grace -1/8). So, you have two clef changes at two different times! That's exactly what LilyPond observes, and in most cases it will really duplicate stuff, once before and once after the grace. Cheers, Reinhold PS: If you think the problem can easily be solved by simply handling all events between notes before the next following note rather than together with the next noted, please think though Voice 3 from above with -) Voice 5: c4 \grace e8 \clef bass c4 -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: grace synchronization
Am Friday, 26. August 2011, 23:05:26 schrieb Kieren MacMillan:
Well, here's an curious discovery: If you have a global variable
simultaneous-ed into the Voice/Staff context(s), the extra skipped
grace note MUST BE IN THE GLOBAL, not just explicitly placed in the other
Voice(s)/Staff(s).
Exactly. The detailled example in the other mail I just sent a second ago
explains why.
global = { \key a \major s1 \break s1 }
The break will be handled by lilypond at moment 4/4 (grace 0), or in short
4/4G-0.
notesA = \relative {
c1
\acciaccatura { d8 } e1
}
The acciaccatura d8 is at moment 4/4G-1/8, which is earlier than the break
above (which is at 4/4G-0). Additionally, the acciaccatura adds a slur from
moment 4/4G-1/8 to moment 4/4G-0, so the \break appears during an active slur!
While that solves the problem in this minimal example, it doesn't in my
piece (which includes multiple split voices, etc.).
It would if you found all split voices in use. But I totally agree that it
would be much better to have this fixed once and for all.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: grace synchronization
Am Saturday, 27. August 2011, 01:31:43 schrieben Sie: If you have a series of negative infinitesimal values before each event, with preferences of the sort always put this before that, ordinals might be used to describe it. Formally using pairs (r, x), where r is a Rational, and x an ordinal. See http://en.wikipedia.org/wiki/Ordinal_number You would only a small subset of the ordinal, enough to express those preferences. Then x = 0, the first ordinal, would be the time of the note, or last thing to output. Higher ordinals would be infinitesimal times before that. That's exactly how a Moment in lilypond works: a Pair of rationals: (timestep, grace time before the actual step) written in short e.g. for an eighth grace before the second quarter: 1/4G-1/8 or 1/4G-0 (= 1/4) for the actual second quarter. The problem is what is the default for the second value (the grace moment)? While processing a voice like c4 \clef bass c4 you have no information about graces in other voices, so you can either set 0 (together with the next c4, as it is currently done) or -inf (i.e. before the c4 and all grace notes appearing at that time step). You will have to decide to assign the clef to either 1/4G-0 or 1/4G-inf. Now, either of those breaks when combined with one of the following two: c4 \clef bass \grace e8 c4 (clef at 1/4G-1/8 or 1/4G-inf) or c4 \grace e8 \clef bass c4 (clef at 1/4G-0 in both cases) Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Website: Provide LilyPond source together with the example output
Am Mittwoch, 24. August 2011, 13:43:43 schrieb Janek Warchoł: 2011/8/24 Štěpán Němec step...@gmail.com: I think that David's point was that the scores are too big and complex to be shown in their entirety, because they'll scare beginners. I think he suggests that the mouse-over bubble would show only a small part of the code, directly relevant the the object pointed to. What's the point of showing some code that you can't copy and compile in its entirety? That's even more pointless. We shouldn't show the code by default, that's what we all agree, I think. But we should make it possible for the users to easily download the whole code for each example to that they can start playing with it. A click on the image shows an enlarged image (which we shouldn't change to showing the code), but we can add a Download LilyPond code linke next to the image. That would be the best solution, IMO. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org signature.asc Description: This is a digitally signed message part. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1834 in lilypond: Website: provide link to .ly for examples
Am Mittwoch, 24. August 2011, 15:19:57 schrieb David Kastrup: lilyp...@googlecode.com writes: The examples are often too complex and lengthy to be really useful to beginners. As above, they wouldn't work in mouse-over bubbles. The mouse-over bubble would show a looking-glass view into the source, centered at the corresponding view. In my eyes, this would defeat the purpose of the examples page. Our message to newcomers there is Look, how beautiful LilyPond scores can be. If we force a mouse-over bubble with lilypond code on every visitor, then the message becomes You can do pretty scores, but just look how terribly complicated and uncomprehensible it is to write a score with lilypond. Will that incite any non-programmer to use lilypond? The main purpose of the examples page is to show off beautiful engravings with LilyPond. It is aimed at people who have never seen or used lilypond. We really don't want to show code there -- that what the LM / NR is for. However, IF some lilypond user wants to see the code for the examples, it should be easier to get it than using git to check it out from the source code. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: abc2ly get's lost
Am Dienstag, 23. August 2011, 13:55:28 schrieb Terry Therneau: Here is a snippet of a barbershop arrangement that causes Huh? message from abc2ly: % % Wails % [V:1][K:A] e4-|e2 (_ed)| c4-|c2 (e2| [K:Ab] e4-|e2) (=d_d)| c4| [V:2][K:A] c4-|c2 (=cB)| A4-|A2 (c2| [K:Ab] c4-|c2) (=B_B)| A4| w:Oo,_ Oo,_ Oo,_ Oo,__ Oo,_ Oo. [V:3][K:A] ae fe| ae f=f| ee fe| w:Bum ba bum ba bum ba bum ba bum ba bum ba f2 (=g2| [K:Ab] a)e fe| ae f_f| ee ff| w:bum Oo,_ ba bum ba bum ba bum ba bum ba bum ba [V:4] [K:A] A4-|A4-| A4-| A2 (A2| [K:Ab] A4-|A4-|A4) | w:Oo,___ Oo,___ 1. I add extra indentation for clarity; abc2ly doesn't like the lines that have whitespace before a w:. Whether this is a bug or not can easily be argued. I'll push a commit shortly that ignores all whitespace at the begin of a line. 2. After removing the white space we still have an error with the third line of the baritone part (V3). Currently, abc2ly assumes the order: ACCIDENTAL NOTENAME OCTAVE DURATION SLUREND So, your a)e confuses abc2ly, because the ) is before the duration... I haven't found anything about a possible order of elements in an abc file in the specification. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org signature.asc Description: This is a digitally signed message part. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Part_combine_iterator::last_playing_ notinitialized
Am Sunday, 21. August 2011, 11:01:24 schrieb Phil Holmes:
Dan Eble d...@faithful.be wrote in message
news:loom.20110821t044324-...@post.gmane.org...
I'm not top posting.
% valgrind reports that a member of Part_combine_iterator is used
% before being initialized. Initializing last_playing_ = SOLO1 in
% the constructor makes the warning go away.
\version 2.14.2
\partcombine { s } { s }
This compiles happily on my system. What is the example illustrating?
It compiles, but if you run ith through valgrind, you'll see that it accesses
an uninitialized variable. It usually doesn't crash, but there might be
circumstances where it does.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1691 in lilypond: Ugly bars in PDF documents
Am Saturday, 20. August 2011, 06:25:26 schrieben Sie:
Comment #41 on issue 1691 by percival.music.ca: Ugly bars in PDF documents
http://code.google.com/p/lilypond/issues/detail?id=1691
Trevor reminded us (by email) that lilypond automatically sets
ragged-right=##t if the music is less than a full line. This might be the
behavior Reinhold was seeing. If he was seeing it in a different context,
then this sounds like another bug. There's no reason why relative=1 should
imply ragged-right.
No, it was not the implicit ragged setting for one-line snippets. Rather, the
snippets' ly files have an exmplicit
ragged-right=##t
inserted.
The issue is that the relative snippet option implies the fragment option,
which seems to set the ragged-right=##t in all its snippets...
Attached is a simple example to show this, using three snippets with identical
contents, but different snippet options. The first snippet will not have
ragged-right, but the other two will get an explicit ragged-right=##t in the
snippet's .ly file. While this behavior is indirectly explained in the AU, it
does not really make sense from a user's standpoint that relative should
automatically imply ragged-right (having fragment imply ragged-right makes
sense to make it easier for documentation writers)
This deserves a bug report on its own.
To be honest, the whole snippet option handling seems to be a real mess right
now. I'll probably take a look at the whole snippet options handling system in
lilypond-book during the next few days. Probably we can properly analyze each
option's effects and make them more predictable (and correct).
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\input texinfo @c -*- coding: utf-8; mode: texinfo; -*-
@setfilename LineTest
@settitle PhilTest
@letterpaper
still problem:
@lilypond[]
\repeat unfold 50 { c'4 }
@end lilypond
@lilypond[fragment]
\repeat unfold 50 { c'4 }
@end lilypond
@lilypond[relative=1]
\repeat unfold 50 { c4 }
@end lilypond
@bye___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1691 in lilypond: Ugly bars in PDF documents
Am Friday, 19. August 2011, 23:06:36 schrieb Trevor Daniels: Are you sure relative=1 sets ragged-right? That would be silly. But ragged-right is set by LilyPond if there is only one system in the output. This seems quite sensible. Yes, relative=1 implies fragment, which on the other hand implies ragged-right (see also the docs for lilypond-book). This made sense when single-line files in lilypond didn't automatically switch to ragged-right. But now this fallback (fragmend implying ragged-right to prevent stretching for simple snippets) is no longer needed... Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1821 in lilypond: GUB argument list too long
On Di., 16. Aug. 2011 07:46:32 CEST, David Kastrup d...@gnu.org wrote: lilyp...@googlecode.com writes: I think it's literally that we have too many regression test files to fit into the current allowable file size. Use URL:info:make#Text%20Functions for splitting the file lists into two groups, like those starting with letters a-k and those that don't. I think the lys-to-tely call should stay one call. However, it would be quite simple to write the filenames to a file and pass that to lys-to-tely (like we do it in lilypond-book already for compiling the snippets). Cheers, Reinhold ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1821 in lilypond: GUB argument list too long
Am Tuesday, 16. August 2011, 12:06:30 schrieben Sie: Reinhold Kainhofer reinh...@kainhofer.com writes: I think the lys-to-tely call should stay one call. However, it would be quite simple to write the filenames to a file and pass that to lys-to-tely (like we do it in lilypond-book already for compiling the snippets). If we can't pass the filenames to a call of lys-to-tely because of command line length limits, I don't see us passing the filenames to echo or similar shell commands more easily in order to write them to a file. Well, first, maybe we can find a way to pipe the list to a file, so the list never appears in a shell command. If that doesn't work, then we can always split the list into smaller chunks, write each junk to the file and then call lys-to-tely on the file containing all filenames. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1821 in lilypond: GUB argument list too long
Am Tuesday, 16. August 2011, 12:47:13 schrieb Mike Solomon: On Aug 16, 2011, at 12:06 PM, David Kastrup wrote: If we can't pass the filenames to a call of lys-to-tely because of command line length limits, I don't see us passing the filenames to echo or similar shell commands more easily in order to write them to a file. The filenames can be written to a file via a python script, something like: ... and how do you get the list to the python script? Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: More \quoteDuring problems, with and without \partcombine
Am Dienstag, 16. August 2011, 04:30:34 schrieb Marnen Laibow-Koser:
1 (partcombine-omits-quotes): When two quoted parts are \partcombined, only
one part's notes remain in the combined staff. The 2 Flutes staff should
have all the notes from the Flute 1 and Flute 2 staves; it does not.
Part-combine does not work (and will probably never work) together with
quoting.
The technical reason is that the part-combiner does its stuff at a very early
stage of lilypond, while the quoting takes place at a very late stage of a
lilypond run.
2 (quotes-without-other-music): When there is no music in a staff except a
\quoteDuring, nothing is drawn. The Flute staff should be identical to
the Violin staff; it is not.
That's another problem of automatic voice creation in Lilypond, i.e. in most
cases you don't need to write \new Voice, but lilypond will do that for you.
In this case, you will have to write \new Voice in the flute explicitly,
because otherwise lilypond will fail to create the voice for you.
In particular, if you change your file to (notice the added \new Voice):
staffFlute = \new Staff \new Voice {
\set Staff.instrumentName = Flute
\fluteNotes
}
then everything works just fine.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: --png does not properly obey landscape setting
Am Monday, 15. August 2011, 13:22:33 schrieb Dmytro O. Redchuk: On Sun 14 Aug 2011, 22:22 Reinhold Kainhofer wrote: If one uses landscape setting, i.e. #(set-global-page-size a4 'landscape) then the output of lilypond --png landscape.ly will NOT be landscape (90 degree rotation is missing). The PDF file has the proper rotation. Should 413 be reopened? Or rather reincarnated? http://code.google.com/p/lilypond/issues/detail?id=413 It's a different issue. The image extent seems correct, just the rotation is missing. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
--png does not properly obey landscape setting
If one uses landscape setting, i.e.
#(set-global-page-size a4 'landscape)
then the output of lilypond --png landscape.ly will NOT be landscape (90
degree rotation is missing).
Attached is a sample file landscape.ly. Run it with
lilypond --png landscape.ly
and you will get a png like the attached one. While the staves are properly
layed out, the final png is missing the 90 degree rotation (i.e. the staves do
not got from left to right, but from bottom to top). The PDF file has the
proper rotation.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
attachment: landscape.png\version 2.15.9
#(set-default-paper-size a4 'landscape)
\relative c' { \repeat unfold 7 { c1\break}}
landscape.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
[PATCH] Re: GUILE error reporting has changed for worse in 2.15 (compared to 2.12), useless now
Am Mittwoch, 3. August 2011, 21:39:43 schrieb Reinhold Kainhofer: However, in lilypond 2.15.9 (and probably also some earlier versions), lilypond suddenly only prints out the error message, but not where the error occurred (neither file nor expression is displayed): [...] Is there any way to revert GUILE's error reporting back to the 2.12 verbose output? I think this deserves a bug report with priority High, according to the latest GOP-8 (anything which makes it difficult for serious contributors to help out (e.g. difficult to find the relevant source tree(s), [...]).) After some git bisect'ing, the offending commit is 52bea08ef73a55ee3091f3267ee7075c066d13c5, which removed all (debug-enabled debug) calls with the reason that they caused deprecation warnings (but also printed out vital path/backtrace information!). Here is a patch, which reverts those debug changes: http://codereview.appspot.com/4815085/ The reason for the initial removal was to suppress deprecation warnings with guile 2.0, but that should be easier achieved with setting warn-deprecated to #f. See guile's 1.8 documentation: http://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Debugger- options.html#Debugger-options And the 2.0 documentation: http://www.gnu.org/software/guile/manual/html_node/Debug-Options.html Any objections to applying this patch and reinstating the old, working behavior of scheme error messages? I have not tested the patch with guile 2.0, though, since I only have 1.8 installed and in use. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
GUILE error reporting has changed for worse in 2.15 (compared to 2.12), useless now
An example is attached. It contains just a faulty music-function that crashes
guile (car and cdr expect a pair, not an empty list):
aa = #(define-music-function (a b) () (car '()))
{ a\aa }
In 2.12, when you had an error in some GUILE code, lilypond would print out
the error together with the location where the error occured
GNU LilyPond 2.12.3
»crash.ly« wird verarbeitet
Analysieren...
crash.ly:4:2: In procedure car in expression (car (quote ())):
crash.ly:4:2: Wrong type (expecting pair): ()
However, in lilypond 2.15.9 (and probably also some earlier versions),
lilypond suddenly only prints out the error message, but not where the error
occurred (neither file nor expression is displayed):
GNU LilyPond 2.15.9
»crash.ly« wird verarbeitet
Analysieren...
ERROR: Wrong type (expecting pair): ()
As you can imagine, from this error output it is basically impossible to find
the correct location of broken guile code somewhere in out scm/ directory (see
also my comment at issue 1.770, which I wouldn't have been able to fix without
the 2.12 error message)
Is there any way to revert GUILE's error reporting back to the 2.12 verbose
output?
I think this deserves a bug report with priority High, according to the
latest GOP-8 (anything which makes it difficult for serious contributors to
help out (e.g. difficult to find the relevant source tree(s), [...]).)
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.12.0
aa = #(define-music-function (a b) ()
(car '())
(make-music 'Music))
{
a\aa
}___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1742 in lilypond: print transposed guitar chords on piano sheets
On Do., 4. Aug. 2011 00:28:37 CEST, lilyp...@googlecode.com wrote: no, because we have 10-ish other patches also waiting. ok, I should have picked 5 patches instead of 4, but I'm on a cheap netbook and I was bored with fighting my crappy 2cm trackpad to click through all the download patch + find out if it still applies or not. But you are aware of 'git cl patch issue_id' and 'git reset --hard origin/master', right? It shouldn't be too hard -- even on a small netbook (like my eeepc) -- to check whether a patch still applies. The hardest parts are probably finding the rietveld issue ids. Cheers, Reinhold ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: musicxml2ly.py conversion errors (two)
Am Samstag, 16. Juli 2011, 01:31:05 schrieb Ken Kellogg-Smith: 1. .ly source code: Internal measure numbering errors beginning at (jEdit) line 30 et. seq. musicxml2ly's measure numbering routine made two related discrepancies: (1) at line 30: measure #1 was identified as measure number #2, (2) at line 36: the measure number was duplicated (measure number 5 repeated). Both are no bugs. The measure number printed is always the number of the NEXT following measure. The reason is that you can then easily replace the % by \barNumberCheck #. And measure number 5 is not repeated for different measures. Rather, it is simply printed twice, once before the \mark and once after the mark, which is, however, at the same barline, so no discrepancy appears. 2. .ly source code: At (jEdit) line 61: the text Fine is incorrectly put in measure 22 instead of measure 21. This discrepancy directly impacted the appearance of the .pdf output file. The problem is that the mxl file uses a simple text markup before a barline, while in LilyPond such text markups can only be attached to notes and the like. Thus, we have to wait for the next note to attach the markup. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Partcombine: full bar rests
On Do., 14. Jul. 2011 20:14:48 CEST, Jean-Charles Malahieude lily...@orange.fr wrote: Hi all! Using the part combiner, I would prefer not to have to split a multimeasure rest or use tags in order to get what is on the second line. That's a known bug: http://code.google.com/p/lilypond/issues/detail?id=1677 Cheers, Reinhold ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1760 in lilypond: \RemoveEmptyStaves only works inside a \layout block
Am Mittwoch, 13. Juli 2011, 10:56:23 schrieb David Kastrup:
lilyp...@googlecode.com writes:
\RemoveEmptyStaves is defined inside engraver-init.ly, which renders
it inaccessible as an identifier outside a \layout block.
The following snippet causes the parser to emit two errors, and the
second bar isn't removed:
\version 2.15.5
\new Staff \RemoveEmptyStaves {
c'1 \break
r1
}
Wouldn't that need to be
\new Staff \with { \RemoveEmptyStaves } { ...
All the following three work:
mysettings = \with {...}
\new Staff \with { \mysettings } {...}
\new Staff \with \mysettings {...}
\new Staff \mysettings {...}
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Percussion Notation
Am Montag, 27. Juni 2011, 09:17:44 schrieb Janek Warchoł: 2011/6/27 cdg xratama...@hotmail.com or two slashes on a stemmed 8th note, not a fan. These appear to be the same thickness as a beam, and worse of all, are completely horizontal. So, is it possible to adjust the angle of these symbols? Yes. You need to override a property of the stem object to do this. (StemTremolo, to be more precise - stems of notes with tremolos are handled differently than regular notes, so a special object, StemTremolo, is used instead of regular Stem). I've looked this up in Elaine Gould's Behind Bars, and both stem tremolos on beamed notes (pp.224ff) as well as drum rolls (pp.294ff) use the same slope as the tremolo flags without beams. In no case is the tremolo beam adjusted to have the same slope as the beam. Gardner Read's Music Notation also shows an example on p.393 with the tremolo slashed NOT adjusted with the beam. Neither has Kurt Stone's Music Notation in the Twentieth Century (see pp.148ff). So, I couldn't find any reference that the tremolo slashes should be aligned with the beam. To the contrary, all standard notation reference use the same slope as on notes without a beam. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Partcombine: beaming
On Mo., 27. Jun. 2011 22:48:29 CEST, Jean-Charles Malahieude lily...@orange.fr wrote: While combining parts for a piano reduction (choral score), it appears that each time the first combine voice is lower than the other, beams are not combined : Exactly, the part-combiner does not combine the notes if there are voice crossings. Otherwise it would look like the first voice has the two A's and the second one the two F's, which is not the case. That's one of the explicit design goals of the part-combiner. Cheers, Reinhold ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \midi plays straight through repeat marks
Am Sonntag, 19. Juni 2011, 15:26:02 schrieb Graham Percival: On Sun, Jun 19, 2011 at 01:03:45PM +, Michael Hendry wrote: I'm trying to think of a situation where playing the second-time ending immediately after the first-time one would be desirable. I suppose that it would be helpful if midi output is being used as a proof-reading assistant, to reduce the time it takes to check the entire score. That is precisely the use case. LilyPond's midi output is intended as a proof-reading aid, not an audio performance tool. Still, it would often be useful to have a global flag to switch on/off repeat expansion for midi globally. That would be extremely useful in particular for tremolo repeats (but also for ordinary volta repeats sometimes)! Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \midi plays straight through repeat marks
Am Sonntag, 19. Juni 2011, 16:55:25 schrieben Sie:
On Sun, Jun 19, 2011 at 04:21:55PM +0200, Reinhold Kainhofer wrote:
Still, it would often be useful to have a global flag to switch on/off
repeat expansion for midi globally. That would be extremely useful in
particular for tremolo repeats (but also for ordinary volta repeats
sometimes)!
Didn't somebody add that in
704b06c2bbaebd2ce83e7c04481c12e8fbdf9363
? :)
Not that I can see. That command-line option would only give you the chance to
easily set such a global switch.
But AFAICS, there is currently no such flag to cause repeat expansion without
explicitly prepending \unfoldRepeats in the midi block...
E.g. suppose you have a file like
%
\version 2.15.0
\layout {}
\midi {}
\score {
\relative c'' {
\repeat tremolo 8 { c32 e }
\repeat percent 2 { c8 d }
}
}
\score {
\relative c'' {
\repeat tremolo 8 { c32 e }
\repeat percent 2 { c8 d }
}
}
%
Is there any current way to switch on/off expansion of the repeats in both
scores for the midi output, other than manually prepending \unfoldRepeats in
BOTH scores?
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Correct Figured Bass signs (slashed and crossed numbers)
Am Donnerstag, 9. Juni 2011, 13:22:06 schrieb Nils: I need correct baroque figured bass signs not the modern equivalents which Lilypond provides. Yes, that's a valid feature request in my eyes (actually, I'll need them too for my own editions). For example the slashed 6 where the slash is only in the upper part The slashed 6 in your example is apparently a very old variation. In most modern editions the slash is diagonally through the upper arc of the 6. or the slashed 4 where the slash goes vertically through the right side of the 4, creating a 4+. http://www.musiktheorie-aktuell.de/tutorials/regola/Hahn_petiteSixte.png . 6 in the lower row, 4+ in the upper. There are other signs like this, but if anyone knows at all what I'm talking about he or she will surely know the rest. Basically, a complete set of slashed digits that I encountered so far are: 2+ with the vertical slash through the extended horizontal line of the 2 4+ with the vertical slash through the extended horizontal line of the 4 5+ with the vertical slash through the extended horizontal line of the 5 6+ with the slash diagonally (left top to right bottom through the upper curve of the 6 See also: http://www.robertkelleyphd.com/FiguredBass.pdf Note, however, that these slashed 6 digits were used mainly only in hand- written scores and in modern printed scores. Many printed scores of the 19th centuries have the slashes for the 6 like lilypond. See e.g. page 8 of Mozart's Benedictus sit Deus, Alte Mozart Ausgabe (Wolfgang Amadeus Mozarts Werke, Serie III: Kleinere geistliche Gesangwerke. Leipzig: Breitkopf Härtel, 1880. Plate W.A.M. 117.): http://216.129.110.22/files/imglnks/usimg/5/53/IMSLP78470-PMLP158784- Mozart_Werke_Breitkopf_Serie_03_KV117.pdf (The 4+ is printed as described above, see e.g. p.13) On the other hand, some printed scores of the 19th century have the slashes as you suggest them E.g. line 2 measure 4, or line 6 measure 1 of: http://imslp.info/files/imglnks/usimg/e/ef/IMSLP32559-PMLP74139- Eybler_Graduale_DiesSanctificatus_HV61_Org.pdf I have encountered the 5+ only once: http://216.129.110.22/files/imglnks/usimg/0/0b/IMSLP32525-PMLP74102- Eybler_SperateInDeo_Org.pdf Anyone created such a set? If not, how can I do it on my own? (Publishers will) No, but it would be great to have it. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Partcombine
Am Dienstag, 31. Mai 2011, 22:18:49 schrieb Nels Daily:
I'm not top posting.
Partcombine function will not show the second voice in measure 11.
Here's the code:
That's a bug in the partcombiner (one of many...). I think a bug report is
suitable so that it doesn't get lost.
Attached is a stripped down example.
A short analysis of the bug:
The disappearing notes start after a multi-measure rest, which did start
earlier than a multi-measure rest in the first voice. The part-combiner walks
through the score as following:
1) In the first measure, only mI is playing, so it starts a solo (mII has a
multi-measure rest) and uses only the music events from mI
2) In the second measure both voices have a multi-measure rest, the solo of mI
has ended. As mII has a multi-measure rest already going on, the part-combiner
needs to take the multi-measure rest from mI (the part-combiner is not able to
split up a multi-measure rest!)
3) In the third measure, mII has a rest, so the first quarter is still detected
as unisilence (thus the rest from mI is still used). Now, as there is already
a whole measure rest going on, lilypond ignores the following notes.
Note that there are some other bugs in the part-combiner that can be seen with
this example:
-) If one replaces the r4 with a b4 in measure 3, then the notes are displayed
(marked as Solo II, but the whole-measure rest from mI is displayed, too.
-) If one adds a measure c1 to both voices, the r4 in mI is wrongly
printed as a full-measure rest (rests in unisilence are taken from the second
voice, unless voice one had a solo ending before the rest, like in the
original example)
-) If one adds any note after the R1*2 in mI, then the notes are correctly
printe.
As Xavier already mentioned, there is a workaround to force the partcombiner
to use a particular combining strategy. (Also note that the first quarter eight
rest in the third measure of your original example is printed as if there were
two voices present... Also in this case you need to tell the part-combiner
that the rest should be a solo, too. Don't worry, the Solo text will still
be printed on the first note, not on the rest).
Cheers,
Reinhold
\version 2.13.63-1 % necessary for upgrading to future LilyPond
versions.
hornthree = \relative c' {
\time 2/4
R2*2 r8 e16 r r8 e16 r r8 cis16 r r8 e16 r
R2*2 r8 e16 r r8 e16 r r8 d16 r r8 e16 r R2*6
}
hornfour = \relative c' {
\time 2/4
R2*10
%% These notes don't appear!!! %%
r8 b~ b b~ b b~ b b~ b b~ b b~ b b~ b b
}
\score {
{
\partcombine \hornthree \hornfour
}
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
pc.pdf
Description: Adobe PDF document
\version 2.15.0
mI = \relative c' {
r4 e e e |
R1*2
}
mII = \relative c' {
R1*2
%% These notes don't appear!!! %%
r4 b b b
}
\score{
\partcombine \mI \mII
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Strange \repeat tremolo
Am Montag, 30. Mai 2011, 10:56:16 schrieb Mario Moles:
Hi to all!
In this code \repeat tremolo and \change staff
don't work fine: why?
That's simply a bug in the tremolo code: It counts all elements of the tremolo
and assumes all of them are notes. So in the first case, LilyPond sees three
events (two notes plus the staff change), assumes they are all notes and
correspondingly adds the dot...
This problem deserves a bug report...
Can the attached (stripped-down) testcase be added to the report, too?
Codewise, the problem lies in scm/music-functions.scm, function make-repeat,
line 281:
(length (ly:music-property main 'elements))
instead of checking whether all elements are really notes.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.13.62
csr = \change Staff = right
csl = \change Staff = left
global = {
\key c \major
}
right = \relative c'' {
\global
% Doesn't work: The \change is counted as note, thus a dot is added
\csl \repeat tremolo 4 { f,,16 \csr f'}
% Works: Only two notes, correctly scaled:
\repeat tremolo 4 { f16 f'} |
}
\score {
\new PianoStaff
\new Staff = right \right
\new Staff = left { \clef bass \global \stemDown d,1 }
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1633 in lilypond: pdf utf-16be breaks doc compile
Am Sonntag, 24. April 2011, um 04:06:08 schrieb Colin Campbell: Here you go, Reinhold. I've done a complete new clone, then git pull -r, ./autogen.sh --noconfigure, mkdir build, cd build , make then make doc. The doc build failed identically to my original report, and I've attached the bach-schenker.ps file. Hmm, that .ps file does not even contain a DOCINFO block. However, it seems to be truncated, so lilypond fails earlier than I suspected... Are you on a 32 or a 64 bit system? And which OS? Thanks, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
In figured bass, _ direction indicator does not work (^ and - work)
In figured bass, attaching a text script to a skip (because one has to mark
tasto solo parts with t.s.) works, but it is not possible to use the _
direction indicator to print it below the staff. ^ and - work fine. Simple
test case attached.
The problem happens in 2.12 as well as in 2.13.
AFAICS, the problem is that in figured bass, _ is redefined in the parser to
mean an empty figure, so the parser does not detect it as a direction
modifier, even if it is used outside of a bass figure, i.e. not inside
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\version 2.12.3
ts = #(make-music 'TextScriptEvent 'text t.s. 'direction UP )
% fb = \figuremode { 54 s4^\ts 32 } % Works
% fb = \figuremode { 54 s4-\ts 32 } % Works
fb = \figuremode { 54 s4\ts 32 } % Works
% fb = \figuremode { 54 s4_\ts 32 } % Does NOT work!!!
n = \relative c' { c4 d e f }
\score {
\new Staff
\new Voice \n \fb
}
fb_figuremode_direction.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: tempo causes insertion of empty staff line
Am Sonntag, 20. März 2011, um 22:21:58 schrieb Phil Holmes: Philip Stolz phi...@gmx.de wrote in message news:loom.20110320t212309-...@post.gmane.org... % If tempo is specified for the whole score % lilypond adds an empty staff line. % This issue did not exist in version 2.13.49. % The first version where it occurred was 2.13.50. % It also exists in 2.13.54. [...] This is a very interesting regression. However, the example you provide is more complicated than necessary. I think the issue is that previously, the \tempo command simply set some context properties, while it now is a separate music event and thus causes an implicit voice to be generated if no voice is yet created. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bass figures are not horizontally aligned to whole notes
Am Dienstag, 1. März 2011, um 14:03:39 schrieb Bertrand Bordage:
\new Staff { \clef F f4 g g2 c1 d }
\figuremode {
5/4 6 4 4 _+ _!1 6/
}
Figures should be aligned to whole notes.
Workaround attached.
This is really just a quick workaround, no solution, as it badly breaks as
soon as a figure has an accidental:
\new Staff { \clef F c1 c c \bar |.}
\new FiguredBass \figuremode {
\figuredBassCenterOnNote
\set figuredBassPlusDirection = #RIGHT
51 6 4+ 2\+ 6
}
By default, the numbers are all aligned, irrespective of whether one of them
has an alteration (#, b, +). With your figuredBassCenterOnNote (which is a
good idea), that alignment of the numbers is totally lost.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
centered-figures.pdf
Description: Adobe PDF document
figuredBassCenterOnNote = \override BassFigure #'X-offset =
#(lambda (grob)
(let* ((paper-col (ly:grob-parent grob X))
(elts (ly:grob-object paper-col 'elements))
(figure grob))
(for-each
(lambda (idx)
(let ((elt (ly:grob-array-ref elts idx)))
(set! figure elt)))
(iota (ly:grob-array-length elts)))
(-
(interval-center (ly:grob-robust-relative-extent figure figure X))
(interval-center (ly:stencil-extent(ly:text-interface::print grob) X)
\pointAndClickOff
\header { tagline = ##f }
\new Staff { \clef F c1 c c \bar |.}
\new FiguredBass \figuremode {
\figuredBassCenterOnNote
\set figuredBassPlusDirection = #RIGHT
51 6 4+ 2\+ 6
}
\new Staff { \clef F c1 c c \bar |.}
\new FiguredBass \figuremode {
\set figuredBassPlusDirection = #RIGHT
51 6 4+ 2\+ 6
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: musicxml2ly converts whole rests in 5/4 incorrectly
Am Montag, 14. Februar 2011, um 12:22:11 schrieb Dmytro O. Redchuk: On Tue 04 Jan 2011, 21:55 Neil Thornock wrote: I'm not top posting. When converting a Finale file that includes measures with 5/4 time signature with whole rests, the rest gets converted with a duration of R1.. rather than R1*5/4 or R4*5. Please (in a case if this is actual still), would you provide a small example (xml file) to prove/check? I can't reproduce this with a hand-crafted example of a full-bar rest in 5/4 time signature. Here, these rests are all converted to R4*5 (or R4*10 for a two-bar rest). Can you please provide a sample MusicXML file that produces this behavior? Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: musicxml2ly converts whole rests in 5/4 incorrectly
Am Samstag, 19. Februar 2011, um 13:46:54 schrieb Neil Thornock: Hi all, Sorry for the delay. Attached is a musicxml file and the resulting ly output. This is Finale 2009 and LilyPond 12.3. Notice R1.. -- won't work. Ah, thanks for the info. In LilyPond 2.12.x this didn't work indeed. However, the 2.13.x branch (soon to be the 2.14 release) works just fine. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics on beamed notes not correctly converted by musicxml2ly
Am Samstag, 19. Februar 2011, um 16:49:08 schrieb Hans Aikema: On 19-2-2011 16:24, Hans Aikema wrote: When the MusicXML input contains beamed fast notes (8th, 16th etc) the lyrics accompanying each note after the first of the beamed notes is not imported into the lilypond file. As a follow-up: This might be related to lilypond interpreting manual beams different from autobeams when it comes to placing lyrics. I had to remove the manual beams from the converted file to have the lyric 'three' appear on the second note in the converted file. Yes, the reason is that lilypond treats beams as melismas (which is the usual convention in classical scores; only in modern scores you'll find lyrics on beamed notes!), so there cannot be any lyrics on the subsequent notes. Thus, musicxml2ly ignores those syllables. If you want lyrics on those notes, you have to ignore beamining, which can be done with the --no-beaming command line option to musicxml2ly: musicxml2ly --no-beaming lyrics-melisma.xml Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Unicode PDF titles garbled
- Ursprüngliche Mitteilung - It's actually simpler than using utf-16be. All that is needed is to use escape sequences instead of the accented characters. E.g. I would need to use \362 instead of ò. That's another encoding, PDFDocEncoding (documented in the PDF reference). Thanks, I had alreay found that. Unfortunately, I haven't found a scheme/guile method to create those escape sequences from a utf8 string (I don't even know exactly which escape sequences these are! At least they are none of the usual utf8 representations). I suggest to consequently use UTF-16BE (including surrogate support) which can be easily converted from and to UTF-8. How can I do this in guile? A Google search didn't return any useful results (except a proposal from years ago). In particular, I must only output the strings of the DOCINFO section as UTF-16BE... So, it can't be a port-specific setting, but only effective for one print command. Thanks, Reinhold ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
