Re: Automatic barline misplaced?
Hi Mungo,
At 12:22 on 23 Nov 2022, Mungo Carstairs wrote:
> I noticed that at
> https://en.wikipedia.org/w/index.php?title=Symphony_No._5_(Sibelius),
> the first musical example has the last barline after 9 quavers, when
> it should be after 12 (time signature being 12/8).
> \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.
Well spotted. This simply has the incorrect argument to \partial. There
should be 8 quavers before the *first* barline, not 5, so try this:
\relative c' {
\clef treble
\key ees \major
\time 12/8
\tempo "Tempo molto moderato"
\partial 8*8
bes4~\p\<( bes2.~ |
bes4 ees8 f) bes4-- g-- ees8 f4.\fermata
}
(This is not a lilypond bug, perhaps the user list would be better next time.)
--
Mark Knoop
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.22: unexpected bar numbering when using * lengths and skipBars
Hi Silas,
At 12:36 on 21 Nov 2022, Silas S. Brown wrote:
> % In 2/4 time, I want to write 4 bars rest
> % followed by 2 minims (half-notes).
> % The bar numbering comes out differently:
> \version "2.22.2"
> \relative c' {
> \set Score.skipBars = ##t
> \time 2/4 R2*4 c ^"This is bar 5" \break
> d ^"I think this should be bar 6 but it is bar 9" }
> % The problem goes away if I remember to
> % write "c2" instead of "c" after the "R2*4".
Remember that in LilyPond, durations carry over from the previous event
if not explicitly specified. This includes the duration of multimeasure
rests. You have already found the solution - this is the expected
behaviour.
--
Mark Knoop
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Breath mark style in LilyPond 2.23.80
At 10:10 on 12 Nov 2022, samarutuk via bug-lilypond wrote: > Dear all, when I tried version 2.23.80 for the first time yesterday, I > was absolutely shocked to see the new, very mundane comma as a breath > mark when rendering. I know that other notation programs also use the > comma, but for me the more caesura-like character used before was > always a reason to use Emmentaler/Feta, also and especially in > MuseScore. The normal text style comma, with its delicate tadpole > continuation, goes down much more easily in an opulent score with > lyrics, staccato dots, and other expressive marks. It's a misstep > aesthetically and for readability reasons, in my humble opinion. As a > brass player, breath marks are very important and actually occur in > large numbers, so this comma will really haunt me constantly. However, > since I don't expect you to undo it, then I do ask that you still > preserve the old style so that each Lilypondian can decide for > themselves whether to use the snappy comma or the Emmental original > breath mark (tm). If MuseScore (which I still use) adopts the modified > font, I may add the old breath mark there as well. Sorry for the long > text... and yes, I'm still shocked (and sticking with older versions > for now). Search for \breathe on this page. https://lilypond.org/doc/v2.23/Documentation/changes/index.html Perhaps the user list might be more appropriate for these sort of questions? -- Mark Knoop ___ 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
At 15:15 on 28 Oct 2022, Ole V. Villumsen via bug-lilypond wrote:
> 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.)
> FWIW if I leave out "\partial 8*0" (in direct conflict with NR), the
> typeset music is identical. It still prints the rest wrong. Only I now
> also get the expected warning from Lilypond: "mid-measure time
> signature without \partial".
Hi Ole,
I'm not sure why you think the NR says to use "\partial 8*0", but the
following should work for your CPE Bach example.
{
\time 3/4
\partial 4
c'4 |
c'4 4 4 |
4 4 4 |
\partial 2
4 4
\bar "||"
\time 2/4
R2
}
--
Mark Knoop
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: quoteDuring and repeat tremolo don't work together
At 15:10 on 21 Mar 2020, David Kastrup wrote:
> Mark Knoop writes:
>> At 12:52 on 21 Mar 2020, Rutger Hofman wrote:
>>> Good morning list,
>>>
>>> when I end a \quoteDuring after a \repeat tremolo { ... }, the tremolo
>>> beams are missing or distorted. If the quotation has nontremolo music
>>> afterwards, there is no issue.
>>>
>>> I didn't find a workaround. I tried adding a grace note or a
>>> zero-duration note in the quotation, to no avail.
>>>
>>> I would love to have a workaround as long as this has not been fixed.
>>
>> You need to set quotedEventTypes to include tremolo-event. See:
>>
>> http://lilypond.org/doc/v2.18/Documentation/notation/writing-parts#quoting-other-voices
>
> Huh. Why wouldn't that be the default? This report triggered a Deja vu
> with me; I thought it was fixed previously? Or was this some other kind
> of event recently added?
Apologies David, it is indeed now included in the default. I think I was
remembering the same from a previous problem I encountered. Rutger - I'm not
sure what is going on here.
--
Mark Knoop
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: quoteDuring and repeat tremolo don't work together
At 12:52 on 21 Mar 2020, Rutger Hofman wrote:
> Good morning list,
>
> when I end a \quoteDuring after a \repeat tremolo { ... }, the tremolo
> beams are missing or distorted. If the quotation has nontremolo music
> afterwards, there is no issue.
>
> I didn't find a workaround. I tried adding a grace note or a
> zero-duration note in the quotation, to no avail.
>
> I would love to have a workaround as long as this has not been fixed.
You need to set quotedEventTypes to include tremolo-event. See:
http://lilypond.org/doc/v2.18/Documentation/notation/writing-parts#quoting-other-voices
--
Mark Knoop
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
bendAfter broken by chords
There seems to be a problem with the \bendAfter command which is affected when
used with chords, even in another voice. Not sure what's going on here.
%
\version "2.19.83"
{
\textLengthOn
c''1\bendAfter #-5 ^"this bend OK"
^"no bend attempted"
c''1\bendAfter #-5 ^"this bend OK"
\bendAfter #-5 ^"bend fails"
c''1\bendAfter #-5 ^"bend fails"
}
{
<< {
\voiceOne
c''1\bendAfter #-5 ^"bend fails even if chord is in another voice"
} \context Voice {
\voiceTwo
} >> \oneVoice
}
%
--
Mark Knoop
m...@markknoop.com
https://markknoop.com/
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Rehearsal mark interferes with TupletBracket length
At 10:19 on 20 Feb 2019, Andrew Bernard wrote: > Using 2.19.82 on Debian 9, my string quartet displays an issue that is > hard to understand, and appears to be a defect. Referring to the > attached image, the mark makes the tuplet brackets too short in the > violin and cello part. I can prove this by adding an X-offset to the > RehearsalMark and the issue goes away. I can't test this at the moment, but are you anywhere overriding the `extra-spacing-width` of the RehearsalMark grob? -- Mark Knoop ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: paper variables does not affect a score placed in a markup block
At 01:39 on 16 Dec 2018, Davide Bonetti wrote:
>Minimum example:
>
>\version "2.19.80"
>
>%paper variables does not affect a score placed in a markup block
>
>\paper { system-system-spacing.basic-distance = #18 }
>
> \score {
> \repeat unfold 120 c'4
>}
In markup, use baseline-skip instead, viz:
\markup
\override #'(baseline-skip . 5)
\score {
\repeat unfold 120 c'4
}
--
Mark Knoop
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
clusters interrupted by rests but not multi-measure rests
\makeClusters \music produces expected output when \music contains a
rest, but multi-measure rests and skips do not interrupt the cluster.
Whilst the documentation for Clusters includes under Known issues and
warnings: "Separate clusters need a separating rest between them",
there doesn't seem to be an issue for this in the tracker. Surely this
is not the intended behaviour?
\version "2.19.59"
\makeClusters {
\textLengthOn
<c' g'>2 <c' c''>
r1^\markup "clusters stop for Rests"
<c' g'>2 <c' c''>
<>^\markup "but not MultiMeasureRests" R1
<c' g'>2 <c' c''>
s1^\markup "or Skips"
<c' g'>2 <c' c''>
}
--
Mark Knoop
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Crash: Unterminated tie with articulation in temporary voice
At 01:57 on 09 Sep 2016, Thomas Morley wrote:
>2016-09-09 0:13 GMT+02:00 Simon Albrecht <simon.albre...@mail.de>:
>_Cannot_ confirm crash with a build from most recent master, i.e from:
>commit 5944d20489bb5b8e4c4907fa3b3bcae9ec275ccb
>
>with:
>gcc --version
>gcc (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609
I reduced Urs' example to this:
{ fis'1 ~ -> }
which does result in a Segmentation fault (core dumped) on 2.19.47 but
compiles fine on current git. I presume David's commit 93f3d6 is what
fixed this.
{
% 2.19.47
fis'1 ~ -> % seg fault
%fis'1 ~% compiles
%fis'1 ~ -> fis'1 ~ % compiles
%fis'1 ~ -> fis'1 ~ g' % compiles
%fis'1 -> % compiles
% 2.19.48 current git
%fis'1 ~ -> % compiles
%fis'1 ~% compiles
%fis'1 -> % compiles
%fis'1 ~ -> fis'1 ~ % compiles
%fis'1 ~ -> fis'1 ~ g' % compiles
}
--
Mark Knoop
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: segfault in 2.19.45
At 18:32 on 29 Jul 2016, Kevin Barry wrote: >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. http://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=b0dce76daf27721ba157cd2ac5d7662d4c8d75f8 This is fixed in git, we just need to wait for a new build in Fedora. -- Mark Knoop ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Changed behaviour of point-and-click
Sorry for the delayed reply - I've been travelling. See below. At 18:27 on 17 May 2016, David Kastrup wrote: >Mark Knoop <m...@opus11.net> writes: >> Could you indicate a working setup where relative point-and-click >> links are *not* broken? > >They work like other file-relative links in URIs. To be completely clear, I am of course aware what *should* happen. However, this doesn't happen with my setup (Evince running in Gnome). Clicking the link in Evince is identical to running: xdg-open textedit://file.ly:1:1:1 This has no way of knowing in which directory the PDF is located, and is run by default in $HOME. Please, could somebody describe a setup (specific os, desktop, pdf-reader) where relative links DO work? Urs, do relative links work for you? At 05:47 on 17 May 2016, Urs Liska wrote: >It has been brought up more than once that having full paths in the >point-and-click links *might* be considered a security issue. And much >more important, having relative point-and-click links would make the >files more portable: if you send someone a zip file with .ly and .pdf >files in it relative links would work right out-of-the-box, without >prior compilation. Or if you move/rename a working tree on your >computer the point-and-click-links wouldn't be broken anymore. What is the point of sending a .ly and a .pdf? Surely the point of sending the source is that you don't need to send the pdf. >On the other hand, if a recompilation is required to make >point-and-click links work, what are they useful for, anyway? Links are useful during the edit-compile-edit cycle to jump to specific locations in the source from the compiled pdf. >In short: I suggest not to revert the above patch but make the >behaviour configurable through a command line switch. > >What do you think: >- revert the patch >- keep the patch >- keep the patch, add configuration option and make relative links >default >- keep the patch, add configuration option and make absolute links >default ? The patch should certainly be reverted not least because the description is incorrect. If people have a use for relative links then redo a corrected patch and add a configuration option. Links have always been absolute in the past and so should be the default. -- Mark Knoop ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Changed behaviour of point-and-click
At 10:32 on 17 May 2016, Urs Liska wrote: >Am 17.05.2016 um 14:30 schrieb Mark Knoop: >> At 05:47 on 17 May 2016, Urs Liska wrote: >>> Mark, can you give us a reason why you consider relative >>> point-and-click links "broken"? >> I am unaware of any way for the pdf viewer, or the whatever handles >> the textedit url, to know what the link is relative to. Correct me >> if I am wrong on this. > >I think the links should be relative to the location of the PDF. But as >David pointed out it's less trivial than one might think to determine >what that properly is always. Indeed, it's not trivial for lilypond to know that, but that is not my point. Even if the links *are* valid, relative to the location of the pdf, do you then expect the pdf viewer to convert them to absolute links? Evince certainly doesn't do that. Maybe other pdf viewers do. Or instead, if the relative link is passed to the url-handler (usually via a desktop environment such as Gnome, Windows, etc), how does that handler know what the link is relative to? i.e.: what file should lilypond-invoke-editor textedit://file.ly:1:2:3 open? Could you indicate a working setup where relative point-and-click links are *not* broken? -- Mark Knoop ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Changed behaviour of point-and-click
At 05:47 on 17 May 2016, Urs Liska wrote: >Mark, can you give us a reason why you consider relative >point-and-click links "broken"? I am unaware of any way for the pdf viewer, or the whatever handles the textedit url, to know what the link is relative to. Correct me if I am wrong on this. -- Mark Knoop ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: regression: point-and-click no longer includes absolute path
>> The point-and-click link in the resulting pdf is relative: >> textedit://testpaths.ly:9:2:3 - and therefore doesn't work. > >Hm, the PDF you attached *does* give an absolute link, but: Yes, sorry, testing with different versions and attached the wrong one. See attached pdf now. >Indeed, this is right, so obviously my patch *did* change the behaviour >of point-and-click. (I have to repeat that nobody noticed that during >review). It could be that most point-and-click users are also users of Frescobaldi or other front-ends that pass the full pathname to lilypond. -- Mark Knoop testpaths.pdf Description: Adobe PDF document ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: regression: point-and-click no longer includes absolute path
Thanks Urs,
At 09:37 on 13 May 2016, Urs Liska wrote:
>Which version of LilyPond and what Linux exactly do you use (2.19.40
>binary release?)?
lilypond 2.19.40, on Fedora 23, distro build (lilypond-2.19.40-1.fc23)
However I have just downloaded 2.19.41 binary release from lilypond.org
and see the same behavior (I added { c } to the code below to
generate a pdf):
GNU LilyPond 2.19.41
Processing `testpaths.ly'
Parsing...testpaths.ly
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-DUHuav'...
Converting to `testpaths.pdf'...
Deleting `/tmp/lilypond-DUHuav'...
Success: compilation successfully completed
The point-and-click link in the resulting pdf is relative:
textedit://testpaths.ly:9:2:3 - and therefore doesn't work.
>Compiling your example with LilyPond built from current master gives
>me:
>
>Starting lilypond 2.19.42 [Untitled]...
>Processing `/tmp/frescobaldi-dW8ldh/tmpTuF3xf/document.ly'
>Parsing...
>/tmp/frescobaldi-dW8ldh/tmpTuF3xf/document.ly
>Success: compilation successfully completed
Hmm, that's interesting. Is this perhaps because you are running via
frescobaldi which passes the full pathname of the file to lilypond? Can
you try running directly with a relative path.
ly:input-file-line-char-column seems to return the path which is given
on the commandline, whether it is relative or absolute.
>(and that what was the case when I made that change (and obviously
>noone had objections then)).
>
>So please show me what you get in return from that function on your
>system. Or an example where point-and-click links are actually
>generated relatively and break anything.
>
>Urs
>
>Am 13.05.2016 um 09:16 schrieb Mark Knoop:
>> The commit below has broken point-and-click links for me on Linux.
>> Embedded paths are now relative rather than absolute. It seems the
>> assumption in the commit message that an absolute path is always
>> returned is incorrect, as can be seen with the following example.
>>
>> Reverting scm/output-ps.scm fixes the problem.
>>
>> \version "2.19.40"
>> testpaths =
>> #(define-void-function
>>(parser location)
>>()
>>(display (car (ly:input-file-line-char-column location
>> \testpaths
>>
>>
>> commit f30a8189adbbeefa2103e2c2e194040f66bc2291
>> Refs: release/2.19.27-1-280-gf30a818
>> Author: Urs Liska <u...@openlilylib.org>
>> AuthorDate: Tue Jan 19 10:52:33 2016 +0100
>> Commit: Urs Liska <u...@openlilylib.org>
>> CommitDate: Sun Jan 24 21:24:52 2016 +0100
>>
>> #4747: Remove (all) uses of is-absolute?
>>
>> The check for absolute paths in in output-ps.scm
>> and -svg.scm is unnecessary because
>> (car ly:input-file-line-char-column a-location)
>> always returns an absolute, slashified path
>>
>> Now is-absolute? is not used anymore by LilyPond itself.
>>
--
Mark Knoop
\version "2.19.40"
testpaths =
#(define-void-function
(parser location)
()
(display (car (ly:input-file-line-char-column location
\testpaths
{ c }
testpaths.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
regression: point-and-click no longer includes absolute path
The commit below has broken point-and-click links for me on Linux. Embedded paths are now relative rather than absolute. It seems the assumption in the commit message that an absolute path is always returned is incorrect, as can be seen with the following example. Reverting scm/output-ps.scm fixes the problem. \version "2.19.40" testpaths = #(define-void-function (parser location) () (display (car (ly:input-file-line-char-column location \testpaths commit f30a8189adbbeefa2103e2c2e194040f66bc2291 Refs: release/2.19.27-1-280-gf30a818 Author: Urs Liska <u...@openlilylib.org> AuthorDate: Tue Jan 19 10:52:33 2016 +0100 Commit: Urs Liska <u...@openlilylib.org> CommitDate: Sun Jan 24 21:24:52 2016 +0100 #4747: Remove (all) uses of is-absolute? The check for absolute paths in in output-ps.scm and -svg.scm is unnecessary because (car ly:input-file-line-char-column a-location) always returns an absolute, slashified path Now is-absolute? is not used anymore by LilyPond itself. -- Mark Knoop ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Effect of empty chord on spacing
Not sure if this qualifies as a bug, but it's a little unexpected and
annoying. Using an empty chord to attach markup with full-bar rests
seems to change the spacing of the bars, the bar with the is
significantly shorter. Using a zero-duration skip (s1*0) has the same
effect.
This only seems to happen under certain circumstances: when the line is
full, and the rests are ultimately followed by some music.
\version 2.19.18 % same result with 2.18.2
{
R1
^\markup \column { attached to }
R1
R1
R1^\markup \column { attached to R1 }
c'1
\repeat unfold 16 c'16
}
--
Mark Knoop
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Disappearing barlines with skipBars - possible bug?
At 00:03 on 25 Mar 2015, Thomas Morley wrote: I disagree. \set Score.skipBars = ##t _is_ intended to affect notes _and_ useful! Don't limit your thoughts to modern music. Below I retyped (quick'n dirty) the last bar from Missa Papae Marcelli, Sanctus by Palestrina taken from an edition which tries transforming the original in sort of modern notation. That is an interesting case. It would seem to me that ideally there should be two properties (perhaps three?) to control this behaviour for notes, rests and multimeasure rests respectively. -- Mark Knoop ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Disappearing barlines with skipBars - possible bug?
At 12:31 on 24 Mar 2015, Kevin Barry wrote:
On Tue, Mar 24, 2015 at 9:01 AM, Mark Knoop m...@opus11.net wrote:
At 18:16 on 23 Mar 2015, Mark Knoop wrote:
Barlines disappear when skipBars is true and a note duration
continues over the bar. I don't think this should happen.
\version 2.18.2
{
\time 2/4
r4 c'2 r4
r4 \tuplet 3/2 { c'2 d'4 } r4
\set Score.skipBars = ##t
r4 c'2 r4
r4 \tuplet 3/2 { c'2 d'4 } r4
}
Tuplets across barlines are a relatively common notational practice
and work perfectly well in LilyPond. It is undesirable that they
should require a workaround for use in parts with skipBars.
If I understand you correctly it seems that skipBars simply shouldn't
apply to notes then? To clarify what I meant: I can't think of any
score where notes that cross barlines would leave any bars empty,
{ \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
which begs the question of what exactly skipBars is supposed to do
with notes that cross barlines? My understanding was that it merges
the bars in question.
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.
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. If there is a case for keeping the
behaviour, I would suggest a separate property for notes that cross
barlines.
I would be interested in others' opinions on this.
I still think you should send this to the bug list, where it is more
likely to get discussed (some of the developers there are not
subscribed to the user list).
--
Mark Knoop
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Disappearing barlines with skipBars - possible bug?
At 15:43 on 24 Mar 2015, Kevin Barry wrote:
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?).
I agree these are contrived examples and am not claiming them to be
standard notation. However tuplets spanning barlines are common in
contemporary music and that is the context where this bug appears.
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.
Um, no: When printing the part, multi-rests must be condensed. This is
done by setting a run-time variable \set Score.skipBars = ##t
It is in Notation Reference 5.3.2 that it's used as an example of a
context property, although still with reference to its use for
combining multimeasure rests.
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).
Yes, it's just a shortcut:
ly/property-init.ly:156:compressFullBarRests = \set Score.skipBars = ##t
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.
cced to bug-lilypond
--
Mark Knoop
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
tupletFullLength, tupletFullLengthNote problems
I'm not top posting.
1) When tupletFullLength is set, combining tuplets with a clef change in another
staff results in the tuplet bracket ending early.
2) When tupletFullLengthNote is set and a tuplet ends a line, the tuplet
number is printed again at the beginning of the next line and the
bracket is not terminated.
\version 2.11.44
\paper {
ragged-right = ##t
}
% music
uppermusic = {
\times 2/3 { g'2 g' g' }
g'1
\set tupletFullLength = ##t
\times 2/3 { g'2 ^1 g' g' }
g'1
\set tupletFullLengthNote = ##t
\times 2/3 { g'2 ^2 g' g' } \break
g'1
}
lowermusic = {
\clef bass r1
\clef treble r1
\clef bass r1
\clef treble r1
\clef bass r1 r1
}
% score
\score {
{
\new PianoStaff = piano
\new Staff = upper { \uppermusic }
\new Staff = lower { \lowermusic }
}
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
