Re: Possible bug: Grace note at the beginning makes instrumentName disappear?

Hello Thomas, in your case using a with block is definitely the best option. One can also solve such issues by adding a skip column before the main beat like this \new Staff << {\set Staff.instrumentName = #"abc" \grace s} \new Voice \grace c c >> which can be useful with stuff like tempo in a

Re: Possible bug: Grace note at the beginning makes instrumentName disappear?

Thank you David for this lesson, I appreciate it a lot. Thomas > Am 16.02.2022 um 18:50 schrieb David Kastrup : > > Thomas Scharkowski writes: > >> Grace note at the beginning makes instrumentName disappear: >> macOs 12.1 >> LilyPond 2.23.6 >> >> -- >> \version "2.23.6" >> >> GraceVoice = \n

Re: Possible bug: Grace note at the beginning makes instrumentName disappear?

Thomas Scharkowski writes: > Grace note at the beginning makes instrumentName disappear: > macOs 12.1 > LilyPond 2.23.6 > > -- > \version "2.23.6" > > GraceVoice = \new Voice > { > \grace > c'8 b4 > } > > GraceStaff = \new Staff > << > \set Staff.instrumentName = "Grace" > \GraceVoice

Re: Possible bug: Grace note at the beginning makes instrumentName disappear?

Greetings Thomas, In the case of grace notes, the instrumentName must be placed in a \with block. GraceStaff = \new Staff \with { instrumentName = #"Grace" } << \GraceVoice >> Not sure if the curly and angled braces work exactly the same way, because I haven't done this with variables, but

Re: possible bug?

Hello Erik, As I said, this is not a solution but just a demonstration, and it abuses the Accidental grob to place the embellishment. This means you’ll need to force an Accidental on the embellished note by doing a!. @Lukas: As I said, this is just a demonstration, and it is doing very shady t

Re: possible bug?

Am 26.12.21 um 20:35 schrieb Valentin Petzel: Hello Erik, I think the behaviour you want is for some sort of embellishment which basically is handled similar to some sort of articulation. The appended file is in an extremely hacky demonstration of how one could implement something like, thoug

Re: possible bug?

Moser" > Aan: "E Appeldoorn" ; "lilypond-user@gnu.org" > > Verzonden: 25-12-2021 20:44:22 > Onderwerp: Re: possible bug? > > >And one addition: > >>I did try the options you then gave me. (context \score \override > >>SpacingSpanner.

Re: possible bug?

For what it's worth, strict-note-spacing et al. are known to have some quirks. The corresponding issues are https://gitlab.com/lilypond/lilypond/-/issues/2630 https://gitlab.com/lilypond/lilypond/-/issues/4493 https://gitlab.com/lilypond/lilypond/-/issues/4499 Regards, Jean

Re: possible bug?

Hi Erik, Just showing one other bar that looks suddenly awfull with strict spacing << \new Staff \relative c'' { es4-- r8   \tuplet 5/4 {f32([ ges as ges f)]}   es8^.[ \acciaccatura {a} bes^!] es,4-- | } >> Thanks, that really is not desirable. The \newSpacingSection command also introducing

Re: possible bug?

And one addition: I did try the options you then gave me. (context \score \override SpacingSpanner.strict-note-spacing = ##t and also \override Score.SpacingSpanner.strict-grace-spacing = ##t) The relationship between those two settings is not at all obvious from the documentation: https:/

Re: possible bug?

> On 25 Dec 2021, at 18:59, E Appeldoorn wrote: > > HI all and merry christmas > > A couple of weeks ago I had a question about a spacing problem I have in a > score. After many trials that did not solve anything I'm coming to the > conclusion that there might be a bug with the \appoggiatura

Re: possible bug?

What would be the correct way to engrave this? Space the 4 16ths evenly, put the two 8ths above their corresponding 16ths and squeezing the appoggiatura notes in? What if there's not enough place left for them - should the 16ths then be spaced further apart (evenly) until it fits? Even if th

Re: possible bug?

Hi Erik, Am 25.12.21 um 18:59 schrieb E Appeldoorn: I have created a complete bare minimum of a trial, one bar, two voices. While that's much closer to a minimal example than your previous examples, it's still far from being a bare minimum. That would be something like: \version "2.22" <<

Re: possible bug: putting accordion register symbol in title section leads to an error

Am So., 31. Jan. 2021 um 16:38 Uhr schrieb Davide Bonetti : > Thanks again (and sorry for the bad english) I'm not aware of any bad english, well, apart from my own ... Cheers, Harm

Re: possible bug: putting accordion register symbol in title section leads to an error

Thomas Morley writes: > Am So., 31. Jan. 2021 um 13:59 Uhr schrieb Davide Bonetti > : >> we know that accordion register symbols works as markup and also as a >> music function. >> >> One can put accordion symbols everywhere in a markup block, but if you >> try to put accordion symbol in a title

Re: possible bug: putting accordion register symbol in title section leads to an error

Thanks Harm for the workaround. As you pointed it works only putting #(use-modules (scm accreg)) in every header where is needed, so in a book with multiple scores it's a quite tedious. I think accordion registers is the only markup that need use-modules. Is there a way to get rid of use-modu

Re: possible bug: putting accordion register symbol in title section leads to an error

Am So., 31. Jan. 2021 um 13:59 Uhr schrieb Davide Bonetti : > > Hi! > > we know that accordion register symbols works as markup and also as a > music function. > > One can put accordion symbols everywhere in a markup block, but if you > try to put accordion symbol in a title section this leads to

Re: Possible bug with tempo mark spacing

Hi Malte, > That sounds like a really special case: MarkLine context AND hidden Staff AND > this staff contains notes (why is it hidden then?) AND Y-offset is set AND > extra-spacing-width is set … That "really special case" includes >50% of my choral writing, which comprises >50% of my compos

Re: Possible bug with tempo mark spacing

It's not that special of a case. Hiding a staff containing notes and using a MarkLine are normal techniques for managing a large ensemble score. >From property-init.ly: markLengthOn = { \override Score.MetronomeMark.extra-spacing-width = #'(0 . 1.0) \override Score.RehearsalMark.extra-spacing

Re: Possible bug with tempo mark spacing

Am 28.12.18 um 04:54 schrieb Saul Tobin: When using a context like MarkLine for tempo marks, if the staff immediately below the MarkLine is hidden but contains rhythmic activity, and if BOTH Y-offset and extra-spacing-width are overridden for MetronomeMark, the first rhythmic column will st

Re: possible bug?

Thank you so simple On 26 October 2017 14:55:40 BST, Pierre Perol-Schneider wrote: >Hi Peter, > >\override Beam.breakable = ##t > >should solve your problem. >See : >http://lilypond.org/doc/v2.19/Documentation/notation/writing-rhythms > >Cheers, >Pierre > >2017-10-26 11:43 GMT+02:00 : > >>

Re: possible bug?

You are on the right track! If you Google for "lilypond beam line break", you will quickly find the explanation and the solution: \override Beam.breakable = ##t    /Mats On 2017-10-26 12:10, peter.gen...@sunscales.co.uk wrote: Is it me ? The following script when run via Frescobaldi produc

Re: possible bug?

Hi Peter, \override Beam.breakable = ##t should solve your problem. See : http://lilypond.org/doc/v2.19/Documentation/notation/writing-rhythms Cheers, Pierre 2017-10-26 11:43 GMT+02:00 : > Is it me ? > > > > The following script when run via Frescobaldi produces correct notation > but does not

Re: Possible bug, attempting to use non-latin characters in verse

On 26/05/2015 17:31, Colin Jesse Kinlund wrote: \version "2.18.2" firstVoice = \lyricmode { I -- av -- na -- na, } pirveliEkhma = \lyricmode { ი -- ავ -- ნა -- ნა, } melody = \relative c'' { \time 5/4 c4 d e e8( d4.)} \score { \new ChoirStaff << \new Voice = "pirveli" { \melody } \new Lyrics

Re: Possible bug, attempting to use non-latin characters in verse

2015-05-26 12:36 GMT+02:00 Michael Gerdau : > Hi Colin, > > after replacing \lyricsto "melody" with \lyricsto "pirveli" this worked Argh, sure, I forgot to mention this in my previous mail > for me under 2.19.20 running on ArchLinux. > > Not sure what the problem is but I have a few small example

Re: Possible bug, attempting to use non-latin characters in verse

Hi Colin, after replacing \lyricsto "melody" with \lyricsto "pirveli" this worked for me under 2.19.20 running on ArchLinux. Not sure what the problem is but I have a few small examples that work nicely under Linux and create problems on both Windows 8.1 and OS X 10.10.3 Best wishes, Michael --

Re: Possible bug, attempting to use non-latin characters in verse

2015-05-26 9:31 GMT+02:00 Colin Jesse Kinlund : > Hi LilyPonders, I have a possible bug I’m trying to work around/figure out. > I have a number of Georgian songs where I’ve set a latin transliteration as > “verse 1” and the Georgian alphabet for “verse 2”. > With Lilypond 2.18.2 (or 2.19.20) on OS

Re: Possible Bug with \partcombine?

Joshua Nichols gmail.com> writes: > Is there talk about improving this feature? Yes. Someone recently gave \partcombine an option to double-stem unisons http://code.google.com/p/lilypond/issues/detail?id=4112 The example at the top of this follow-up might make more sense http://code.google.com

Re: Possible Bug with \partcombine?

> The simplest solution here is to keep the voices separate through the slurs... Thanks, this is helpful. Is there talk about improving this feature? Or do you know of a hack for getting the desired output? Your solution will be a solid work around from here on out. Thanks. Josh __

Re: Possible Bug with \partcombine?

Joshua Nichols gmail.com> writes: > I was recently typesetting a song, using part combine, from a hymnal. I ran into a problem: everytime I ran \partcombine, I found that "unterminated slur" and "cannot end slur," were common warnings. I was confused, and so I created this small snippet that s

Re: possible bug: \change Staff and beam collision

Hi Keith, Thanks for the detailed explanation, I think I understand the situation well now. Keith OHara wrote > I have no better suggestion. The manual tweak is simple, though, > \once\override Staff.OttavaBracket.staff-padding = #6 Thanks anyway. Unfortunately my case of avoiding manual twe

Re: possible bug: \change Staff and beam collision

Gilberto Agostinho gmail.com> writes: > but when changing staff the ottava position > gets lower (!) and collides with the beam. LilyPond allows you to beam to any other staff, so in general that beam might have to go up and cross the ottava bracket, while the bracket must stay with the staff.

Re: possible bug: \change Staff and beam collision

Hi Mike, Thanks for your reply. Mike Solomon wrote > This is a persistent issue in LilyPond development - there was some work > on it in course a couple years ago that has since been put on hold but I > hope to pick it back up one day. I totally understand it. Mike Solomon wrote > I know that

Re: possible bug: \change Staff and beam collision

> On Nov 2, 2014, at 8:40 PM, Gilberto Agostinho > wrote: > > Hello all, > > Please have a look on the following code: > > \version "2.19.15" > > \new PianoStaff << > \new Staff = up { > \override Score.Beam.damping = 3 > \stemUp a'8 > \ottava #1 a''' > \ottava #0 a' > a, > } > \new S

Re: possible bug: \change Staff and beam collision

> On Nov 2, 2014, at 8:40 PM, Gilberto Agostinho > wrote: > > Hello all, > > Please have a look on the following code: > > \version "2.19.15" > > \new PianoStaff << > \new Staff = up { > \override Score.Beam.damping = 3 > \stemUp a'8 > \ottava #1 a''' > \ottava #0 a' > a, > } > \

Re: possible bug: \change Staff and beam collision

> On Nov 2, 2014, at 8:40 PM, Gilberto Agostinho > wrote: > > Hello all, > > Please have a look on the following code: > > \version "2.19.15" > > \new PianoStaff << > \new Staff = up { >\override Score.Beam.damping = 3 >\stemUp a'8 >\ottava #1 a''' >\ottava #0 a' >a, >

Re: Possible Bug with \numericTimeSignature

Keith OHara writes: > Joshua Nichols gmail.com> writes: > >> global = { >> \key c \major >> \numericTimeSignature > > It is a bug, but you can fix this one yourself if you like. > > In 'property-init.ly' the definition is > numericTimeSignature = \override Staff.TimeSignature.style = #'numbe

Re: Possible Bug with \numericTimeSignature

Am 13.05.2014 04:56, schrieb Keith OHara: Whenever you write a grace note in LilyPond, you need grace n Fortunately that's not _whenever_ but only in situations at events like time signature (changes). Urs ___ lilypond-user mailing list lilypond-u

Re: Possible Bug with \numericTimeSignature

Joshua Nichols gmail.com> writes: > I've never experienced this before now... Oops, I just realized you mean the grace-note bug. Whenever you write a grace note in LilyPond, you need grace notes or skips of the same duration in every other staff. So here in the upper staff you need \grace {s8}

Re: Possible Bug with \numericTimeSignature

Joshua Nichols gmail.com> writes: > global = { > \key c \major > \numericTimeSignature It is a bug, but you can fix this one yourself if you like. In 'property-init.ly' the definition is numericTimeSignature = \override Staff.TimeSignature.style = #'numbered but we want it to apply to the e

Re: Possible bug: grace note/piano staff/repeat

Wow, i ran into a good one my first try! Thanks for the replies. Yes, can see a little bit of the slur from the silent grace note, but it's a work around. Knute Snortum (via Gmail) On Tue, Apr 22, 2014 at 11:57 AM, Urs Liska wrote: > Am 22.04.2014 20:38, schrieb Paul Morris: > > Urs Liska

Re: Possible bug: grace note/piano staff/repeat

Am 22.04.2014 20:38, schrieb Paul Morris: Urs Liska wrote This is what I wanted to suggest too, but this will leave an ugly slur fragment (see attached image) in the upper voice. Clicking on that (point-and-click) will lead to startAcciaccaturaMusic in grace-init.ly Anyone know how to remove

Re: Possible bug: grace note/piano staff/repeat

Urs Liska wrote > This is what I wanted to suggest too, but this will leave an ugly slur > fragment (see attached image) in the upper voice. > Clicking on that (point-and-click) will lead to > > startAcciaccaturaMusic > > in grace-init.ly > > Anyone know how to remove this too? Good point! It

Re: Possible bug: grace note/piano staff/repeat

Ah, the old and notorious "grace synchronization" bug: https://code.google.com/p/lilypond/issues/detail?id=34 The workaround is to insert a corresponding spacer in the other part. In your example, that would look like this: \acciaccatura s8 c4 c c c HTH, -Paul -- View this message in contex

Re: Possible bug: grace note/piano staff/repeat

Am 22.04.2014 20:25, schrieb Robert Schmaus: Hi Knute, that's an old lilypond issue - actually, this came up already just a couple of days ago, and someone described it in that thread as the "most persistent lilypond bug". So anyway, the way to fix this is simple: put (empty) grace notes in *all

Re: Possible bug: grace note/piano staff/repeat

Hi Knute, that's an old lilypond issue - actually, this came up already just a couple of days ago, and someone described it in that thread as the "most persistent lilypond bug". So anyway, the way to fix this is simple: put (empty) grace notes in *all* voices at the same spot your "real" grace

Re: Possible bug: grace note/piano staff/repeat

Am 22.04.2014 20:15, schrieb Knute Snortum: I may have found a bug in LilyPond 2.18.2 but since I'm new to typesetting I want to run it past the list first. I think this is http://code.google.com/p/lilypond/issues/detail?id=34 the probably oldest and most annoying bug in the pond ;-) HTH, M

Re: Re Possible bug with volta repeat (Peter Gentry)

On Mon, 2014-02-10 at 16:44 +, Peter Gentry wrote: > A similar issue is seen when the grace appears in a bar following \bar "||" > in the parts. It's a bit of a fag well, you could always use Denemo to create your LilyPond - it will insert the s's for you when you do Check Score ... after all

Re Possible bug with volta repeat (Peter Gentry)

A similar issue is seen when the grace appears in a bar following \bar "||" in the parts. It's a bit of a fag having to insert bits of s's into multiple parts - I'm inclined just to forget the grace (along with the performers!). regards Peter Gentry __

Re: Possible bug with volta repeat

On 02/10/2014 04:47 PM, Peter Gentry wrote: The issue is when grace notes [...] The magic word... I haven't found this in the list of bugs afetr a search. Yet another incarnation of . Also see

RE: Possible bug with volta repeat

Thanks to all who replied. >-Original Message- >From: Alexander Kobel [mailto:n...@a-kobel.de] > >Yet another incarnation of >. Also >see >al-rhythmic-concerns#Known

Re: Possible bug with volta repeat

- Original Message - From: "Peter Gentry" To: Sent: Monday, February 10, 2014 3:47 PM Subject: Possible bug with volta repeat I haven't found this in the list of bugs afetr a search. regards Peter Gentry It's our most famous and oldest outstanding bug: http://code.google.com/p/l

RE: Possible bug with volta repeat

Peter, I ran into this for piano score. The solution works here also (I tried it). Insert "\grace { s8 s s } " at the beginning of the first alternative for the upper voice. Mark -Original Message- From: lilypond-user-bounces+carsonmark=ca.rr@gnu.org [mailto:lilypond-user-bounces+car

Re: Possible bug with TrillSpanner.to-barline?

Daniel Rosen writes: >> -Original Message- >> From: Eluze [mailto:elu...@gmail.com] >> >> try it in the Staff context: >> >> \override Staff.TrillSpanner.to-barline = ##t >> >> Eluze > > Well, that did the trick. A couple things about this are interesting > to me, though. > > First of a

RE: Possible bug with TrillSpanner.to-barline?

> -Original Message- > From: Eluze [mailto:elu...@gmail.com] > Sent: Thursday, December 26, 2013 5:22 PM > To: Daniel Rosen; lilypond-user@gnu.org > Subject: Re: Possible bug with TrillSpanner.to-barline? > > > Am 26.12.2013 22:22, schrieb Daniel Rosen:

Re: Possible bug with TrillSpanner.to-barline?

Am 26.12.2013 22:22, schrieb Daniel Rosen: In the example below, uncommenting the indicated line results in the TrillSpanner only printing the wavy line without the "tr." Is this a bug? \version "2.17.97" trillSharpMarkup = \markup { \concat { \musicglyph #"scripts.trill" \hspace #0.4 \rai

Re: Possible bug? Commenting out section causes EOF

ryanmichaelmcclure writes: > I am working on a multi-part piece. I have all of my parts in one .ly file. > So, when I want to work on just one, I comment out all other parts using %{ > %} However, when I go to engrave, I get an error that reads > > /home/ryanmcclure/Compositions/Transcriptions/

Re: Possible bug? Commenting out section causes EOF

/facepalm/ I forgot to uncomment at the end of the document so that \book { could be closed. Please disregard these emails :P PS--To all of those who are reading this, thank you for all of the help you've given me during my LilyPond learning process! It is appreciated more than you could ever kno

Re: possible bug with tupletSpannerDuration in quoted music

Hello, On 5 February 2012 21:24, Shevek wrote: > > In 2.14, tupletSpannerDuration doesn't get properly applied to quoted music > unless tupletSpannerDuration is set in the quoted music itself. Bug, or am I > doing something wrong? Possibly, See: http://lilypond.org/doc/v2.14/Documentation/nota

Re: possible bug with tupletSpannerDuration in quoted music

Shevek writes: > In 2.14, tupletSpannerDuration doesn't get properly applied to quoted > music unless tupletSpannerDuration is set in the quoted music > itself. Bug, or am I doing something wrong? More likely "peculiarity" than "bug" though I have not analyzed your example in detail. Quoted mus

Re: Possible bug with multiple voices, slurup and rests?

Hi all, I seem to be having trouble with rest alignment. The specific case I have is pretty specific: 1. I have a multiple-voice section 2. I have /slurUp 3. I have a rest, with no rests before this point In this case, the rest seems to still be high rather than centered, as if another voice

Re: Possible bug with multiple voices, slurup and rests?

Hi Harm, Thomas Morley googlemail.com> writes: > > Hi David, > > don't know, whether it's abug or not, but try: > > \version "2.14.2" > { > % no! Problem here > << { f' e' g' g' } \\ { e' d' d' d' } >> \oneVoice \slurUp d' r4 > } > > HTH, > Harm > This looks like it fixes my issue. Tha

Re: Possible bug with multiple voices, slurup and rests?

Hi David, 2012/1/17 David Liu : > Hi all, > > I seem to be having trouble with rest alignment. The specific case I have is > pretty specific: > > 1. I have a multiple-voice section > 2. I have /slurUp > 3. I have a rest, with no rests before this point > > In this case, the rest seems to still be

Re: possible bug, 2.13.60

- Original Message - From: "Stan Sanderson" To: "lilypond-user Mailinglist" Sent: Thursday, April 21, 2011 5:27 PM Subject: possible bug, 2.13.60 I was updating a score from 2.13.52 and found a problem. \header { texidoc = "beaming problem" reportedin = "2.13.60" } \version "2.13.6

Re: Possible bug in lyrics mode

FYI: Added to the issue tracker: http://code.google.com/p/lilypond/issues/detail?id=1188 Best Urs Am 13.07.2010 16:48, schrieb Arle Lommel: Hi all, Just thought I'd mention something I believe to be a bug in lyrics mode, but thought I'd ask if there is a rationale for it before I submit. I f

Re: Possible bug in lyrics mode

I’ve gone ahead and submitted the lyric mode spacing issue to the gmane lilypond bugs list. This is the first time I've submitted a bug and as I look at the other postings, so I'll ask here if I need to do anything beyond posting it there to get the bug actually listed?For what it's worth, I've cre

Re: Possible bug in lyrics mode

On Tue, Jul 13, 2010 at 11:07 AM, Alexander Kobel wrote: > On 2010-07-13 16:48, Arle Lommel wrote: > > Line height for lyrics (at least in 2.13.24) is determined by the >> postscript bounding box for the characters in the line (or at least >> that's what it seems), *not* the em-square, which is

Re: Possible bug in lyrics mode

On 2010-07-13 16:48, Arle Lommel wrote: Line height for lyrics (at least in 2.13.24) is determined by the postscript bounding box for the characters in the line (or at least that's what it seems), *not* the em-square, which is the basic unit for almost all typographic measurements. This means th

Re: Possible bug

2009/9/12 Jonathan Wilkes : > 1) Maybe related to issue 675: I notice if I have something like \f\> and > I don't end the dimenuendo with a \!, the diminuendo isn't shown, and the > \f disappears.  But there's no error or warning output by Lilypond. This has just been fixed in the development ver

Re: Possible bug? - "indent" differs for header and body markups

Alexander Kobel wrote: Hi, all, perhaps it's a bug; I'm not convinced yet, but surely irritated. The header markups (title and tagline) in the attached example have an additional X-offset of about the width of a usual space, both compared to the staff lines and the normal "book body" markups

Re: Possible bug

On Saturday 22 February 2003 21.50, Beldon Dominello wrote: > I have a piece of music which is in 12/8 time. For the sake of clarity, > the phrase I am trying to score consists of an eigth note f' tied to a > quarter note f' followed by an eigth note g' tied to a dotted quarter g'. > This whole p

Re: possible bug in 1.6.4

Kirk Howe wrote: > and everything else works correctly. Well, I took a look at the output and noticed that many of your beams are horizontal even though one clearly would expect them to go upwards. The problem is examples like \score { \notes \relative c'' { [c8 d e d' g, a b c]

Re: Possible bug.

Hello, JR> This is the first ever score I have tried in lilypond. Cool program by the JR> way. The very last note causes some problems if it is dotted. The output is JR> Interpreting music...[8][16][24]programming error: Skipped something ?! JR> (Continu JR> ing; cross thumbs). JR> The output is

Re: Possible bug.

I haven't put triplets in ptfilter.sed yet because I'm doing something else now, but you shouldn't find it difficult to do exactly what you want with simple substitution. Probably you don't want to use the backslash though. You could, but it's confusing and you would have to make sure that there

Re: Possible bug.

On Fri, 30 Aug 2002 11:40:57 +1200 Jonathan Rosanowski <[EMAIL PROTECTED]> wrote: > Interpreting music...[8][16][24]programming error: Skipped something ?! > (Continu > ing; cross thumbs). One little note: you should specify what version of Lily and what OS you're running. I can confirm that thi