Re: Imprecise font scaling
On Thu, 15 Feb 2024 at 12:35, Jean Abou Samra wrote: > > IMHO, this also falls in the "not worth documenting" category. But yes, > lily/include/dimensions.hh contains > > const Real INCH_TO_PT = 72.270; Hello, Actually "NR 4.2.2 Setting the staff size" kind of document it: The default staff size is 20 points, which corresponds to a staff height of 7.03mm (one point is equal to 100/7227 of an inch, or 2540/7227 mm). Kind regards, Xavier
Re: Melody bars are out of sync after tie into first alternative and added lyrics
On Fri, 26 Jan 2024 at 11:50, Arne Ploese via bug-lilypond < bug-lilypond@gnu.org> wrote: > > Hi, > > after the tie into the first alternative the bar of second alternative > seems to be out of sync. > In the example it seems that the alternative 2 has only space for 3 > quarter notes, if the alternative 2 does not start with "r4". > This happens only, if I add the lyrics. Hello, Please read NR 2.1.2 Techniques specific to lyrics > Lyrics and repeats > Repeats with alternative endings When a note is tied over into two or more alternative endings [...] to align the lyrics correctly it is necessary to disable the automatic creation of melismata over the volta section and insert manual skips There is also an example which deals with almost exactly the same as your code. Kind regards, Xavier
Re: Double bar not at end of staff with scaled joined staves in 2.24.1 and higher
On Sun, 23 Jul 2023 at 19:28, Heiko Schill wrote: > > Hi all, > > when compiling the attached snippet, the double bar in the first (scaled) > staff of two joined staffs is not at the end of the line but shifted a > little to the left. The smaller the scale factor is, the further to the > left the double bar ends up. This happens with lilypond 2.24.1 and higher > (also tested with 2.25.5), but the snippet compiles correctly with 2.22.1... Hello, Please read the section "Known issues and warnings" of NR 4.2.2 Setting the staff size https://lilypond.org/doc/v2.24/Documentation/notation/setting-the-staff-size Use #(define bar-line-props '((BarLine thick-thickness) (BarLine hair-thickness) (BarLine kern))) and #(revert-props 'magnifyStaff 0 bar-line-props) This is the main reason why I do not use \magnifyStaff but still rely on fontSize and \override StaffSymbol.staff-space = #(magstep #-x) Cheers, Xavier -- Xavier Scheuer
Re: Stem neutral-direction bug
On Fri, 10 Jun 2022 at 02:54, Ahanu Banerjee wrote:
>
> % unexpected warning with rests inside tuplet:
> % "direction of grob Stem must be UP or DOWN; using UP"
>
> \version "2.23.9"
> \layout {
> \context {
> \Voice
> \consists "Melody_engraver"
> \override Stem #'neutral-direction = #'()
> }
> }
>
> { \tuplet 3/2 { r4 r r } }
Hello,
It looks like #6093 but it has been fixed and closed (and I don't
understand the ins and outs of the discussion between developers).
https://gitlab.com/lilypond/lilypond/-/issues/6093
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Slur to wrong note when slur is inside a chord with a staccato mark
On Mon, 28 Mar 2022 at 20:21, Knute Snortum wrote:
>
> When you try to slur to a note inside a chord and that chord has a
> staccato mark, the slur ends on the top note, not the target note.
>
> %%%
> \version "2.23.7"
>
> \relative {
> a'16( b c -.
> }
> %%%
Hello,
As a complimentary information:
With \override Script.avoid-slur = #'outside or \override Script.avoid-slur
= #'around the slur is correct.
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: ChordNames bug with bass octaves
On Mon, 29 Nov 2021 at 21:25, brarsh--- via bug-lilypond <
bug-lilypond@gnu.org> wrote:
>
> ChordNames should (probably) drop/consume/merge extra octave bass notes
before computing the structure of a chord. Unless I'm misunderstanding the
source of the error.
>
> The first name is correct. The extra bass note, even though it doesn't
change the chord, confuses the chord computer. The 8 and 15 are both
octaves and so shouldn't be included in the chord name.
>
> \version "2.22.1"
> \new ChordNames {
> 1
> 1
> }
> \new Staff \relative c'{
> 1
> 1
> }
>
Hello,
You do not have the same notes in your ChordNames and in your Staff.
Add relative to your ChordNames and you get the same notes and probably the
results you expect.
\new ChordNames \relative c' {
1
1
}
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Multi-measure rests not compressed when \partial is used in middle of score
On Sun, 11 Oct 2020 at 02:34, Nate Whetsell
wrote:
>
> Hi there,
>
> First, thank you for all your work on LilyPond.
>
> Within \compressMMRests, if a multi-measure rest is preceded by a
\partial that’s not at the beginning of the score, it appears that the
multi-measure rest isn’t compressed. Here’s a LilyPond example that
illustrates the issue:
>
> ```
> \version "2.20.0"
> \compressMMRests {
> c'1
> \partial 4 c'4
> R1*42 % These rests are not compressed.
> }
> ```
Hello,
Note that \set Score.skipBars = ##t is working.
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Fw: wrong text font
On Sun, 20 Sep 2020 at 19:51, Stefano Carbonelli via bug-lilypond < bug-lilypond@gnu.org> wrote: > > @Jonas > > Yes I installed the package with apt-get install lilypond > > It still doesn't work with the generic package: > > I assumed to go into the folder and run: > ./lilypond test.ly > the attached output pdf shows the same problem in its bottom text. > > Thanks Hi, Check fontconfig DPI setting. The desktop environment LXQT sets this to 96 dpi and it should be 1200 for Lilypond. https://gitlab.com/lilypond/lilypond/-/issues/5136 Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Using TeX Gyre Schola vs. C059
On Sun, 7 Jun 2020 at 08:47, Werner LEMBERG wrote: > > Sounds like a sensible idea. It seems that the TeX Gyre font are no > longer under development or maintenance; the last release is from > 2009. The recent URW fonts are from 2016. > > On the other hand, a switch to a new default is not urgent, since you > can always select the URW fonts explicitly for typesetting text. > > So if you want to work on it, patches are highly welcomed :-) Oooh, that' s interesting! I recently came across the "ScholaX" LaTeX package which is also an extension of TeX Gyre Schola. https://ctan.org/pkg/scholax The README file mentions: Changes in version 1.026 1. Added a number of new glyphs to extend the coverage of the TS1 encoding. 2. Modified the sizes and positions of the tiddles on glyphs related to i and j to better match their appearance to those in the original URW++ clone of Century Schoolbook. I don't know if this project is related to C059, I haven't seen the mention anyway. The license is also LPPL. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bar number with chord name
On Sat, 18 Apr 2020 at 19:49, Aidan O Connor wrote:
>
> When chord names are included, the bar numbers are positioned above the
chord name. This is particularly noticeable if a fret diagram is also
included. The bar numbers should be positioned immediately above the staff.
> In this example, the chord name forces the second measure bar number out
of position compared to other bars.
>
> \version "2.20.0"
> <<
> \chords { c1 c1 }
> \new Staff {
> \override Score.BarNumber.break-visibility = ##(#t #t #t)
> r1 r1 ^ \markup { \fret-diagram "" }
> }
> >>
>
Hello,
If you want the bar numbers above the staff, then move the
"Bar_number_engraver" to the staff level.
\layout {
\context {
\Score
\remove "Bar_number_engraver"
}
\context {
\Staff
\consists "Bar_number_engraver"
}
}
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Grace prevents \voiceOne when set at the same time
> I'm not top posting.
Hi,
I do not know if this was already reported (I did not find it in the
tracker).
\grace (and similar \acciaccatura etc.) prevents \voiceOne (and similar
\stemUp etc.) when they are both set at the same time.
I doubt such an issue would remain unreported for such a long time, so
probably either it is already in the tracker, either this issue is
a regression compared to an older version of LilyPond.
\version "2.18.0"
% Issue: grace prevents \voiceOne
\relative c'' {
c1 \voiceOne \grace c8 c2 c2 % \voiceOne not activated
}
% Works: \voiceOne inserted before or after grace
\relative c'' {
\voiceOne c1 \grace c8 c2 c2 % works (\voiceOne activated)
}
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
DynamicText alignment broken for make-dynamic-extra
Hello Janek, I am using Graham's make-dynamic-extra function to align properly "composite" dynamic and text indications like "mp dolce" or "più f" (for the latter the function is make-extra-dynamic, a bit different). http://lists.gnu.org/archive/html/lilypond-user/2011-06/msg00335.html For years it worked as I wanted, i.e. align the "composite" indication with the "dynamic" part centered on the note head (like a normal DynamicText). However in latest LilyPond version (stable 2.18.2 and development 2.19.15) it does not work as it did before. After some research on LilyPond mailing lists I read the thread "self-alignment-X has negligible effects on dynamics" http://lists.gnu.org/archive/html/lilypond-user/2014-07/msg00691.html and issue 4036 and 3978 https://code.google.com/p/lilypond/issues/detail?id=4036 https://code.google.com/p/lilypond/issues/detail?id=3978 Is there something to modify in the make-dynamic-extra function in order to make it centered on the dynamic again? So that the "mp dolce" and "più f" indications in my scores are correctly aligned again with latest lily version. Thank you for your attention and your work on LilyPond. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: problème à l'ouverture de l'application
2013/6/30 a.davaine > > Bonjour, > > J'ai voulu installer Lilypond mais il ne s'est pas ouvert et le > message suivant est apparu: > > > Que dois-je faire ? > Merci pour votre réponse. Bonjour Alexia, Cette liste de diffusion a pour but de signaler les bugs de LilyPond. La communauté d'utilisateurs étant internationale, les messages de cette liste sont en anglais. Pour des questions, remarques en français il est préférable d'utiliser la liste francophone : lilypond-user...@gnu.org . Infos : https://lists.gnu.org/mailman/listinfo/lilypond-user-fr Archives : http://lilypond-french-users.1298960.n2.nabble.com/ La reproduction du message d'erreur n'est pas passée dans ton message. Pourrais-tu le recopier ? Par ailleurs, je ne sais pas si tu es au courant, le logiciel LilyPond est un peu différent d'autres logiciels de création de partitions dans le sens où il ne dispose pas d'interface graphique. Il est donc nécessaire de prendre un peu de temps pour apprendre à l'utiliser, via la syntaxe LilyPond. http://lilypond.org/text-input.fr.html Tout ceci est expliqué dans le manuel d'initiation : http://lilypond.org/learning.fr.html Si tu as d'autres questions, n'hésite pas à les poser sur la liste francophone, où la communauté active fera de son mieux pour y répondre. Cordialement, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: vowel aligned lyrics - want to improve it
On 22 February 2010 09:01, Wolf Alight wrote: > > What a way to start the monday morning! > Thank you Neil! > > I will put this in the Snippet Repository. I just thought of one > enhancement I want to make and one "feature" that came up: > > (snip) > Hi, Someone on the French users mailing list would like to align lyrics on the first vowel. http://lilypond-french-users.1298960.n2.nabble.com/Alignement-des-paroles-sur-la-premiere-voyelle-td7579353.html I found this thread but searching the LSR with the keyword "vowel" gives no result (and, of course, nothing about this in the doc). 1. Could someone confirm me this is the latest version of the code for "vowel aligned lyrics" feature? 2. If it's effectively not on the LSR, could it be added? 3. It would be great to have "vowel aligned lyrics" directly in LilyPond; could this be added to the tracker as feature request? Thanks! Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Positioning of "8" under clef symbol in G_8 clef
On 3 April 2013 19:08, Janek Warchoł wrote: > > Interestingly, this was discussed before; i've discovered some old > drafts of mine concerning it. Also, i see that my work on rewriting > alignment interface would fit nicely with this stuff; i see now how > this should be achieved. I can make a patch, but i'm busy; some > bounty would increase my motivation ;) If at least 2 people will > pledge $5 each, i'll write a patch in the next few days - who's > interested? Hi Janek, I am not interested in this feature as I have never used a G_8 clef in the scores I engraved, but I would gladly pledge 2 times $5 to increase your motivation. ;) Please send me (privately) your bank account or any other information needed for the money transfer as your convenience. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: span-bars missing since 2.17.13
On 5 March 2013 13:36, Eluze wrote: > the example in Snippets: > http://lilypond.org/doc/v2.17/Documentation/snippets-big-page.html#rhythms-removing-connecting-bar-lines-on-staffgroup-pianostaff-or-grandstaff > has no more spanned bars! > > I didn't find a corresponding issue - shall this be added? https://code.google.com/p/lilypond/issues/detail?id=3203 Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: hshift a rest in a triplet not possible?
On 3 March 2013 23:42, Eluze wrote:
> Pierre Perol-Schneider reports this problem on the French LilyPond forum:
>
> shifting the rest in a triplet doesn't work
>
> (snip)
>
> if instead of a8\rest in the Medium voice you have a real note, shifting is
> perfect.
>
> reading in Internals I found:
>
> 2.2.97 Rhythmic column engraver
> Generate NoteColumn, an object that groups stems, note heads, and rests.
>
> is this a bug with the documentation or rests or triplets?
Actually it is not specific to tuplets.
Begin lily code
\version "2.17.12"
% NoteColumn 'force-hshift does not work for rests
\new Staff {
<<
\new Voice {
\voiceOne
\relative c' {
f4
\once \override NoteColumn #'force-hshift = #1
f4
r4
% rests are not force-shifted
\once \override NoteColumn #'force-hshift = #1
r4 |
}
}
\new Voice {
\voiceTwo
\relative c' {
\repeat unfold 4 c4 |
}
}
>>
}
End of lily code
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: partcombineChords affects preceding note, gives wrong output
On 3 March 2013 18:16, Colin Hall wrote: > > Thanks for the report, Pavel. > > I checked for existing issues against partCombine. There are some, but > your report seems to be distinct, so I created a new tracker. > > https://code.google.com/p/lilypond/issues/detail?id=3220 Hi, For a reason I do not know it seems that partcombine issues were given the label "partcombine". http://code.google.com/p/lilypond/issues/list?q=label:partcombine Recent partcombine issues however are not tagged "partcombine". http://code.google.com/p/lilypond/issues/list?can=2&q=partcombine Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Single Whole Measure Rest vs compressed MMR
On 28 February 2013 05:25, Werner LEMBERG wrote: > > As far as I know, they are treated similarly. OK, thanks. > Why should there be a difference? The idea of having compressed > MMRs is to save horizontal space, isn't it? I did not claim there should be a difference, I was asking the question. IIRC I increased the horizontal space of compressed MMR in order to prevent overlapping of tempo indications in a piece for an instrument part with many MMR (similar to what Kieren is also asking/fighting AFAIK). I also used it as a workaround because "full measure rests take too little horizontal space compared to notes" (issue 1798, still open as issue 3135). http://code.google.com/p/lilypond/issues/detail?id=3135 > Can you show us some literature scans which supports your claim? I can't, that's why I was asking the question (but instrument parts with lots of MMR and tempo indications still needs careful thinking). Since it seems "single Whole Measure Rest" and "compressed MMR" are usually treated similarly, sorry for the noise. Thank you for your consideration. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Single Whole Measure Rest vs compressed MMR
On 28 February 2013 01:05, Thomas Morley wrote:
>
> Hi Xavier,
>
> do you think of sth like this:
>
> (snip)
>
Hi Thomas,
Thank you for your answer.
I did not use the 'bound-padding property but I was overriding MMR
'minimum-length to different values corresponding to my needs.
Your 'bound-padding solution is interesting. I'm not used to
'before-line-breaking (and 'after-line-breaking) overrides and its
rather "cryptic" scheme expressions as values.
I'll keep that in mind for my future codes, thanks.
On 28 February 2013 01:37, Thomas Morley wrote:
>
> BTW, you could print the MultiMeasureRestNumber on a "single Whole
> Measure Rest", too:
>
> { \set restNumberThreshold = #0 R1 }
Yes I knew that (and already used it).
One point in favor of the fact that "single Whole Measure Rest" and
"compressed MMR" are usually treated similarly.
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Single Whole Measure Rest vs compressed MMR (WAS: Issue 3208 Wrong MultiMeasureRest glyph)
On 27 February 2013 18:13, wrote: > > Comment #1 on issue 3208 by philehol...@googlemail.com: Wrong > MultiMeasureRest glyph > http://code.google.com/p/lilypond/issues/detail?id=3208 > > OK - let's just be clear about what the bug is. Lilypond does the right > thing (TM) for single Whole Measure Rests - breve rests and longa rests are > correct. It does the wrong thing for multimeasure rests, where what it uses > for 2 breve bar rests (staff system 2 above) it uses the symbol for a 4 bar > church rest. That's wrong, agreed, and needs fixing. This reminds me of a question/issue I never asked here. I sometimes wanted different horizontal space settings for "single Whole Measure Rest" and "real" multimeasure rests a.k.a "compressed MMR" (with a number above). Currently LilyPond does not consider "single Whole Measure Rest" and "compressed MMR" differently. 1. Are "single Whole Measure Rest" and "compressed MMR" two different things, and treated as such, with specific rules, etc. in references like Ross, Read, Gould? 2. Would it make sense to have different grobs to handle these two with different properties settings ? Thank you for your attention. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bug with RehearsalMark, resulting in a wrong placed BreathingSign
On 15 February 2013 00:07, Thomas Morley wrote:
> With the following code the BreathingSign is placed wrong.
>
> \version "2.16.1"
> % same with:
> %\version "2.17.10"
>
> <<
> \new Staff \relative c'' { d8 d \mark \markup "Tutti" d2. }
> \new Staff \relative c' { d4 \breathe d2 \mark \markup "Tutti" d4 }
> >>
>
>
> I stumbled over it by accident.
> Setting the RehearsalMark on the second beat of Staff two, as actual
> intended, will solve the issue.
> Setting d4 instead of d8 d in Staff one, too.
> Using a shorter RehearsalMark, too.
>
> Nevertheless, the BreathingSign should be placed correct, in all cases.
Actually the placement of the RehearsalMark occurring at the same time
is also wrong. And both the BreathingSign and this RehearsalMark are
wrongly placed before the first note of the piece.
Strange (and very bad) bug, nice catch!
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Add tempo spanners
On 13 February 2013 01:43, Colin Hall wrote: > > Thanks for the report, Xavier, but I think we already have this feature > in Lilypond, don't we? See: > > http://lilypond.org/doc/v2.17/Documentation/notation/writing-text#text-spanners > > which documents syntax such as: > > \override TextSpanner.bound-details.left.text = "rit." > b1\startTextSpan > e,\stopTextSpan Hi Colin, Yes we already have text spanners but they can interact only with other text spanners, IIRC. It is not clear what this feature would do precisely (and this certainly deserves a discussion with both users and developers, that's why I cc: both discussion lists). But personaly I would like "tempo spanners" to be able to interact with tempo indications (MetronomeMark) in the same idea DynamicTextSpanner interact with DynamicText. So a \tempo command would end a "tempo spanner". On 13 February 2013 01:49, Jay Anderson wrote: > > If I'm understanding the request correctly this functionality isn't > currently available. Text spanners live in the staff. > TempoTextSpanners would live in the score and be set like current > tempo marks (bold and above the system). I've often wanted this > feature as well. Actually I would prefer non-bold but maybe italic (and 'dashed-line style) as default setting (see for example "rit.", "rall.", "accel."), but AFAICS some publishers print them upright, others italic. As usual, people could change these properties to what they want. On 13 February 2013 02:43, Colin Hall wrote: > > Thanks, Jay, that makes it much clearer. Just need some proposed syntax > now. Well, something like current syntax for TextSpanner would be OK I guess. But as far as I'm concerned I will certainly use a postfix syntax that does not need \set or \override to define the text before the note (like in the code of snippets "Dynamics text spanner postfix" and "Dynamics custom text spanner postfix" for DynamicTextSpanner in NR 1.8.1). Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Add tempo spanners
On 4 February 2013 16:01, Kieren MacMillan wrote: > Hello all! > > A few weeks ago, in response to Mike Solomon's call for features and bugs, I > posted a request: > >>> 2. Allowing a text markup (especially a MetronomeMark) to have a "minimum >>> measure length". This would avoid collisions, particularly where there are >>> lots of multi-measure rests (e.g., orchestral parts). > > His response was: > >> #2 is doable via a hack. Minimum lengths can only work if you use spanners, >> but you can hijack the tempo print function for a text spanner (and suppress >> the line afterwards) and then create a scheme engraver for text spanner that >> uses whatever as the left bound and the next bar line's non-musical paper >> column as the right bound. Or you could just use the existing engraver and >> use the last note in the measure as a bound, although this will potentially >> create uneven spacing in a measure. >> >> You'll have to manually put this TextSpanner in the topmost context and/or >> use ly:side-position-interface::move-to-extremal-staff (I'd recommend the >> former, as the latter is powerful but falls in the category of LilyPond >> black magic). Make sure to use springs and rods and set a minimum-length - >> there's an example in the docs with a hairpin or glissando or something >> spanner-y that does this. > > Is there anyone out there who can work on this with me? I've got some money > to put towards the implementation. It would be great to have a TempoTextSpanner, for example in order to handle common notation such as rit. - - - - a tempo or rall - - - - I do not see this request tracked yet. Bug squad, could you add it? Maybe Kieren or Mike could give a proper description. Link to the original thread: http://lists.gnu.org/archive/html/lilypond-user/2013-02/msg00064.html Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Add native support of pitched ornamentations
Hi,
In some part of the thread "A must-see for anybody on this list" on
lilypond-user, Joseph Rushton Wakeling and David Kastrup agreed that
LilyPond is missing a proper command for pitched ornamentations.
Instead of the current code
a4\mordent^\markup{ \flat }
we should have a dedicated command
a4\pitchedMordent { bes }
that would properly change the accidental when transposed, like
\pitchedTrill actually works (IIUC).
This enhancement could be applied to all the ornament scripts, but
differently for each of them (turn for example could have the upper
note or the lower note (or both) with accidentals, so printed above
and/or below the turn).
Original discussion:
http://lists.gnu.org/archive/html/lilypond-user/2013-02/msg00286.html
http://lists.gnu.org/archive/html/lilypond-user/2013-02/msg00287.html
http://lists.gnu.org/archive/html/lilypond-user/2013-02/msg00295.html
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bass figures are not horizontally aligned to whole notes
On 6 February 2013 22:13, Marek Klein wrote: > > Could this be considered as the minimal example and the bad output?: > > (snip) > Sorry for the late reply. I'm not the OP reporting this bug (I almost never use figure bass) but I think it is indeed a minimal example showing the issue. As mentioned by the French user, the issue is clearly visible especially when increasing staff size. On 12 February 2013 21:56, Ralph Palmer wrote: > > Thanks, Marek and Xavier, and my apologies, Marek, for misreading your name > and calling you Mark. This has been submitted as issue 3172 : > http://code.google.com/p/lilypond/issues/detail?id=3172 Perfect, thanks ! Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: LSR for two opposing fermatas fails on staff change
On 10 February 2013 09:43, Javier Ruiz-Alma wrote:
> The LSR for typesetting two opposing fermatas above/below a barline will not
> produce desired result when voices converge on one staff. Suggest adding a
> note
> of this, or better yet, how one could overcome this.
>
> http://lsr.dsi.unimi.it/LSR/Item?id=10
>
> (snip)
>
I use Neil's "multi-mark-engraver"
http://lists.gnu.org/archive/html/lilypond-user/2011-08/msg00157.html
and so far I never encountered any side-effect.
Lily code
% you should include the definition of "multi-mark-engraver"
% http://lists.gnu.org/archive/html/lilypond-user/2011-08/msg00157.html
markDown =
#(define-music-function (parser location text) (markup?)
(make-music 'MarkEvent
'direction DOWN
'label text))
\layout {
\context {
\Score
\remove "Mark_engraver"
\consists #multi-mark-engraver
\consists "Tweak_engraver"
}
}
soprano = {
c''2 \change Staff = "lower" d''2
\override Score.RehearsalMark #'break-visibility = #begin-of-line-invisible
\mark \markup { \musicglyph #"scripts.ufermata" }
}
bass = {
a'1
\markDown \markup { \musicglyph #"scripts.dfermata" }
}
\score {
\new GrandStaff <<
\new Staff = "upper" { \soprano }
\new Staff = "lower" { \bass }
>>
\layout {
}
}
End of lily code
Cheers,
Xavier
PS: I do not think a limitation in a LSR snippet that is AFAIK not part
of LilyPond official documentation could qualify as a bug.
But adding "multi-mark-engraver" features in LilyPond by default could
(should?) be considered as a nice feature request.
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Error by adding an exclamation mark !
On 2 February 2013 23:52, Piotr wrote:
> > I'm not top posting.
>
> \version "2.16.2"
> %{
> A reminder accidental can be forced by adding
> an exclamation mark ! after the pitch.
> Here it makes error.
> %}
>
> \relative c'' {
> \clef "treble" \key bes \major \time 6/8
> \autoBeamOff b8 a es!'~ es16[ c] d[ g] e8~|
> }
Hi,
The octave (' or , etc.) is part of the pitch.
Replace es!'~ by es'!~ .
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bass figures are not horizontally aligned to whole notes
On 1 March 2011 16:26, Reinhold Kainhofer wrote:
>
> 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
> <5>1 <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.
Hi,
Someone just asked a (different) question concerning figured bass
alignment on the French users mailing list, but then I found track of
this issue there, as well as this conversation.
AFAICS this issue is still present with 2.17.11.
I do not find the original report on the issue tracker, and I suppose
no fix has been pushed, since figures are not centered on note column.
Could someone confirm this situation?
My guess is that bass figures should indeed be centered on the note
heads (note column), so default behaviour should be changed accordingly.
But only the figures. Accidentals, +, etc. should not be taken into
account in the "centering", contrary to Bertrand's first "workaround".
If someone possessing a reference book could confirm this, thanks.
Then addition of this on the tracker would be appreciated.
Thanks you.
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1798 not verified for whole note full measure rest (4/4 time)
Hi Mike, Colin, LilyPond fellows, I'm sorry for this "one-year-later" intervention about this issue. http://code.google.com/p/lilypond/issues/detail?id=1798 A recent reply I did to Federico made me think about the fact that, in 4/4 time signature, full measure rests take very little horizontal space (well, *too little* actually, since it takes less horizontal space than a whole note). Then I remembered I already submitted a bug report about this but could not find it in the open issue. Finally I found it is closed/verified, but after I double-checked, while I reckon issue #1798 is indeed verified in 3/4 time (Reinhold's example, used by Colin to verify the issue), it is not the case in 4/4 time, as can be seen when compiling the code I submitted when I originally reported this issue (attached again here, with output from current 2.17.10 version), where FMR take more horizontal space than with 2.15.7, but still less than a whole note! Could you make full measure rests take as much horizontal space as the equivalent note for every measure/FMR duration? Thanks in advance. Cheers, Xavier -- Xavier Scheuer whole-measure-rest-horizontal-space.ly Description: Binary data <>___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Bug reports from December 14, 2012, forgotten?
Hi dear bug squad members, I do not want to criticize but I think some bug reports remained untracked, as I see no reply to the original poster. This is the case for Daniel Rosen's "Avoiding collisions involving full-bar rests" e-mail, Eluze's "add "real" string number extenders", Arle Lommel's "Changing document fonts with non-standard global font size causes scaling problems" or pls' "automatic scaling to landscape paper size leads to collisions". All of them reported on December 14, 2012. I do not know how you guys handle this, I just would like to make sure they do not become lost/forgotten. Thank you! Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Add "countUnfoldRepeats" feature
On 17 December 2012 12:18, Colin Hall wrote: > > Thanks for the very clear and complete feature request, Xavier. > > I've created a new tracker for this. > > http://code.google.com/p/lilypond/issues/detail?id=3038 Thank you, I starred it. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Document Measure_counter_engraver
On 17 December 2012 11:59, Colin Hall wrote: > > I searched the tracker and found this: > > http://code.google.com/p/lilypond/issues/detail?id=2924 > > Could you read that and let me know if this is the documentation you > were seeking? Thank you Colin. Yes indeed it is the documentation I was seeking. I searched with the terms "Measure_counter_engraver" or "counter", but I should have tried "\startMeasureCount" or simply "count". You found it, this is OK then. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
thumb but also "finger changes" should be Fingering
Hi,
I see that David Kastrup is currently fixing issue #1029
"\thumb should behave like other fingerings", thank you.
Does that mean that after the fix has been pushed \thumb will be
engraved by "Fingering_engraver" (or "New_Fingering_engraver", I do
not understand why there are two engravers)?
So that when we remove this engraver all the fingerings (including
thumbs) are removed?
Great, thank you.
Would it be possible to add a command for "finger changes", so that
they are engraved by "Fingering_engraver" ("New_Fingering_engraver")
also?
Currently the doc says
Markup texts may be used for finger changes.
c4-1 d-2 f-4 c^\markup { \finger "2 - 3" }
but of course by doing so they are engraved as TextScript,
not Fingering.
Could you add a feature request for this?
Thank you in advance.
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Add "countUnfoldRepeats" feature
Hi,
Now that "Measure_counter_engraver" has been implemented into LilyPond
people can add a measure counter (great, thanks).
But unfortunately people have to start it and stop it _manually_,
using \startMeasureCount and \stopMeasureCount.
Could we add a feature to have an _automatic_ measure counter for
unfold repeats?
Something like "countPercentRepeats" but for unfold repeats, that could
be named "countUnfoldRepeats".
With a "countUnfoldRepeats" property, "UnfoldRepeatCounter" object
and "Unfold_repeat_engraver".
I do not know if "repeatCountVisibility" property should be divided
into "percentRepeatCountVisibility" and "unfoldRepeatCountVisibility"
or if they could both share "repeatCountVisibility".
Example of how it would work
\relative c'' {
\set countUnfoldRepeats = ##t
\repeat unfold 4 { c1 }
}
End of example
Thank you in advance.
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Document Measure_counter_engraver
On 15 December 2012 16:58, David Nalesnik wrote: > > The Measure_counter_engraver is part of LilyPond as of 2.17.7. There > isn't any documentation yet. (For one thing, I'm unsure of where to > put it as it requires adding the engraver to a context. Would a > snippet be the best way to tackle this issue?) Hi, Thank you for implementing this "Measure_counter_engraver". French-speaking people were asking for this feature, and now that it exists, it would be nice to mention it in the doc so they are aware it exists and have an idea how to use it. Should the bug squad members add an issue to keep track until it is documented? Thank you in advance. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
"StaffPartCombine" i.e. combine different *staves* on a single staff feature request
Dear LilyPond developers and users,
dear bug squad, could you add this feature request on the tracker?
Here is a feature request made on the French users mailing list.
It can be seen as a mix of "PartCombine" and "RemoveEmptyStaves".
Like in \partcombine , when the music is identical it is printed only
once (on the same one staff) but unlike \partcombine when the notes
differ they are not printed on different voices on the same staff,
but instead on _different staves_.
This would be a very useful for the many cases (in orchestral scores)
when the cellos and double basses play the same part or for example
when a single voice (e.g. "Violin I") split (div.):
people at the right-hand side of the stand play the upper part
and people at the left-hand side play the lower part.
Usually the "divisi staves" are joined thanks to a brace
(like a GrandStaff, sometimes like a StaffGroup, with spanbars).
Addition of "div." text at the separation and "unison" text
when "back to normal" would be nice too, as well as for example
the possibility to change the instrument names automatically
at these passages ("Vcl/Cb" vs "Vcl" and "Cb").
Sometimes (in existing published scores) the division is done
at a line break, sometimes not (in this case the "unison" part is
either printed on both separate staves, either the publisher uses
"repeat percent" measures).
Same for the "div. end", sometimes at a line break, sometimes not.
New parameters to define these desired settings would be appreciated.
And the "overkill feature" would be to have the same construction for
"VoicePartCombine" (aka current \partcombine) and "StaffPartCombine",
thus allowing to mix these different "combines" and for example to use
the same "notes files" but have different outputs for the conductor
and separate parts.
If it could handle more than two voices, that would be great,
as I have experienced 3 or 4 voices on different staves.
Many thanks for your consideration.
If you have questions, do not hesitate to ask.
Please do not forget to cc: Loïc and Jean-François as they asked for
this feature on the French users mailing list, so they could also say
how they would see this new feature work.
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug? with Choir Staff
On 21 August 2012 23:28, Colin Hall wrote: > > Thanks for the help, Reinhold. > > Aaron, thanks for taking the time and effort to post a bug report > through Gmane. > > Following up on the comment from Reinhold, could you confirm what OS > you are using. Also, which PDF viewer you are using? > > Could you try a different viewer? The version of LilyPond used is also a relevant information. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Center a number above a measure
On 28/03/2012, Colin Hall wrote:
>
> Looking at that horn part I only see the number "1" above single bar rests.
> So, does the following code meet your needs?
>
> Documented here:
> http://lilypond.org/doc/v2.14/Documentation/notation/writing-rests#full-measure-rests
>
> {
> \set Staff.instrumentName = \markup \column { \line {With} \line {markup}
> }
> R1*1^\markup \huge \bold "1" | R1*1^\markup \huge \bold "1" | R1*1^\markup
> \huge \bold "1"
> }
>
This is complicated and tricky, IMHO.
Why not use
\set restNumberThreshold = #0
> I'll add this as a feature request. The code from David would make a good
> starting point.
As I said on the tracker (BTW, with the new "lilypond-auto" mailing list
should we send our comments as "comments" on the tracker (which would
be buried on "lilypond-auto") or reply as a normal e-mail to
bug-lilypond?), this is an advanced version of issue #146 .
http://code.google.com/p/lilypond/issues/detail?id=146
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Flat collides with Slur
On 18 March 2012 23:27, Mark Mathias wrote: > Is this a bug? It looks strange to me to see a flat sticking through a > slur... Even though I'm on the Bug Squad I thought somebody else should > look at it before creating an issue. I think it is already tracked as issue #796 . http://code.google.com/p/lilypond/issues/detail?id=796 Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Combining lyrics lines
On 18 March 2012 14:36, Trevor Daniels wrote: > > Yes please! That would be the correct place for it. There is nothing > in the vocal section at the moment about the new spacing parameters, > and this would be a great start. Hello, I think the *French-speaking* mailing list was cc: by mistake in the first message of this thread. Could you take care of *not* cc: lilypond-user-fr in the next messages of this english-speaking thread? Thanks in advance. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Slurs between different voices
On 16 March 2012 17:44, Francisco Vila wrote:
>
> Thank you. I have tried the \hideNotes trick but does not work because
> a beam is only printed it the initial note is not hidden.
The code I would have used (maybe a bit tricky).
Snippet
\version "2.15.30"
\new Staff {
\time 2/4
<<
\new Voice {
\relative g'' {
\voiceOne
s4 g16( f e d |
\stemDown
\once \override Flag #'style = #'no-flag
c'16-|) s16*3
}
}
\new Voice {
\relative g' {
\stemDown
s4 g4 |
c16( d bis c)
}
}
>>
}
End of snippet
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Slurs between different voices
On 16 March 2012 17:30, Francisco Vila wrote: > > This is not an upright slur from the lowest note, this is a 'downside' slur Right, I did not consider this case. Nice request, then. > See attached again. How do you do that? Right now I would use two voices. ;-P But with your "be able to start a slur from a specific note of a chord" it would be easier, of course. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Slurs between different voices
On 16 March 2012 16:51, Francisco Vila wrote: > > Also, I had put my hopes in this variant: > > (snip) > > %END > > But not. Might be considered as an issue. But IMHO issue #1316 is by far more confusing for lambda users: I mean, I replied to dozens of e-mail from users on the French (but not only) user mailing list who did not understand why slurs, hairpins, spanners, lyrics do not work when going from inside a << \\ >> construct to outside of it (and vice-versa). And I think solving issue #1316 could "solve" your situation as well. http://code.google.com/p/lilypond/issues/detail?id=1316 Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Slurs between different voices
On 16 March 2012 16:47, Francisco Vila wrote:
>
> Well I'd change the title to "be able to start a slur from a specific
> note of a chord". This gives a warning and does not printa a slur. For
> cases like this, maybe still the named slurs have any sense.
>
> \version "2.15.30"
> \new Staff {
> \new Voice \relative f {
>16 d, b c )
> }
> }
To have a slur from the highest note of the chord use
^(
For a slur to start from the lowest note
_(
What would you expect —as graphical output— for a slur starting on
a note *in the middle of a chord*? I cannot represent how it would
look like and I cannot remember having seen such thing (in "normal
chords I mean, this is different from a polyphonic passage)?
??
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Slurs between different voices
On 16 March 2012 13:51, Francisco Vila wrote:
>
> I attach two. Op25-n3 is more obvious. Its code (w/o slur) would be
> something like
>
> \version "2.15.30"
> \new Staff \relative f {
> <<
>\new Voice { \voiceOne d''16 c8. g16 f8. }
>\new Voice { \voiceTwo f8[ f'] c,[ c'] }
> >>
> }
>
>
> A comfortable syntax would be \startSlur #name ... \endSlur #name like in
>
> <<
>\new Voice { \voiceOne d''16 \startSlur #A c8. }
>\new Voice { \voiceTwo f,8[ f'] \endSlur #A }
> >>
>
> A #name would be reusable if the slur has ended in a previous column.
> Otherwise, new names everywhere would be needed.
Hi Francisco,
Simply moving the "Slur_engraver" from Voice level to Staff level does
what you want, IIUC.
Snippet
\version "2.15.33"
\score {
\new Staff {
\time 2/4
<<
\new Voice {
\relative c'' {
\voiceOne
d16( c8. a16( g8.
}
}
\new Voice {
\relative c'' {
\voiceTwo
g8 g') c,,8 c'8)
}
}
>>
}
\layout {
\context {
\Voice
\remove "Slur_engraver"
\remove "Slur_performer"
}
\context {
\Staff
\consists "Slur_engraver"
\consists "Slur_performer"
}
}
}
End of snippet
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bug for slur and (not) restored accidental
On 27 January 2012 15:48, Rutger Hofman wrote:
> % If a slur spans a bar, and after the bar a note has an accidental
> % as-per key, and the note before the bar is the same but natural-ed,
> % an accidental should be printed for the note after the bar.
> %
> % The first line in the example should be identical to the second line.
> % This is irrespective of accidentalStyle.
>
> \version "2.14.0"
>
> \score {
>\new Staff {
>\key g \major
>\time 2/4
>
>f'2( |
>fis') | \break
>f'2( |
>fis'!) |
>}
> }
This is disputed.
Just for the record, 2 threads discussing this "issue" (and whether this
should be considered as an issue or not). "Workarounds" are
straightforward and are also mentioned there.
http://lists.gnu.org/archive/html/lilypond-user/2011-11/msg00408.html
http://lists.gnu.org/archive/html/lilypond-user/2011-01/msg00524.html
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Top Margin Adjustment
On 24 January 2012 00:25, -Eluze wrote: > > it's not ignored - but after having defined top-margin = 5\cm you override > this with #(set-paper-size "letter") > > changing this order will do what you expect! I missed that point. IMHO it is worth mentioning this as a warning in NR 4.1.3 and 4.1.5 (for top-margin, bottom-margin and left-margin, right-margin, inner-margin, outer-margin, binding-offset, indent and short-indent respectively). The difference between modifying these variables and their corresponding top-margin-default, bottom-margin-default, etc. should also be explained there. Thank you in advance. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Top Margin Adjustment
On 24 January 2012 00:13, Thomas Wilmot wrote: > Hello, > > In any LilyPond score, I always find the top margins to look abnormally small. > I have tried to set top-margin, but for some reason, it is ignored. If you replace "top-margin" by "top-margin-default" it works. But of course this issue (regression?) is totally valid! I do not understand why many paper settings have been replaced by "same-name-default" in ‘ly/paper-defaults-init.ly’. Is it for automatic scale depending on paper size? IIRC that does not work for several of them and it is not properly documented in the NR. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Regression: 16th tuplets not subdivided with subdivideBeams
Hello,
Just reported on the French Users mailing list:
Snippet
%% subdivideBeams does not work anymore with 16th tuplets.
%% With 2.15.26 only the second beat is subdivided as expected.
%% Worked well with stable 2.14.2, so this is a Regression.
\version "2.15.26"
\relative c'' {
\set subdivideBeams = ##t
\set baseMoment = #(ly:make-moment 1 8)
\set beatStructure = #'(2 2 2 2)
\repeat unfold 8 {
\times 2/3 { c16 e d }
}
}
End of snippet
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Defect [new]: \partcombine: accidental reminders of first part lost.
On 19 January 2012 18:06, Peter Häring wrote:
> \partcombine { bes'1 b'! } { g'1 b' }
>
> %Second example: second part has a reminder natural; it is shown in combined
> % parts (as it should be).
> \partcombine { d''1 b' } { bes'1 b'! }
Workaround:
\partcombine { bes'1 \partcombineApartOnce b'! } { g'1 b' }
\partcombine { d''1 b' } { bes'1 \partcombineApartOnce b'! }
but then we fall in the case of displaying "complex chords", like
. I thought we had this accidentals in "complex chords" as an
issue on the tracker but I do not find it. It as been discussed several
times on various LilyPond mailing lists, there is a snippet "Displaying
complex chords" on the LSR: http://lsr.dsi.unimi.it/LSR/Item?id=505
(not always "usable").
AFAIK developers would like examples of how such situations are handled
by music publishers. Do they use separate note heads, where do they
place the accidentals, etc. But if "complex accidentals in chords" is
not tracked yet, then it should be added IMHO.
Relevant code showing the issue is simply
If someone could have a look at what Ross, Read or Gould say about this,
how to engrave it, that would be very kind.
I do not know how (forced, cautionary) accidentals are handled by
\partcombine but that may require a separate issue.
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Production with LilyPond
On 9 January 2012 17:35, Aurélien Bello wrote: > Hi, > > I would like to : > > 1. Wish you a happy new year 2012 Hello, Happy new year 2012 likewise. I guess this message would be more appropriate on lilypond-u...@gnu.org rather than on the bug reports mailing list. May I suggest you to send it (again) to this address, thus reaching the LilyPond Users community? > 2. Thank you for your wonderful work with Lilypond > 3. Inform you about a production: > I am a conductor living in Berlin. > Last summer I re-orchestrated the "Pictures at an exhibition" of > Mussorgsky and made the whole orchestra material and the score using > LilyPond. It was a pleasure to use your software for this (long) job > and the musicians enjoyed it a lot. > The new orchestration has been played 16.10.2011 and will be played > again 15.4.2012 and 16.4.2012. > You can find more informations about the concerts on my website. Since these concerts are located in Germany, you could announce it on the "Deutsches Lilypond Forum": http://www.lilypondforum.de I suppose such announcement would be acceptable there. > If you wish I can send you a pdf-copy of the files. If you wish you could release it under a free license, and make it available (with the .ly files) on the Mutopia Project website http://www.mutopiaproject.org or as PDF on the International Music Score Library Project (IMSLP) website: http://imslp.org . See respectively http://www.mutopiaproject.org/contribute.html or http://imslp.org/wiki/IMSLP:Contributor_Portal to contribute. Cordialement, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reorganize NR 1.3 Expressive marks
Hi James, Currently we have snippets about DynamicTextSpanner both in NR 1.3.1 Expressive marks attached to notes > Dynamics and in NR 1.8.1 Writing text > Text spanners . It would be more consistent to have everything about DynamicTextSpanner in the same section of the NR, i.e. NR 1.3.1, with a cross-reference to this section in NR 1.8.1. But that would make a lot of snippets about dynamics together. Why not make a specific section of NR 1. Musical notation about dynamics (e.g NR 1.3 Dynamics , containing what is currently in "Dynamics" and "New dynamic marks" + the snippets moved from NR 1.8.1), and another section for the other "expressive marks attached to notes" (NR 1.4 "Expressive marks attached to notes" containing in the order "Articulations and ornamentations", "Trills", "Slurs", "Breath marks", "Falls and doits", "Glissando", "Arpeggio")? I'd suggest something like: NR 1.3 Dynamics 1.3.1 Dynamic marks 1.3.2 Hairpins 1.3.3 Dynamic text spanners 1.3.4 New dynamic marks 1.3.5 Custom dynamic text spanners NR 1.4 Expressive marks 1.4.1 Articulations and ornamentations Articulations and ornamentations, Trills (with trills together) 1.4.2 Curves Slurs (with a warning cross-ref about ties), Phrasing slurs, Breath marks, Falls and doits 1.4.3 Lines Glissando, Arpeggio (but not trills here) We could add something about the horizontal line that means "keep the finger", "keep the position" or "stay on the same string". What do you think? I could help with that after February. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Hairpin #'minimum-length does not apply to real length of the hairpin
Hi,
I noticed this while replying to James.
\override Hairpin #'minimum-length = #8 does not take into account the
fact that a hairpin can be shortened by the presence of a DynamicText.
"minimum-length" is applied not the real length of the hairpin, but to
the length of the hairpin **if it would not have been shortened by the
presence of a dynamic**. IMHO it should apply to the _real length_ of
the hairpin (the printed one!), even if it is a "shortened hairpin"
(hey, it is usually these "shortened hairpins" that we —the users— want
to lengthen when we \override Hairpin #'minimum-length !!).
It is not easy to explain this, I hope the following code will help you
to understand better what I mean.
Snippet
\version "2.15.24"
\relative c' {
c1\< |
c\mf |
\override Hairpin #'minimum-length = #8
c\> |
% this "shortened" (due to the presence of the DynamicText) hairpin
% does not have a _real_ minimum-length of #8 !
c1\ppp\<^"too short!" |
\override Hairpin #'minimum-length = #12
c\fff\> |
c\> |
\revert Hairpin #'minimum-length
c\mf\> |
c\p
}
End of snippet
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: PianoStaff, time and grace duplicates the time display
On 8 January 2012 18:12, Romain Behar wrote: > Dear Xavier, > > Thanks for your help, I've overlooked that part of the documentation. > Another related question: replacing the grace wit an acciaccatura adds a > slur between the grace and the next note. This looks OK, except that the > slur also shows with the skip followed by a rest: > > […] > > Any idea how to remove that extra slur? Use \grace s8 instead of \acciaccatura . Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: PianoStaff, time and grace duplicates the time display
On 7 January 2012 23:47, Romain BEHAR wrote:
>
> %
> % Adding a grace at the beginning of a piano staff repeats time value
> % The following example displays: treble, 3/4, grace note, 3/4 again, c''
> %
Please read the notation reference, NR 1.2.6 Special rhythmic concerns
> Grace notes > "Known issues and warnings"
Grace note synchronization can also lead to surprises. Staff notation,
such as key signatures, bar lines, etc., are also synchronized.
Take care when you mix staves with grace notes and staves without.
This can be remedied by inserting grace skips of the corresponding
durations in the other staves.
http://lilypond.org/doc/v2.15/Documentation/notation/special-rhythmic-concerns.html#grace-notes
In your case
\new PianoStaff <<
\new Staff {
\time 3/4
\grace d''8 c''
}
\new Staff {
\time 3/4
\grace s8 r4
}
>>
Grace synchronization is tracked as issue #34
http://code.google.com/p/lilypond/issues/detail?id=34
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Engravers cannot be added at the StaffGroup level
Dear Bug Squad,
This has been reported two times in lilypond-user:
http://lists.gnu.org/archive/html/lilypond-user/2011-12/msg00395.html
http://lists.gnu.org/archive/html/lilypond-user/2012-01/msg00111.html
"Mark_engraver" or "Metronome_mark_engraver" should be moveable to the
StaffGroup (and alike: GrandStaff, ChoirStaff, etc.) context (and work!!).
Snippet
\version "2.13.24"
music = \repeat unfold 5 {
\repeat unfold 5 c'1
\mark \default
}
\score {
<<
\new Staff {
s1*0^"Marks should NOT be above this Staff (i.e. above the Score)!"
\music
}
\new StaffGroup {
<<
\new Staff {
s1*0^"Marks should be above the StaffGroup"
\music
}
\new Staff {
\music
}
>>
}
>>
\layout {
\context {
\Score
\remove "Mark_engraver"
% same for "Metronome_mark_engraver"
\remove "Staff_collecting_engraver"
}
\context {
\StaffGroup
\consists "Mark_engraver"
\consists "Staff_collecting_engraver"
% same for "Metronome_mark_engraver"
}
}
}
%% Note that it works if we move it to the Staff level (instead of the
%% StaffGroup). But engravers at the StaffGroup level is required for
%% example if the first staff of the StaffGroup is removed, using
%% \RemoveEmptyStaves (Frenched score).
\score {
<<
\new Staff {
s1*0^"Marks are not above the score"
\music
}
\new StaffGroup {
<<
\new Staff \with {
\consists "Mark_engraver"
} {
s1*0^"Marks are above this Staff"
\music
}
\new Staff {
\music
}
>>
}
>>
\layout {
\context {
\Score
\remove "Mark_engraver"
\remove "Staff_collecting_engraver"
}
\context {
\Staff
% \consists "Mark_engraver" % We add this engraver to the
second Staff only
\consists "Staff_collecting_engraver"
}
}
}
End of the snippet
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Figured bass and rehearsal marks
On 1 January 2012 16:19, Nicolas Sceaux wrote: > Hi, > > LilyPond from today's git. > > ReahearsalMarks, with DOWN direction, are placed between the lower staff > and its figured bass, whereas one would expect the mark to appear below > the figured bass. > > Example: > > […] > > A possible workaround: > > (Is there a better way?) Not better, but another workaround: you could add "Mark_engraver" to the FiguredBass context (with RehearsalMark #'direction = #DOWN). The right solution would be to extend "Staff_collecting_engraver" so that it handles "non-staff" as well (lyrics, chords, figured bass and Dynamics context). Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Beam subdivision bug in 2.15.22
On 16 December 2011 19:48, Thomas Scharkowski wrote:
> \times 2/3 { b16 b b } b8 b4 b b
>
> 2.15.22 produces a (wrong) beam subdivison.
> 2.14.2 output is correct.
> See attachments.
Result is fine with 2.15.20.
I did not make a git-bisect but I suspect Carl's fix for issue #11
to be the cause of this.
http://code.google.com/p/lilypond/issues/detail?id=11
I'm not a git expert but it seems Carl's commit was pushed a few hours
after 2.15.20 release, so issue #11 should have been tagged as
fixed_2_15_21, isn't it?
A better wording for this issue report would be something like
"unexpected beamlet in tuplet sixteenth". But maybe it is better to
reopen issue #11.
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Feature request: multiplication should work on notes, chords and all rests
On 15 December 2011 22:58, Pavel Roskin wrote: > Hello! > > For some reason, multiplication only works on full-measure rests > and silent rests. > > It would be nice to make it work on notes, chords and all kinds of > rests. For short repetitions, \repeat unfold is an overkill, which > doesn't make the source shorter: > > […] > There were already some (intense?) discussion about this. See issue #1067, which is AFAICS the same request as yours. http://code.google.com/p/lilypond/issues/detail?id=1067 Graham said he added it to the list of things to discuss in GLISS. In case you did not know, there is already a "shortcut syntax" when repeating the same chord: 'q' 4 q q q Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: no barlines in pdf output
On 12 December 2011 12:55, renato wrote:
>
> tiny example:
>
> \version "2.14.2"
>
> %the following gives no barlines in pdf output
> \relative c'' {
> c1 | c1 | c1 |
> }
>
>
> I'm on Archlinux i686, and this was confirmed by others here:
> https://bugs.archlinux.org/task/25106
Hi,
This was already reported:
https://lists.gnu.org/archive/html/bug-lilypond/2011-08/msg00126.html
https://lists.gnu.org/archive/html/bug-lilypond/2011-08/msg00127.html
But this does not appear with "official" version of LilyPond, so the
issue is more likely in Arch's packaging, probably a different version
of Ghostscript or FontForge (more recent) than the one used in official
LilyPond package.
There is a "preventive" bug report to check/fix the possible
incompatibility with Ghostscript 9:
http://code.google.com/p/lilypond/issues/detail?id=1717
and there are currently some plans to upgrade the version of FontForge
used in "official" LilyPond:
http://code.google.com/p/lilypond/issues/detail?id=1637
http://code.google.com/p/lilypond/issues/detail?id=1964
So if an issue pops up due to one of these it will be fixed when
LilyPond will use them.
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Set global staff size as command line option
On 11 December 2011 01:23, Colin Hall wrote: > > Added as issue 2095 > > http://code.google.com/p/lilypond/issues/detail?id=2095 Thanks! > It looks like the developers have selected some variables, including > paper-size, for inclusion in the ly:set-option feature. I'll create > a feature request and let them determine if it is possible or > desireable to add global-staff-size. At least from a (well, "my") user perspective this is very desirable. I know some people wearing glasses who prefer their scores to be in bigger (global-)staff-size. It would be so convenient to be able to do it in command-line with a syntax like the one for paper-size! The way given by Francisco (and yourself) have some severe drawbacks compared to the "like paper-size" way. You need to add something in your .ly file and the argument -e'(define-public mySize 14)' is _mandatory_ if you want to compile the file, i.e. it is impossible to compile the file "normally" (lilypond without any argument) anymore. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
$LILYHOME as $TEXMFHOME with LaTeX
Could you please add the forwarded feature request to the tracker? Carl said "It seems to me that this would be a useful thing". Graham: "That's a feature request from at least 7 years ago. It's not at all new. If you want to get it "in the system", send it to bug-lilypond.". Similar request on lilypond-user a few days ago: http://lists.gnu.org/archive/html/lilypond-user/2011-12/msg00117.html http://lists.gnu.org/archive/html/lilypond-devel/2011-12/msg00073.html -- Forwarded message -- From: Denis Bitouzé Date: 5 December 2011 17:21 Subject: $LILYHOME as $TEXMFHOME with LaTeX To: lilypond-de...@gnu.org Hi, thanks a lot for developing and maintaining LilyPond! I read the way of including LilyPond files here: http://lilypond.org/doc/v2.14/Documentation/notation/including-lilypond-files.html especially the way where one can avoid to specify the (relative or absolute) path of the included file: 1. either with the --include command line option 2. or with the LilyPond directory ‘../ly’. IMHO, none of these method is very handy: 1. with the 1st one, one has to remember the option and configure his editor for each project where "parts" files have to be included. Moreover, one could need to include files from different locations: a configuration file in some directory, part files in another directory, 2. with the 2nd one, the 'ly' directory could be removed/replaced/overwritten when LilyPond is upgraded or reinstalled. So I suggest that LilyPond lets us have our own 'ly' directory, located in our personal area (/home// with Linux, /Users//Library/ with Mac OS, C:\Users\\ with Windows Vista or Seven) where we can put files (parts files but, more interesting, configuration files) that can be included in LilyPond files without their path. If you are familiar with LaTeX, this 'ly' directory could be the $LILYHOME equivalent to $TEXMFHOME. What is opinion about this suggestion? Best regards. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1377 should be pushed now?
Hi Joe, dear developers, bug squad, Issue 1377 is tagged as "Patch-push" since more than one month now, should it be pushed, go under a countdown? http://code.google.com/p/lilypond/issues/detail?id=1377 As said David 2 weeks ago: "What's up with this one?". Thanks for your attention. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Doc: alternativeNumberingStyle (fix issue 2059) should be documented
On 7 December 2011 23:44, Carl Sorensen wrote: > > This should become a new issue, type Documentation. > > Thanks, The use of this \set Score.alternativeNumberingStyle = #'number or \set Score.alternativeNumberingStyle = #'numbers-with-letters (from the fix of issue 2059 "Bar numbering of alternatives" http://code.google.com/p/lilypond/issues/detail?id=2059 http://codereview.appspot.com/5440049 ) deserves an explanation (as a snippet) in the notation reference, NR 1.4.1 Long repeats and maybe a cross-reference in NR 1.2.5 Bars > Bar numbers and this new feature deserves an entry in 'Documentation/changes.tely' IMHO Thank you! Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Set global staff size as command line option
On 9 December 2011 10:27, Colin Hall wrote: > > Added as issue 2090 > > http://code.google.com/p/lilypond/issues/detail?id=2090 This is nice to add this to the tracker. It would be nice to add my initial request (first message of this thread) to the tracker also. Maybe I was not clear, but that feature request has its place on the tracker, isn't it? Cheers, Xavier On 7 December 2011 15:01, Xavier Scheuer wrote: > Hi, > > Is it possible to set global staff size as command line option? > Like it is possible to specify paper size with > > lilypond -dpaper-size=\"letter\" myfile.ly > > I'd like a similar command line option for #(set-global-staff-size 14) . > Is there a way to achieve this with current version? > > Anyway, I think that would be a nice new feature. > Dear bug squad, could you add this request on the tracker ? > Thanks! > > Cheers, > Xavier > -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Where to put user ly files on OSX?
On 7 December 2011 02:58, huzzam wrote: > > Hi-- > > I'm fairly new to lilypond, and am starting to write my own ly files to > include. I want to put them somewhere that will be accessible easily from > any score (user defaults). The only place I've so far been able to find to > put them is inside the lilypond application package itself > (/Applications/Lilypond.app/Contents/Resources/share/lilypond/current/ly). > This obviously is annoying when I upgrade lilypond, as I have to dig in > there and copy my files to the new one. > > Is there some place I can put them so that I can still just "\include > asdf.ly" (without a path), but which is not inside the package itself? > Something along the lines of ~/Library/lilypond or /usr/share/lilypond? There is not such features in LilyPond yet (but I'd love this too). Denis made a similar request on lilypond-devel a few days ago. http://lists.gnu.org/archive/html/lilypond-devel/2011-12/msg00073.html No developer replied at the moment; I hope one will say something about it. Then I suppose it could be added to the tracker (cc: to bug-lilypond) as a new feature request. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Set global staff size as command line option
Hi, Is it possible to set global staff size as command line option? Like it is possible to specify paper size with lilypond -dpaper-size=\"letter\" myfile.ly I'd like a similar command line option for #(set-global-staff-size 14) . Is there a way to achieve this with current version? Anyway, I think that would be a nice new feature. Dear bug squad, could you add this request on the tracker ? Thanks! Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Doc: improve NR 1.6.3 Instrument names (better to use \with )
Dear bug squad, could you add this doc improvement request to the
tracker, as asked by James in this thread? Thanks!
http://lists.gnu.org/archive/html/lilypond-devel/2011-12/msg00041.html
In NR 1.6.3 Writing parts > Instrument names , it should be recommended
to use
\new Staff \with {
instrumentName = #"Bassoon"
}
and _not_ (advise against)
\set Staff.instrumentName = #"Violin "
for the following reason: one _must_ use \with {…} to avoid the
instrument name _not to be printed!_ if a parallel voice starts with a
\grace .
This is not an "hypothetical issue", we got at least half a dozen
messages from users experiencing this "issue" (although they did
exactly what is said in the documentation) on the French users mailing
list.
Could you please change the doc, NR 1.6.3 Writing parts > Instrument
names , accordingly?
Thanks in advance.
Here is a snippet showing the relevance of this issue (typically what
a lambda user would encounter).
\version "2.15.20"
\score {
<<
\new Staff \with {
instrumentName = #"OK"
} {
c'1
}
\new Staff \with {
instrumentName = #"OK"
} {
\grace b8 c'1
}
>>
}
\score {
<<
\new Staff {
\set Staff.instrumentName = #"NOT PRINTED!!"
c'1
}
\new Staff {
\set Staff.instrumentName = #"NOT OK"
\grace b8 c'1
}
>>
}
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Most popular French users request : bar numbering of alternatives
Dear LilyPond developers,
Dear Bug Squad members, could you add this enhancement request to
the tracker? Thanks!
This is by far the most popular enhancement request from the French
users mailing list: Bar numbering of repeat volta _alternatives_.
Currently LilyPond counts the measures of each "alternative" as
normal, unrepeated, measures hence incrementing the currentBarNumber
in both alternative "1." and "2.". Several references supports what is
actually asked by many users: bar numbering of alternatives should not
be counted twice.
\version "2.15.20"
\relative c' {
\override Score.BarNumber #'break-visibility = #'#(#t #t #t)
\repeat volta 2 {
c1 | % 1
c1 | % 2
c1 | % 3
}
\alternative {
{
c1 | % currenlty: 4 % request: 4 or 4a
}
{
c1 | % currently: 5 % request: 4 or 4b !!
}
}
\textLengthOn
c1^"currently: 6 request: 5 !!" | % currently: 6 % request: 5 !!
\textLengthOff
c1 | % currently: 7 % request: 6
% etc.
}
Please do not discard this (popular) request again.
I'd suggest to have _at least_ the possibility to switch on this
feature, for example via a variable setting such as
\set barNumberAlternativeOnce = ##t
Well-know music publishing houses that use this numbering includes
Simrock, Breitkopf, Bärenreiter, Henle.
E.g. Henle et Breitkopf: |1. 34 | 35 :||2. 34 | 35 etc.,
Bärenreiter: |1. 34a | 35a :|| 2. 34b | 35b.
I do not know what say music engraving books like Ross, Read or Gould
but here is what says Jean-Pierre Coulon in his "Repository of
music-notation mistakes" or "Essay on the true art of music engraving":
"When first ending-second ending measures are present, measure numbers
of only the first ending measure act on the numbering. If necessary,
corresponding measure numbers have the subscripts a and b."
Section 5.4 page 9.
http://www.icking-music-archive.org/lists/sottisier/sottieng.pdf
http://www.icking-music-archive.org/lists/sottisier/sottisier.html
And here are some messages of users supporting this request.
lilypond-user-fr (in French):
http://lilypond-french-users.1298960.n2.nabble.com/Repetitions-volta-et-numeros-de-mesure-td7036772.html
http://lilypond-french-users.1298960.n2.nabble.com/numerotation-des-mesures-en-cas-de-reprise-avec-alternatives-td6936029.html
http://lilypond-french-users.1298960.n2.nabble.com/numeros-de-mesures-et-reprises-td5565647.html
http://lilypond-french-users.1298960.n2.nabble.com/Numeros-de-mesure-dans-1-et-2-td5227683.html
http://lilypond-french-users.1298960.n2.nabble.com/Numerotation-de-mesures-et-reprises-td4474721.html
lilypond-user:
http://lists.gnu.org/archive/html/lilypond-user/2009-07/msg00522.html
http://lists.gnu.org/archive/html/lilypond-user/2007-09/msg00096.html
http://lists.gnu.org/archive/html/lilypond-user/2006-09/msg00113.html
The implementation and what to do in the case of alternatives of
different measures duration are open to discussion.
But keep in mind that in 90% of the cases there are only 2 alternatives
which have the same measures duration. In the remaining cases
the first alternative is often the shortest.
Thanks for your attention.
Cheers,
Xavier (and many French users)
--
Xavier Scheuer
___
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
2011/11/27 Przemysław Pawełczyk :
>
> By "it will be" I thought it is somewhat automated process, but I
> don't see it in:
>
> http://code.google.com/p/lilypond/issues/list
>
> Am I obliged to add the issue myself? I don't know LilyPond
> bug-related workflow (and I wasn't sure it's bug in the first place,
> hence I didn't send my mail to bugs ML).
No, there is a team of people ("Bug Squad") who add the issues to the
tracker after the report on bug-lilypond. Phil added it one hour ago
(although he did not cc: his message to you).
http://code.google.com/p/lilypond/issues/detail?id=2057
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2 pages on only one sheet
On 27 November 2011 12:41, Phil Holmes wrote: > > This mailing list is for reporting bugs, and you may not get the answer you > want, since not all experienced users will read it. I suggest reposting > this to lilypond-user, and also saying what operating system you use. Actually this is a feature request: to have the ability to have, for example, two A5 "pages" on A4 paper, directly with LilyPond. Jean-Cristophe (another french user) suggested a syntax like: #(set-paper-size "a4") #(set-*page*-size "a5") Cheers, Xavier -- Xavier Scheuer ___ 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 25 November 2011 17:50, PrzemysławPawełczyk wrote:
> Hello.
>
> 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.
>
> I believe it should be possible to fix it globally (some override?)
> without rewriting dynamics to end (de)crescendo earlier, because in
> more complex pieces it would be really cumbersome.
>
> Example (possibly not the tinest one):
> http://paste.przemoc.net/lilypond/decrescendo-touches-bar/decrescendo.ly
>
> Sorry for not putting it here inline, but because of broken top-posting
> detection in gmane I couldn't send it otherwise. I reported the problem,
> so hopefully it will be fixed in future.
>
> Above example rendered and converted to image:
> http://i.imgur.com/ZQkQA.png
>
> Compare 1st and 3rd measures (bad) with 2nd and 4th (good).
>
> Regards.
>
> P.S. Please add me to CC as I'm not on the list.
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.
LilyPond code (bug report)
%% Hairpin at a line break touches the barline, whereas for a normal bar
%% (i.e. not at a line break) it does not.
%%
%% Might be (or not) related to Reinhold's fix for #1433 (1259).
%%
%% Reported by Przemysław 'Przemoc' Pawełczyk, modified minimal example.
\version "2.15.20"
music = \relative c' {
c1\p\< | c\f\> | \break
c1\p\< | c\f\> | c1\p\< | \break
c1\f
}
\score {
<<
\new StaffGroup <<
\new Staff {
\music
}
\new Staff {
\music
}
>>
>>
}
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: CRASH
On 30 October 2011 10:53, 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...) > > Any help would be appreciated! Which version of LilyPond are you using? Do you use LilyPond packaged by Ubuntu (installed via Synaptic) or a version downloaded from lilypond.org ? It is recommended to use the "official" LilyPond, not the one packaged by a linux distro in order to report only issues due to LilyPond itself. Then it would be great to provide a minimal example of code generating the issue (by trying to reduce your score to this minimal example). Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: MetronomeMark #'break-align-symbols sometimes fails
On 14 October 2011 00:33, Kieren MacMillan wrote: > > This is a little frustrating, as it was part of a bounty fix from some > time ago. > > I understand the ultimate fix is [apparently] difficult — and Neil > generously gave me a hack to tweak certain issues, especially at line > breaks — but it would be nice to know what it would take to get > MetronomeMark working as desired, once and for all. Hi Kieren, I share your frustration (maybe because I also give a little penny to fix issue #684 (I know the issue number by heart!)). I would be interested to hear if Neil gave you a hack to tweak this particular issue (Neil gave me some hacks too, that are really great and that I am using very often). Too bad there is no simple and clean solution that could be implemented directly! Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: MetronomeMark #'break-align-symbols sometimes fails
On 28 September 2010 20:41, Valentin Villenave wrote:
>
> Hi Xavier,
>
> You're right, it seems to have grown into some sort of an obsession with you
> :)
>
> Anyway, added as http://code.google.com/p/lilypond/issues/detail?id=1276
One year later, I found a new information concerning this issue
(to complete my initial report).
I was about to report that MetronomeMark #'break-align-symbols fails
with key-signature, but then I remembered I already reported a similar
issue! :p
In the previous report I said MetronomeMark #'break-align-symbols did
align well on key-signature. This is not true.
Apparently it worked only because the key signature was changed
_at the same time_ as the tempo mark. If the key signature is set
before, MetronomeMark does not align on key-signature at a line break.
\score {
\new Staff {
\key e \major
\repeat unfold 8 c'1 \break
\override Score.MetronomeMark #'break-align-symbols = #'(key-signature)
\tempo "KeySignature does NOT works either"
\repeat unfold 8 c'1
}
}
So it appears MetronomeMark #'break-align-symbols fails with *every
object* except time-signature.
I hope this information is relevant (it would be great if that could
help solving this issue). :)
Thanks in advance.
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Manual page breaks
Looks like a valid bug report.
Fwd to bug- (it was originally sent to -user).
On 12 September 2011 22:08, Ed Gordijn wrote:
>
> Hi List,
>
> I am working on a piece with three movements. I organized my score in
> different files, for the tiny-example let's say two. The fist file is
> instrument.ly and the second part.lyi. I have different instruments and
> therefore multiple instrument.ly files but I want to use just a single
> part.lyi. So far nothing special. But I can't find a way to insert
> pagebreaks between the movements in my instrument.ly. I don't want fixed
> page breaks in part.lyi because of the differences in length of the
> instrument scores.
>
> In the tiny example I tried to get Movement I on the first page and Movement
> II and III together on a second page. But the \pageBreak is ignored.
>
> How does this work?
>
> Greetings, Ed
>
>
> %%% Tiny example %%%
>
> \version "2.15.10"
>
> % instrument.ly
> mvtI = { c'4 c' c' c' \pageBreak }
> mvtII = { d'4 d' d' d' }
> mvtIII = { e'4 e' e' e' }
>
>
> % part.lyi (identical for all instruments)
> \score {
>\new Staff { \mvtI }
>\header { piece = "Movement I"}
> }
>
> \score {
>\new Staff { \mvtII }
>\header { piece = "Movement II"}
> }
>
> \score {
>\new Staff { \mvtIII }
>\header { piece = "Movement III"}
> }
>
>
> ___
> lilypond-user mailing list
> lilypond-u...@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Whole measure rest is too narrow (compared to whole measure note)
On 8 September 2011 23:10, Reinhold Kainhofer wrote: > > 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! Yes, I got the same feedback from musicians. That's why I reported it and I currently use as a workaround \override MultiMeasureRest #'minimum-length 2011/9/8 Janek Warchoł : > > This was reported by Xavier Scheuer here > http://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg01260.html > And was added to tracker as issue 1798 > http://code.google.com/p/lilypond/issues/detail?id=1798 > Let's star it! :) Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: add a parameter/variable to control the spacing of lines in a score
2011/9/13 Janek Warchoł : > > I think it should be done by allowing system-system-spacing (and > friends) to be set either in paper or layout block, with appropriate > scope. I agree. "system-system-spacing" should be a "score" variable, so it would be possible to define different settings for different \score thanks to their respective \layout block. This enhancement request has also been formulated on the French users mailing list recently (it was on my todo list to report it back here). Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Mac OS 10.5 ppc & Lilypond?
On 13 September 2011 18:05, Stan Sanderson wrote: > > I'd really like to know if my trusty PowerBook G4, running OS 10.5.8, > is now fated to only run earlier versions of Lilypond. 2.15.11 won't > run; 2.15.8 does. > > This is a second post as a copy of the original never arrived in my mailbox. Messages you send to the mailing list are not "delivered back" to your inbox (this is a feature actually, you can change it in your options on https://lists.gnu.org/mailman/listinfo/lilypond-user IIRC). Fwd to bug- so it can be added to the tracker and eventually fixed. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
DynamicText attached to spacer rest not correctly aligned
Hello,
Since issue #620 is now fixed DynamicTextSpanner and Hairpin are now
correctly aligned when attached to spacer rests (e.g. in piano centered
dynamics).
It would be nice if DynamicText was also correctly aligned, which is
not the case now. I thought it was already reported but I cannot find
it on the tracker.
Here is a minimal example showing the difference of horizontal
alignment between dynamics attached to notes and attached to spacer
rests (within a Dynamics context).
Cheers,
Xavier
Snippet
\version "2.15.9"
\score {
<<
\new PianoStaff <<
\new Staff = "up" {
\clef treble
\relative c' {
c4\p c c\mp c |
c4\mf c c\f c |
<<
\repeat unfold 8 c4
\new Dynamics = "dynamics" \with {
alignBelowContext = "up"
} {
s4\p s s\mp s |
s4\mf s s\f s
}
>>
}
}
\new Staff = "down" {
\clef bass
\repeat unfold 16 c4
}
>>
>>
}
End of snippet
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bug: Either Midi output or pdf
On 5 August 2011 17:02, PaulvdM wrote:
>
> When I add
>\midi { \context { \Score tempoWholesPerMinute = #(ly:make-moment 56 2)
> } }
>
> to the score part, I only get a midi file (no pdf), when I comment that part
> I get the expected pdf
You need to add \layout { } within your \score block.
This is explained in NR 3.5.1 Creating MIDI files
If there is a \midi block in a \score with no \layout block, only
MIDI output will be produced. When notation is needed too, a
\layout block must also be present.
\score {
...music...
\midi { }
\layout { }
}
http://lilypond.org/doc/v2.14/Documentation/notation/creating-midi-files.html
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: No bar/ledger lines
On 5 August 2011 13:12, Raanan Elefant wrote: > > Arch Linux, i686 Another person is reporting the same problem, running Arch Linux too. It seems due to the Arch Linux package of LilyPond. If you install LilyPond using the script on lilypond website, is it OK? http://lilypond.org/unix.html Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: No bar/ledger lines
On 5 August 2011 05:23, Keith OHara wrote: > > What you posted is fine input, and LilyPond gives me good output. > > The attached file will probably display correctly on your system. > > If you have a PostScript viewer (ghostview, Adobe Acrobat, etc.) then put a > line in the input file > #(ly:set-option 'delete-intermediate-files #f) > and see if LilyPond produces a good .ps file. > Other than that, I can only suggest to simplify the input to isolate what > triggers the problem, and then post back here. The operating system would be a relevant information too. IIRC Windows XP SP1 causes some issues. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: suspended whole notes - possibly a defect, please give your opinions
2011/8/4 Janek Warchoł : > > Hi, > > I think there is a problem with handling suspended whole notes: Lily > aligns them as if they had stems. > > See attached "suspended whole notes" - in my opinion the last two > measures should look the same and have both chords in the same > horizontal position; also all measures should have the same length in > my opinion. > "suspended quarter notes for comparison" should provide some > explanation on this behaviour. > What do you think? What do engraving books say? (neither me nor > nearby music university don't have any) Hi, That has been registered as issue #1774, isn't it? http://code.google.com/p/lilypond/issues/detail?id=1774 Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Collision between voiceOne and voiceTwo, peculiar cautionary
On 3 August 2011 03:11, Frederick Dennis wrote:
>
> Dear All,
> In this code:
>
> \version "2.14.2"
> pianoOne = \relative c' { \voiceOne aes'4 g8 fis4 g8 }
> pianoTwo = \relative c' { \voiceTwo 4 8 4 f>8}
>
> \score {
> \new PianoStaff <<
> \new Staff = "RH"
> << { \pianoOne } \\ { \pianoTwo } >>
> >>
> }
>
> the cautionary accidental has been moved to the next chord
> and the f sharp is on top of the f natural. Is this a bug?
> Sorry, I forgot to edit the subject.
This is a known bug:
http://code.google.com/p/lilypond/issues/detail?id=1134
See comment 3 for a workaround.
To avoid the f natural on the next chord you can use
#(set-accidental-style 'voice) , although this is not a proper
solution.
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: [2.14.2] cadenzaOn makes [ ] behave like ( ) with regards to lyrics (regression vs 2.12)
2011/8/3 Frédéric Bron : > > In the following code, no word is placed below the second eight note. > Commenting \cadenzaOn or removing manual beaming [] works fine. > Manual beaming [ ] behaves like slur ( ). > This worked in previous versions. This is normal behaviour. \cadenzaOn contains \set Timing.autoBeaming = ##f (which was maybe not the case in 2.12). Manual beaming [ ] behaves like slur ( ) because of the melisma rules (which are based on common engraving practices), see NR 2.1.1 Common notation for vocal music > Multiple notes to one syllable Notes are considered a melisma if they are manually beamed, providing automatic beaming is switched off. http://lilypond.org/doc/v2.15/Documentation/notation/common-notation-for-vocal-music.html#multiple-notes-to-one-syllable Use \set melismaBusyProperties = #'() if you do not want these melismata. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Full measure rest should take more horizontal space
2011/7/31 Janek Warchoł : > > Wow, i'm CCed! Why? You are on my list as aesthetic guru (+ good engraving practices). And also because Gmail's "Consider including" feature suggested me to Cc you (and finally because it usually makes the person reply to the message, which is good in order to hear its opinions). > > […] > > I think i agree that full measure rest should take the same amount of > space as full measure note. :) On 31 July 2011 13:02, Phil Holmes wrote: > > Gould and Read both strongly imply that a WMR should take up the same space > as the equivalent note: we could discuss whether this is always a > semi-breve, or whether it represents the timed length of the note in other > time sigs than 4/4. Gould says "Position a rest exactly as if it were a > note of equivalent duration" [except] "the semi-breve rest is placed at the > visual centre of the bar". Read says "Written rests [..] are always given a > time-value: that is, the rest symbols merely substitute for a written note > value." Thank you Phil. Since it seems I'm not the only one to consider that Full measure rest should take more horizontal space (as much horizontal space as a note of the same duration), could someone open a new issue for this on the tracker? Thanks in advance. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Full measure rest should take more horizontal space
Hello,
In my everyday use of LilyPond I am often annoyed by the fact that
—especially in "tighter situations"— full measure rests take very
little horizontal space, hence their measure width are much more
*compressed* than neighbouring measures.
This results in IMHO poor output.
I do not know what "engraving references" say about the horizontal
_measure width_ in the case of "full measure rest" but I would have
expected a full measure rest to take as much horizontal space as the
corresponding-duration note (full measure-duration note).
Someone could confirm this?
Snippet
%% Full measure rest should take as much horizontal space as a note of
%% the same duration.
%% Currently the "whole rest" measure widths are smaller than
%% corresponding duration note and they are much more compressed in
%% "tighter situations".
%%
%% Note that the width of a full measure rest should adapt to its
%% duration, hence the solution of defining "minimum-length" is not
%% suitable for different time signatures. A full measure rest in
%% 2/4 should have a smaller width than a full measure rest in 4/4
%% because a whole takes much horizontal space than a half note.
%%
\version "2.15.7"
test = \relative c' {
c1
R1
c1
R1
\repeat unfold 2 c1
R1*2
\repeat unfold 2 c1
R1
\repeat unfold 2 c1
R1*2
\repeat unfold 2 c1
R1
c1
R1
c1
c1
}
\score {
\new Staff {
c'1^"current full bar rest width"
\test
}
}
\score {
\new Staff {
c'1^"new (expected) full bar rest width"
\test
}
\layout {
\context {
\Voice
\override MultiMeasureRest #'minimum-length = #8
}
}
}
End of snippet
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1724 -> 620 : workaround?
On 23 July 2011 22:27, Neil Puttock wrote: > > Here's the scheme engraver if you want to try it out. It's obviously > not as sophisticated as Mike's proposed fix, but it does have the > advantage of aligning absolute dynamics properly (assuming there's a > NoteColumn present at the same time). Thanks Neil! It works great. I'll use it as a workaround until Mike's fix is OK and pushed. Thank you Mike too. Good luck. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: lyrics misaligned when nested in a 2nd lyric line
On 22 July 2011 13:16, -Eluze wrote: > > indeed - this works! > > thanks! > Eluze > > ps: did you see my post from yesterday - it seems to appear on many lists > but not on nabble! Yes, I saw it. The same workaround should work there too, isn't it? I have not read in details the discussion on the French users mailing list, though. If you have specific questions, feel free to ask (although as I have already said I'm not really used to vocal music). Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: lyrics misaligned when nested in a 2nd lyric line
On 22 July 2011 11:59, -Eluze wrote:
>
> maybe this is related to issue 1621
> http://code.google.com/p/lilypond/issues/detail?can=1&q=1621
> where nested lyrics mishandle the alignment.
>
> but it's not exactly the same and i don't see a way to apply the workaround
> proposed there.
>
> here are the details:
>
> […]
>
> results in:
> http://old.nabble.com/file/p32114099/bug%2Blyrics%2Bw%2Brepeats%2Bsmall.png
>
> where the text of the 2nd line is left-aligned to the notes.
AFAICS the lyrics are correctly center-aligned if you add
[…]
\context Lyrics = "lyr2" {
\set associatedVoice = "melody"
Sec -- ond time words.
}
[…]
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1724 -> 620 : workaround?
[Sorry for late follow-up, I was on holiday. :-) ] Hi Neil, I see you merged issue 1724 : "DynamicTextSpanner inside Dynamics context are shifted due to pedal" into issue 620 : "It should be possible to specify more specific spanner bounds.". I was wondering if you (or someone else) would have maybe a workaround I could use in order to have a fairly good output for the code attached to #1724 ? http://code.google.com/p/lilypond/issues/detail?id=1724 Issue 1724 is really annoying for me since it totally demolish the advantages of using the Dynamics context. Yes, we have the dynamics correctly aligned vertically (i.e. centered between the two staves of PianoStaff) but due to issue 1724 (620) the DynamicText and DynamicTextSpanner are shifted left irregularly, which results in really bad horizontal alignment (-> poor output !). Any help would be greatly appreciated. Thanks in advance! Cheers, Xavier PS : Please note that since issue 620 has no lilypond code showing the consequences of this issue, it is difficult for a lambda user to understand it, hence IMHO the several duplicate report of this issue. -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Many single-system scores produces bad output and overflow
On 7 July 2011 15:13, Dmytro O. Redchuk wrote: > > Hi, Xavier! > > Sorry for so late reply, I've been flagged your message on Wed 06 Apr 2011, > actually .) > > Anyway: this is issue 1286: > http://code.google.com/p/lilypond/issues/detail?id=1286 > > Page breaking works fine when I replace all your "a"s with "a1". Thanks for the reply anyway! Yes, David Kastrup said somewhere it was due to incomplete bars because that’s what I reported back on the French users mailing list on Sat 09 Apr 2011. http://lists.gnu.org/archive/html/lilypond-user-fr/2011-04/msg00060.html Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
DynamicText inside Dynamics context not correctly aligned
Hello, I remember a discussion reporting that dynamics ( DynamicText ) inside a Dynamics context (i.e. attached to spacer rests) are not correctly aligned (they appear like right-aligned instead of centered). Unfortunately I can't find this discussion again and I cannot find an issue about it on the tracker either. Does someone recall this discussion? I'm actually looking for a workaround. \override DynamicText #'X-offset = #0 gives better results than the default output but now they appear more like left-aligned and \override DynamicText #'self-alignment-X = #CENTER does not change anything in this case. Any help would be appreciated. Thanks in advance! Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
DynamicTextSpanner collides with DynamicText
I'm surprised this issue seems not yet reported (at least I did not find
it on the tracker).
The example below is "extreme". I used 16th notes in order to show
clearly the issue. It happens in "real-life" scores with more logical
rhythm also.
Ideally LilyPond should avoid the collision (I do not know what would
be the proper way to do that). At least in the case where there is
a collision, LilyPond should emit a warning!
This issue might be related to issue #1089 .
%% DynamicTextSpanner collides with DynamicText if the notes are close
%% to each other.
%%
\relative c' {
c4..\p c16\cresc c4..\f c16\cresc
c1\ff
}
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
DynamicTextSpanner inside Dynamics context are shifted due to pedal
%% DynamicTextSpanner inside a Dynamics context are shifted to the left
%% if there is a Pedal inside another Dynamics context.
%% That leads to really poor output of the DynamicTextSpanner, which
%% are shifted left (compared to when they are well aligned without the
%% pedal) and so colliding with the bar line.
%%
%% This is really an issue for every piano score (using the Dynamics
%% context, i.e. centered dynamics and pedal on a horizontal line).
%%
\version "2.15.2"
\score {
<<
\new PianoStaff <<
\new Staff = "up" {
\clef treble
\repeat unfold 48 c'4
}
\new Dynamics = "dynamics" {
\repeat unfold 2 {
s1\cresc s1\f s1\dim s1\p
}
}
\new Staff = "down" {
\clef bass
\repeat unfold 48 c4
}
\new Dynamics= "pedal" {
\repeat unfold 4 {
% comment the pedal and the DynamicTextSpanner are well
% aligned in the Dynamics context above!
s1\sustainOn s1\sustainOff
}
}
>>
>>
}
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Partcombine: beaming
On 27 June 2011 22:48, Jean-Charles Malahieude wrote:
>
> Hello all,
>
> 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" :
I'm not an expert in partcombine but I have read many conversations and
that could be "normal". Partcombine assumes first combined voice should
be "voiceOne" and this non-combination when "first" is actually lower
than second is kind of a way of showing that "first" is actually playing
below "second" (as opposed to normally when they are combined second is
the lowest).
Anyway, you can change that by using \partcombineChords .
\version "2.14.1"
VlnI = \relative c'' {
\partcombineChords
a4. g8 f[ g a f]
}
VlnII = \relative c' {
f4. g8 a[ g f a]
}
\score {
\new Staff <<
\set Staff.printPartCombineTexts = ##f
\partcombine
\VlnI
\VlnII
>>
\layout { }
}
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Cross-staff beam unaesthetic (defect 2.12 -> 2.14)
On 20 June 2011 00:10, Keith OHara wrote:
>
> The default spacing between staves was reduced for version 2.14, to 9 staff-
> spaces from the center of one staff to the next.
>
> The method to increase it is a little awkward:
> \new PianoStaff \with {
>\override StaffGrouper
> #'staff-staff-spacing #'basic-distance = #10.5
> } <<
>
> Is 9 spaces too close to have as the default? I studied several piano scores
> before choosing 9, knowing that they staves spread as required for (most)
> collisions.
>
> Lilypond *will* spread the staves if the notes would otherwise force a more
> extreme beam (for example if you write do in place of mi). Maybe her maximum
> tolerance for high slopes is a little too tolerant?
Actually I do not know.
I'm not used to piano scores. I just noticed this "unaesthetism" while
helping someone on lilypond-user and in noticing that the output looked
better (IMHO) with 2.12 than with 2.14.
Then I spoke to mike who told me to report it.
You (Keith, Mike, etc.) are more "expert" than me!
Cheers,
Xavier
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Cross-staff beam unaesthetic (defect 2.12 -> 2.14)
The following code gives an unaesthetic beam slope with 2.14 (2.15)
whereas the result was good with 2.12 (see attachments).
2.14.1 (2.15.2) gives the following warning:
warning: no viable initial configuration found: may not find good
beam slope
\score {
\new PianoStaff <<
\new Staff = "up" {
\relative c' {
\stemDown cis8*2/3 \change Staff = "down" \stemUp fis, ais b cis d
\change Staff = "up" \stemDown e
\change Staff = "down" \stemUp eis fis
\change Staff = "up" \stemDown d' e cis
}
}
\new Staff = "down" {
\clef bass
s1
}
>>
}
Cheers,
Xavier
--
Xavier Scheuer
<><>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
