Repeat bar line do not show in polymetric music

I'm not top posting. I am working with some polymetric music (i.e., different time signatures for individual instruments), and to do so I am using the following snippet: \layout { \context { \Score \remove Timing_translator \remove Time_signature_engraver \remove

Re: Two possible bugs when dealing with Automatic note splitting

Thanks a lot, guys. Since I work with algorithm composition, the option to split notes is very handy to me. Please let me know if I can be of any help with this bug. Regards, Gilberto On Wed, Oct 2, 2013 at 7:17 PM, David Kastrup d...@gnu.org wrote: Phil Holmes m...@philholmes.net writes:

Two possible ugly bugs

Here are two possible little bugs (of type ugly) that do not look well IMO. If you give me green light, I would happily add them to our Issue Tracker myself. 1) Some ugly positioning when using \pitchedTrill: \version 2.17.29 \markup {Everything is fine here} { \pitchedTrill

Re: Two possible ugly bugs

Hi Phil, Thanks for your reply. As I am new to bug reporting, I sometimes still get confused about it (all my other reports have been filled by others after I posted them in the User forum, or someone directly asked me to post something at the bug tracker). I will always report bugs via the gmane

Re: Two possible ugly bugs

Hi Keith, Thanks for your reply, for the workarounds and for the report. Also, I totally understand your point concerning my 2) Take care, Gilberto -- View this message in context: http://lilypond.1069038.n5.nabble.com/Two-possible-ugly-bugs-tp152775p152858.html Sent from the Bugs mailing

beams look ugly when using \autochange

When using \autochange, the slope of the beams look ugly against the staff lines: \version 2.17.29 \markup { When using autochange:} \markup { Not perfectly horizontal beams, conflicting with staff lines} \new PianoStaff { \autochange \relative c' { \time 2/4 gis16 c,,32 e'' f cis, d16

Re: beams look ugly when using \autochange

Indeed this seems to be a problem with any staff changes. So does this qualify as a bug? I personally think it doesn't look right at all, and to manually tweak every single beam is a headache... Best, Gilberto -- View this message in context:

Re: beams look ugly when using \autochange

So does anyone else agrees that this problem here should be added to the Issue Tracker? If so, could someone who has the permission to do so please add it there? Thanks a lot! Gilberto -- View this message in context:

grace notes and autochange

Hello, I believe I found a bug while using grace notes with \autochange. If a work start with any type of grace note, then they are not affected by the \autochange algorithm. However, if a work start with a note, rest, full measure rest or invisible rest, then all grace notes will behave as

Re: grace notes and autochange

Hi Colin, Thanks for your reply. Colin Campbell-8 wrote This behaviour may well be implied by the wording in NR 1.2.6 Special Rhythmic Concerns, and particularly the Known Issues under Grace Notes That's interesting, I didn't realize these two behaviors could be connected. Colin

Re: beams look ugly when using \autochange

Hello, Gilberto Agostinho wrote When using \autochange, the slope of the beams look ugly against the staff lines Gilberto Agostinho wrote [...] this seems to be a problem with any staff changes. So does this qualify as a bug? I personally think it doesn't look right at all

makeCluster behaves strangely with repeated notes

When more than two notes are repeated, makeCluster creates some strange shapes. To observe that, it's necessary to reduce the ClusterSpanner.padding. See: \version 2.19.15 % all fine with single note repetitions \makeClusters { \override ClusterSpanner.padding = #'-0.25 c'1 c' } % all

Re: makeCluster behaves strangely with repeated notes

://lilypond.1069038.n5.nabble.com/offseting-makeCluster-td177973.html ) Best, Gilberto On 18/06/15 19:27, Simon Albrecht wrote: Am 18.06.2015 um 17:06 schrieb Gilberto Agostinho: % strange behaviour when more than 2 notes are repeated \makeClusters { \override ClusterSpanner.padding = #'-0.25

[feature request]: set grace note duration for MIDI playback

Currently, the MIDI output from LilyPond uses a hard coded value to calculate the duration for the grace notes (1/4 of their duration according to the documentation or 9/40 according to David Kastrup). It would be really nice to allow the users to set this proportion themselves, since

three small bugs

Hello, I would like to report three small bugs I found: - no. 1: when two parts contain manual beams and slurs at the same point and one uses \partcombine, some warnings are outputs in the console: "unterminated beam" and "unterminated slur". It does output the music correctly though. I

Re: partcombine problem with double explicit beams and slurs [was: Re: three small bugs]

Thanks a lot. -- View this message in context: http://lilypond.1069038.n5.nabble.com/three-small-bugs-tp182794p182984.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org

Re: bug report: partcombine and multi-measure rests

Hi Simon > there’s no point in discussing off-list. My bad, I hit the wrong button. Just for the sake of having the conversation registered in the list, I am copying my previous message to the bottom of this one. >> The output is ambiguous > It is inconsistent Yes, inconsistent is a much

bug report: partcombine and multi-measure rests

Hello all, I get strange results when I change the type of \partcombine (for instance, using \partcombineApart) when one of the parts is in the middle of a several bars long multi-measure rest: http://lilypond.1069038.n5.nabble.com/file/n182372/39.png code:

Re: bug report: partcombine and multi-measure rests

ce is silent. Yours, Simon On 14.10.2015 21:15, Gilberto Agostinho wrote: Hello all, I get strange results when I change the type of \partcombine (for instance, using \partcombineApart) when one of the parts is in the middle of a several bars long multi-measure rest: http://lilypond.1069038.n5.na

\autochange bug

Hello list, Here is a bizarre little bug I came across today: for some reason, an invisible rest on a different Staff seems to affect the kneed beamed stems on a PianoStaff when using \autochange. See: \version "2.19.28" A = { c'''16[ c''' c''' c] } B = {s4\p} C = {r4\p} << \new

Kneed beam and subdivisions

Hello bug squad, I would like to report a "ugly" type of bug. When using kneed beams, LilyPond does not set a "main beam" around which all subdivisions are created. The result is not only extremely confusing in some cases, but also absolutely non-standard. For instance, the code below:

Re: Kneed beam and subdivisions

Hi all, In the file lily/beam.cc, lines 231-232, we find the following comment: > We want a maximal number of shared beams, but if there is choice, we > take the one that is closest to the end of the stem. I believe the maximal number of shared beams is indeed necessary, but the problem is to

Re: MIDI dynamic bug

A follow up: it turns out any \override Score.* or \override Staff.* on the top of the variable A will cause the bug to appear. On the other hand if a \tempo indication comes before those \override commands then the playback is normal. -- View this message in context:

MIDI dynamic bug

Dear bug squad, Today I found a bug related to MIDI playback. If I use set the TimeSignature's stencil to false in the following way below, the first dynamic is ignored. Commenting out that override produces the correct result. This affects only the very first note of the playback, all

Re: Kneed beam and subdivisions

Thanks a lot, I really appreciate it, Simon. Take care, Gilberto -- View this message in context: http://lilypond.1069038.n5.nabble.com/Kneed-beam-and-subdivisions-tp184473p184571.html Sent from the Bugs mailing list archive at Nabble.com. ___

Noteheads slightly too large

Hi bug squad, This one is really nitpicking, but by zooming in on a note located in between two staff lines, we can notice that the noteheads always extend a little tiny bit beyond the top staff. See: Elaine Gould, in her book /Behind

Re: Noteheads slightly too large

Hi Urs, Urs Liska wrote > Are you completely sure that the issue is in LilyPond's output and not in > the displaying program? Well, I don't know how can I be *completely* sure about it, but I see this issue on Evince and Okular pdf readers, as well as in Frescobaldi. If you have some suggestion

Re: Noteheads slightly too large

Hi Schneidy, Schneidy wrote > Here's a workaround That doesn't seem to work for me, I still get the noteheads creeping out the staff lines, and if I lower the magnification value more (like 0.98 or less) the noteheads suddenly get *much* smaller, leaving a hole in between them and the staff

Re: Noteheads slightly too large

Hi Simon, Simon Albrecht-2 wrote > You might try > other backends (SVG, PNG), else the best way of testing is printing it > on paper. So I tried this: #(set-global-staff-size 90) { c' d' e' f' } Then exported a png via Frescobaldi using resolution 1200 and in Publish mode, and here is a

Re: Noteheads slightly too large

Hi Paul, Paul Morris wrote > Interesting... Here’s some code for experimenting with this. It scales > notehead stencils. A scaling of 250/276 should make the solid notes equal > to one staff-space. (Or should it be 275/276 to make it the "distance > between the bottom of a staff line to the

Re: Kneed beam and subdivisions

Gilberto Agostinho wrote > I also would like to offer a small bounty to get this fixed: I can pay 30 > EUR to anyone who is able to fix this until February 2016. I know that > giving a deadline for a bounty isn't really the most elegant thing to do, > but this issue is greatly affect

arpeggio

Hello, When using arpeggios in chords with too many accidentals, the arpeggio is often pushed far back, sometimes so far it comes to the previous bar and collides with previous notes. E.g.: \version "2.19.32" { R1 r4 4\arpeggio r2 f4 f f f r4 4\arpeggio r2 } producing:

MIDI dynamic marking playback

Hello bug squad, I found a possible bug with the MIDI output. If the dynamics are in a separate variable than the notes, the first dynamic will be ignored unless the very first command is a \tempo command. E.g.: A = { % \accidentalStyle dodecaphonic-no-repeat % \numericTimeSignature

dodecaphonic-no-repeat and mid bar breaks

Hello bug squad, When using the accidental style dodecaphonic-no-repeat, the accidental of repeated notes aren't restated unless there is a bar line in between them. The problem I found is that when using a mid bar break (by using the command \bar "" \break in the middle of a bar), the

tuplets and accidentals collision

Hello all, I am noticing quite a lot of collisions between accidentals and tuplet brackets+numbers in the composition I am currently engraving. It seems that for some reason LilyPond is ignoring accidentals when deciding the position of the tuplet brackets. Example: \version "2.19.37"

Re: tuplets and accidentals collision

Hi Carl, Carl Sorensen-3 wrote > Why do you think issue 3766 is different from your observation? Both are > a collision between the tuplet bracket and the accidentals. I thought it could be a different issue because the minimal example in that bug report requires the tuplet bracket position

tuplet bracket maximum slope

Hi all, LilyPond's tuplet bracket algorithm seems to not have a specific maximum slope for its brackets, and can produce things like this: \version "2.19.37" { \tuplet 5/4 { 16 d'4 } \tuplet 5/4 { 16 d'4 } \tuplet 5/4 { 16 d'4 } \tuplet 5/4 {

Re: tuplet bracket maximum slope

Thanks a lot, James! (and I just realized I could have left a comment there myself... sorry for the trouble) Take care! Gilberto -- View this message in context: http://lilypond.1069038.n5.nabble.com/tuplet-bracket-maximum-slope-tp192503p192553.html Sent from the Bugs mailing list archive

Re: tuplet bracket maximum slope

Hi James, James Lowe wrote > I have created https://sourceforge.net/p/testlilyissues/issues/4928/ for > this enhancement request. Thanks a lot for that! But if I may ask something else, I noticed that the link for the second image is broken for some reason. This link here work fine:

dodecaphonic-no-repeat and missing accidentals

Hello all, The accidental style dodecaphonic-no-repeat should output accidentals similarly to the dodecaphonic style (i.e. accidentals to every single note) except when dealing immediate repetitions (e.g. only the first note in {cis'4 cis' cis' cis'} would get an accidental). But when one starts

Re: dodecaphonic-no-repeat and missing accidentals

Hi Simon, First of all, thanks for your reply! >> I don't think this behaviour is correct, as it leads to a very >> confusing output. > That’s quite flawed logics – whether or not you find it confusing > doesn’t have anything to do with it being correct or not. Yes, I express myself very

flag and notehead collision with certain chords

Hello all, Recently I realized that some eighth note chords have their flags either too close to the noteheads or sometimes even colliding with them. Below is a code to show that (collisions are marked with an asterisk). See: Producing:

cross staff chords do not automatically hide non-default flags

Hello Bug Squad, I believe I found a bug with the cross staff chords sharing a single stem. When using different flag stencils other than the default one, such as #modern-straight-flag, #old-straight-flag and #flat-flag, the flags are not automatically hidden and require an extra \once \hide

Re: flag and notehead collision with certain chords

Hi Simon, I think part of the problem is that the amount of collision is not even constant for the cases above. Compare the very bottom system on the image I posted, note how the flag barely touches the bottom note a' but completely collides with the bottom e'. > At least you’d have to give

Re: flag and notehead collision with certain chords

Hi all, thanks for the replies! @Noeck > I am pretty sure that I read that this is done on purpose, that the flag > can touch the note head and that the distance of the elements of a 16th, > 32nd, etc. flag are derived from the distance of staff lines. I personally think there is a difference

Re: Grace notes obscure ledger lines

Hi Graham, Graham Percival-3 wrote > Sorry for the delay, and thanks for the report! It has been added > as: https://sourceforge.net/p/testlilyissues/issues/5020/ Thanks a lot, I appreciate it! Cheers, Gilberto -- View this message in context:

Grace notes obscure ledger lines

Hello all, I believe there is a issue with the way LilyPond handles grace notes on ledger lines. As far as I know, ledger lines should be always visible and nothing must block them (beams, slurs, slashes, etc.). LilyPond does that automatically for regular notes, but the beams and slashes of

Re: flag position problems with flat-flag style

Hi Torsten, Sorry to disturb you but I noticed that the length of the stems in beamed notes changed considerably after I used your suggestion below, they are now much taller than before: Torsten Hämmerle wrote > The modified Stem details are: > > \override Stem.details = #'((lengths 3.5 3.5

Re: flag position problems with flat-flag style

Hi all, Thanks for all your replies. David Kastrup wrote > You don't _need_ to override the whole list. You could just override > single properties from it. You are of course right, David, I can just use: \override Stem.details.lengths = #'(3.5 3.5 3.5 4.5 5.0 6.0) Thanks for the tip.

Re: flag position problems with flat-flag style

Hi Torsten, Thanks a lot for your message and apologies for my late reply, for some reason I did not receive a notification that someone had replied to my post. Also, thank you very much for the modified Stem details, that indeed does the trick. I will add that to all my scores. Torsten

Re: flag position problems with flat-flag style

Hi Torsten, Thanks a lot for your message and apologies for my late reply, for some reason I did not receive a notification that someone had replied to my post. Also, thank you very much for the modified Stem details, that indeed does the trick. I will add that to all my scores. > There is no

flag position problems with flat-flag style

Hi all, I noticed that some of the 32nd-note flags in the flat-flag style seem to have a layout problem. The flat flags should always match the staff lines (just like beams do), but in a few cases they are located in between the staff lines, which looks quite bad. See the minimal example below

articulations above ledger lines

Hi all, According to Elaine Gould's /Behind Bars/, articulations should not obscure ledger lines. I believe this is quite justifiable as though we want them as close as possible to the note heads for quick recognition, they make pitch identification much more difficult when many ledger lines

issues with musicxml2ly

Hello bug-squad, I ran into three issues when converting a .musicxml file generated with MuseScore into LilyPond: 1) the .ly file outut by musicxml2ly seems to have a weird encoding and outputs an error. There are many hidden characters which I had to remove manually in order to compile

Re: issues with musicxml2ly

Just a small follow up, I forgot to mention that I my musicxml2ly version is 2.19.82. I am also attaching a .musicxml file generated by MuseScore and the .ly file generated by musicxml2ly. The .ly file does not compile and has the hidden characters and strange enconding I mentioned. test.musicxml

Re: issues with musicxml2ly

Hi Knut, Thanks a lot for your reply. I use Linux Mint 18.3, 64-bit, and my LilyPond is version 2.19.82. The default python interpreter in my installation is 2.7.12, which I think is what came with my Linux Mint 18.3 (I believe I've never bothered trying to update it since I do all my Python

Re: issues with musicxml2ly

Hi Knut, You did not answer the question if you used one of the installers from lilypond.org or if you compiled lilypond. My apologies, forgot about that bit. I am not compiling myself, I am using the installers from lilypond.org. Try if replacing     musicxml ... with     python2 $(grep

Re: issues with musicxml2ly

Hi Knut, Thank you so much for your help and for the explanation, I really appreciate it. This solves the main issue I was having. Concerning the other two feature requests I made in my original in relation to supporting slur positioning and al niente hairpins in musicxml2ly (see

Beams over rests and concaveness

Hello bug-squad, It seems that the beam concaveness value is ignored when beaming over rests, in the case of a single note with a single rest. This happens with and without stemlet. See the code and score below, the groups marked with an asterisk should have been flat (+inf.0 concaveness):

\autoChange behaves inconsistently when rests are present

Hi all, I've came across a strange bug with \autoChange which was not present in version 2.22.2 but is present in version 2.24.1 (and was probably introduced somewhere in between these two versions). Basically, autoChange will sometimes change staves inconsistently and display some notes in

tuplets with tupletFullLength collide with barline

Hello Bug Squad, When using tuplets with tupletFullLength set to True, the last tuplet bracket in a system extends all the way to the barline. This results in potential collisions when barlines cross several staves. E.g., in the output of the code below, the right ending of the last tuplet of

lilypond book preamble not cropping page

Hello everyone, I hope you are all well and had a great year. I noticed that since version 2.24.x, lilypond-book-preamble has stopped automatically cropping the output around the music grobs. *1) *This is the behaviour of 2.22.2, which is what I expect when using lilypond-book-preamble:

Re: lilypond book preamble not cropping page

Hi Klaus, Thanks for the quick reply! On 30/12/2023 17:09, K. Blum wrote: try adding these options to your LY file: #(ly:set-option 'tall-page-formats 'eps,png,pdf) #(ly:set-option 'separate-page-formats 'eps,png,pdf) I can confirm those work. Thanks for pointing me to the previous