Re: Automatic barline misplaced?
On Wed, Nov 23, 2022 at 12:22:14PM +, Mungo Carstairs wrote:
> \relative c' { \clef treble \key ees \major \time 12/8
> \tempo "Tempo molto moderato" \partial 8*5 bes4~\p\<( bes2.~ | bes4 ees8 f)
> bes4-- g-- ees8 f4.\fermata }
>
> I thought I might have a go at correcting it myself, despite knowing
> nothing (until today) about Lilypond. However I can see nothing in the
> markup that places the barline explicitly, so (with all due diffidence)
> wonder whether it is a bug. I did search GitLab for open issues without
> finding anything that seemed to match.
I don't think it's a bug. Looking at the code you quoted it seems the
anacrusis is 5 quavers, when it should be 8 (the same length as a
semibreve).
If you change `\partial 8*5` to `\partial 1` that should fix it.
(Barlines are usually placed automatically by LilyPond, and by setting
the anacrusis to 5 quavers LilyPond is putting the first barline in the
middle of the dotted minim - which is why you see the odd spacing where
the first crotchet afterwards is too far to the right.)
Kevin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Articulations in same spot where slur ends
On Sat, Oct 29, 2022 at 06:29:05AM +, Ole V. Villumsen via bug-lilypond wrote: > Thanks, Pierre! That looks good and isn’t so hacky as my own workaround. > I will do some further experimentation to see if it fulfils my need > and wishes. I still think there’s a bug, though. Best regards, Ole Yes, this is a known bug. It's currently being tracked here: https://gitlab.com/lilypond/lilypond/-/issues/6120 Kevin ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Full bar rest printed incorrectly after time signature change
On Fri, Oct 28, 2022 at 03:15:48PM +, Ole V. Villumsen wrote:
> > If you use \partial at the beginning of a score it treats the resulting
> > duration as the length of music preceding the first bar. This is how bar
> > numbering generally works for upbeats/anacrusis.
>
> Obviously confirmed.
I mean that it is documented behaviour. The NR says "When \partial is
used at the beginning of a score, duration is the length of the music
preceding the first bar."
> I admit that I wondered more than a bit about the requirement in the
> Notation Reference to insert a \partial "when the time signature
> changes in mid measure". Composers do not always want an
> upbeat/fractional pick-up there. Maybe supplying a zero duration is a
> hack; but what is the alternative? At least NR doesn’t give one.
It used to be the case that you had to use a different (more
complicated) syntax to do that, but since the functionality was quite
similar to partial, partial was updated to work when used at times other
than the beginning of a piece.
> > All of the examples of \partial in the documentation use it at the
> > beginning of a bar and supply the duration. If you do the same it should
> > work for you.
>
> I didn’t see any examples of a zero partial in the docs either. I have
> trouble making good sense of your last statement, though, sorry. What
> are you suggesting to do when the composer did not intend nor supply
> an upbeat? (My example is from C.Ph.E. Bach (1714 - 88): Fantasia C
> major H.291, bars 71 - 72.)
Partial only inserts an upbeat when used at the beginning of a score. To
quote the NR: "When \partial is used after the beginning of a score,
duration is the remaining length of the current measure. It does not
create a new numbered bar."
You should imitate the examples in the NR: put \partial 2 at the
beginning of the shortened measure. Something like this (based on the
image you attached):
\relative {
\time 3/4
g'8( fis e' d c b)
\partial 2
a4( gis)
\bar "||"
\tempo "Presto di molto"
\time 2/4
R2
}
Kevin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Full bar rest printed incorrectly after time signature change
On Fri, Oct 28, 2022 at 01:04:38PM +, Ole V. Villumsen via bug-lilypond wrote: > The incomplete 3/4 measure still has not got bar number 1. For most > purposes we can probably live with that. Setting the current bar > number explicitly to 1 did not help (apparently upbeats don’t have bar > numbers). But setting it to 2 for the following bar fixes it for the > remainder of the score. If you use \partial at the beginning of a score it treats the resulting duration as the length of music preceding the first bar. This is how bar numbering generally works for upbeats/anacrusis. > I consider it a workaround not to say a hack. I still firmly believe > that the bug I was reporting is real. Partial expects to be given a duration. I think it will not work as you expect if you multiply the duration by 0 (which is probably a kind of intpu that was not anticipated). At the point when you used it it's already effectively "between" bars and if you supply a duration it will apply to the *next* bar, not the *previous* bar. All of the examples of \partial in the documentation use it at the beginning of a bar and supply the duration. If you do the same it should work for you. Kevin ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Glitch in the documentation?
I also see what I assume to be Catalan. The default language of my browser is Irish. On Sat, 8 Oct 2022 at 11:32, Andrew Bernard via bug-lilypond wrote: > > Also Catalan for me. > > Andrew > > > > > ___ > bug-lilypond mailing list > bug-lilypond@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 64 bit MacOS version + Apple Silicon version
Hi Bart, I believe that we are unfortunately unable to produce 64bit binaries for Apple without violating their licensing terms (someone else will know more, but I believe it's related to Xcode). For now, those who want a 64bit binary rely on macports to provide it. Is what's in macports out of date? Kevin On Thu, 22 Apr 2021 at 12:21, Bart Kummel wrote: > > Hi, > > Apple switched off support for old 32 bit applications years ago. I'm > surprised that there still isn't a 64bit Mac version of Lilypond. In the > meantime, Apple has released their own silicon (the M1 processor), so I > guess you should also be working on a version that runs on that hardware. > > I know there are work arounds, like unofficial builds (but those are > outdated) and running Lilypond via Docker (but that's cumbersome). Those > can only be used as temporary work arounds. > > Best regards, > Bart Kummel > ___ > bug-lilypond mailing list > bug-lilypond@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Info file generation or installation is broken
On Wed, Mar 31, 2021 at 01:42:17AM +0200, David Kastrup wrote: > David Kastrup writes: > > > Apparently, images are no longer copied when doing > > > > make install-info I always work in a terminal so I wouldn't notice the missing images, but anyway I always assumed our info install was broken. I never knew about the install-info make target. Right now, if I run `make install', when it completes it will print a message with the install-info command I need to run. Something like this: install-info --info-dir=~/.local/share/info ~/.local/share/info/lilypond-web.info Running that always fails because the lilypond-web.info file doesn't exist. So I wrote some hack of a script that generates a dir file and just uses that directory. It would be nice not to have to do that. Kevin > > > > making the documentation near useless. Pages look like > > > > File: lilypond-notation.info, Node: Pitches, Next: Rhythms, Up: Musical > > notation > > > > 1.1 Pitches > > === > > > > [image src="lilypond/67/lily-393eafe4.png" alt="[image of music]"] > > > >This section discusses how to specify the pitch of notes. There are > > three steps to this process: input, modification, and output. > > > > * Menu: > > > > * Writing pitches:: > > * Changing multiple pitches:: > > * Displaying pitches:: > > * Note heads:: > > > > now. > > Copy in Emacs can be surprising when images are involved. The > displayed text is actually [broken image:lilypond/67/lily-393eafe4.png] > > > I find that make install-info creates a link > > > > lrwxrwxrwx 1 root root 35 Mär 31 01:28 lilypond -> > > ../doc/lilypond/html/Documentation/ > > > > in /usr/local/share/info > > > > that is entirely useless since I am not interested in installing the > > HTML documentation. > > -- > David Kastrup > > ___ > bug-lilypond mailing list > bug-lilypond@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: script stack order regression
On Sat, Mar 13, 2021 at 05:19:49PM +0100, Robin Bannister wrote: > Hallo there > > I noticed this while trying to make an MWE for a different problem. > > Maybe it counts as a limitation rather than a bug? Hi Robin, Thank you for the report. I don't think LilyPond guarantees a particular order of events occuring at the same moment, but I agree that wrapping them should not change the order. An issue has been created to track this here: https://gitlab.com/lilypond/lilypond/-/issues/6106 A patch to fix it has also been submitted. Kevin ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \center-column broken
On Tue, 16 Feb 2021 at 08:44, Werner LEMBERG wrote: > > > > How about hosting the fonts on www.lilypond.org and referencing them > > in the @font-face definition? > > I think this is not a good idea. I agree that hosting fonts would be a headache: everyone's svg documents would suddenly depend on lilypond.org. I am sympathetic to the idea that we should embed the fonts in the SVG, or perhaps provide a command-line option to tell LilyPond to do so. Inkscape works very well to convert PDFs to SVG, but if we expect our users to do that, then it's debatable whether we should have an SVG backend at all. (I mean this seriously: the SVG backend has its own bugs that are hard to fix; we have no way, currently, to regtest it; and we could get LilyPond to call inkscape itself where it is available and SVG is the specified backend; just a thought...) Kevin ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Wrongly read property with MetronomeMark
I did a git bisect on this (and confirmed the result by checking that reverting the change removes the problem): 905ba822ef656b06b1cc4f0ca33960c9c is the first bad commit commit 2c2908c905ba822ef656b06b1cc4f0ca33960c9c Author: Malte Meyn Date: Sun Sep 29 10:10:35 2019 +0200 Issue 5563: make edges of brackets dashable The new boolean grob property dashed-edge controls whether the edges of a dashed bracket are solid or dashed. Kevin ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Disappearing dynamics
> Didn't seem to help unfortunately. So far it really seems that LilyPond > behaves inconsistently in this case when run as a subprocess of Frescobaldi. How bizarre. I wonder what difference there could possibly be that would make files appear to have different content. Does this issue occur in Frescobaldi if opening after a successful (i.e. dynamics appear correctly) compile from the cli and without making any edits? Does running sync before compilation make any difference? Do dynamics ever disappear after they have successfully appeared once? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: segfault in 2.19.45
> Hi, Fedora lilypond maintainer. We've actually got our 2.19.45 patched, but > the update was superceded by 2.19.46. If you do sudo dnf update lilypond* > --enablerepo=updates-testing you should get it. Many thanks; this fixed it! ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: segfault in 2.19.45
Thank you for taking the time to test it. I'm using the package in Fedora's repo, so I suppose I should take it up with them? I'm not sure how to troubleshoot further. Reinstalling didn't help. Kevin ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
segfault in 2.19.45
Apologies if this is fixed in 2.19.46
It worked in previous versions of 2.19 (I'm not sure when it broke
cause it's not from something i worked on too recently). I am on Linux
64-bit (Fedora). A MWE follows (compiling with no options should
segfault). There must be some kind of problem caused by the slur and
tie ending in the same place.
\version "2.19.45"
{ a( b~ b) }
Starting lilypond 2.19.45 [test.ly]...
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Exited with exit status 1.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: autoBeaming and \set measurePosition
Tinkering with your example seems to suggest that any value that is larger than the time signature will produce the unwanted behaviour. That is, if you set the Timing.measurePosition to anything bigger than the normal size of a bar in the current time signature, the beam before the override is broken. It's odd for sure, but perhaps understandable: you're effectively telling LilyPond that a 2/4 bar has 3 beats left, or that a 3/4 bar has 4 beats left. I'm not sure if I would consider it a bug or not, but it's definitely undesirable. Kevin On Thu, Aug 20, 2015 at 8:41 AM, Phil Holmes m...@philholmes.net wrote: Simon Albrecht simon.albre...@mail.de wrote in message news:55d51b39.2010...@mail.de... I don’t quite know what I’m supposed to think of this: With 3/4, there is no beam between the third and fourth quavers. It doesn’t happen with -1/4, 0, 1/4, or 2/4. Doesn’t seem like this is going to appear in any realistic scenario. Just ignore it? Yours, Simon Simon, What are you trying to do with this example? Also, for trivially small examples (like this is) I think most people find it far easier to comment if you post the code in line, rather than as an attachment. I certainly do. -- Phil Holmes ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Disappearing barlines with skipBars - possible bug?
On Tue, Mar 24, 2015 at 2:38 PM, Mark Knoop m...@opus11.net wrote:
{ \time 2/4 c'4 c'1 c'4 } % 3 bars, 2nd of which is empty
{ \time 2/4 c'4 c'2 c'4 } % 2 bars, neither of which is empty
At best I would consider these to be non-standard notation. At worst I'd
say it's incorrect. It's possible to write a note value longer than a bar,
but I don't think there is an accepted standard for notating that, except
for connecting smaller note values with ties. And as I said before I have
never seen it in a score (do you have any examples?).
skipBars is introduced in the Learning Manual (3.4.5 Scores and parts)
as a way of condensing multi-measure rests. Its only references in the
Manuals are regarding this function. I suspect its impact on notes
crossing barlines is either unintended or at least not thought through
It's just used there as an example of a context property. I agree that its
behaviour for notes rather than rests might not be thought through (but it
/is/ mentioned in the IR so it may not be unintended). Normally full-bar
rests are condensed with \compressFullBarRests (which probably just sets
skipBars to #t, but I didn't check).
I can't imagine a situation where the current behaviour would be
desirable (silently hiding a barline thus changing the length of a bar)
and it would certainly seem to be a very different use case than
condensing multi-measure rests.
I think the default behaviour (without touching skipBars) is ok, and agree
that there's no apparent need for it to affect notes (the possible scenario
with long notes and short empty bars seems implausible). So perhaps
skipBars could be changed to only affect rests, or at the very least a
different context property could be used as an example in the learning
manual (or both).
I verified that \compressFullBarRests does indeed affect notes as well, so
if you want to file a bug report then perhaps proceed on that basis.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
