[2.15.36] A hidden note blocks beams from drawing
The beams on the two e's are omitted in this tiny example (version 2.15.36). \relative c' { r8 \hideNotes f8 \unHideNotes e8. e16 e2 } The beams are *not* omitted in this tiny example. \relative c' { r4 e8. e16 e2 } I realize this isn't latest stable -- I'm in the middle of a project and wanted to avoid upgrades unless there was a good reason (like a bugfix). Could someone confirm whether this is or isn't still an issue? If it's fixed in 2.16, then I'll upgrade. The reason for hiding the note is that I needed a phrasing slur to start where there is a note in the second voice, but no (visible) note in the first voice, and the phrasing slur needs to end in the first voice. So I hid a note in voice 1 to start the phrasing slur. The 8.-16 rhythm follows immediately after and looked rather strange with no beams :) hjh -- James Harkins /// dewdrop world jamshar...@dewdrop-world.net http://www.dewdrop-world.net "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman blog: http://www.dewdrop-world.net/words audio clips: http://www.dewdrop-world.net/audio more audio: http://soundcloud.com/dewdrop_world/tracks ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [2.15.36] A hidden note blocks beams from drawing
James Harkins wrote Friday, September 28, 2012 8:08 AM > The beams on the two e's are omitted in this tiny example (version 2.15.36). > > \relative c' { r8 \hideNotes f8 \unHideNotes e8. e16 e2 } > > > The beams are *not* omitted in this tiny example. > > \relative c' { r4 e8. e16 e2 } > > > I realize this isn't latest stable -- I'm in the middle of a project and > wanted to avoid upgrades unless there was a good reason (like a bugfix). > > Could someone confirm whether this is or isn't still an issue? If it's fixed > in 2.16, then I'll upgrade. No, it's not fixed in the latest 2.16 or 2.17 releases. It's a serious bug caused by the way automatic beams are implemented. A workaround is to manually beam the two e's: \relative c' { r8 \hideNotes f8 \unHideNotes e8.[ e16] e2 } Trevor ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [2.15.36] A hidden note blocks beams from drawing
James Harkins writes: > The beams on the two e's are omitted in this tiny example (version 2.15.36). > > \relative c' { r8 \hideNotes f8 \unHideNotes e8. e16 e2 } \once\hideNotes does not help, but after applying the patch for Issue 2717 http://code.google.com/p/lilypond/issues/detail?id=2717> \relative c' { r8 \single\hideNotes f8 e8. e16 e2 } will do the trick. Note that the patch is still under discussion, so the name could change. You could, however, still harvest the current definition of \single from the patch and use that in your music. As it is a Scheme-only patch, it should work fine by just putting the definition in your file, without needing to change LilyPond itself. http://codereview.appspot.com/6495135/diff/13002/ly/music-functions-init.ly> -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Bug in lyrics placement in mensural music?
- Original Message - From: "Trevor Daniels" To: "Phil Holmes" ; "LilyPond User Group" Sent: Thursday, September 27, 2012 7:38 PM Subject: Re: Bug in lyrics placement in mensural music? Phil Holmes wrote Thursday, September 27, 2012 5:02 PM The code below produces the image attached. As can be seen, using a StaffGroup with mensural staves places the lyrics above the top stave, and I can't find an over-ride that gets them in the proper place. I _think_ this must be a bug, but wondering if anyone knows better? No, it's not a bug. The problem is not with the lyrics but with MensuralStaff, which is not accepted by StaffGroup, so they both get pushed to the bottom. Thanks, Trevor. The answer begs the question that it would appear deliberate that this works wrongly, but it still seems to work wrongly by default. It would seem that a StaffGroup _should_ accept a MensuralStaff by default? -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Bug in lyrics placement in mensural music?
Phil Holmes wrote Friday, September 28, 2012 9:40 AM >> Phil Holmes wrote Thursday, September 27, 2012 5:02 PM >> >>> The code below produces the image attached. As can be seen, using a >>> StaffGroup with mensural staves places the lyrics above the top stave, >>> and I >>> can't find an over-ride that gets them in the proper place. I _think_ >>> this >>> must be a bug, but wondering if anyone knows better? >> >> No, it's not a bug. The problem is not with the lyrics but with >> MensuralStaff, which is not accepted by StaffGroup, so they >> both get pushed to the bottom. > > Thanks, Trevor. The answer begs the question that it would appear > deliberate that this works wrongly, but it still seems to work wrongly by > default. It would seem that a StaffGroup _should_ accept a MensuralStaff by > default? That depends on whether the system start brace provided by StaffGroup is used in mensural music. I know nothing about ancient music so I've no idea whether this is the case or not. Trevor ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Bug in lyrics placement in mensural music?
"Trevor Daniels" writes: > Phil Holmes wrote Friday, September 28, 2012 9:40 AM > >>> Phil Holmes wrote Thursday, September 27, 2012 5:02 PM >>> The code below produces the image attached. As can be seen, using a StaffGroup with mensural staves places the lyrics above the top stave, and I can't find an over-ride that gets them in the proper place. I _think_ this must be a bug, but wondering if anyone knows better? >>> >>> No, it's not a bug. The problem is not with the lyrics but with >>> MensuralStaff, which is not accepted by StaffGroup, so they >>> both get pushed to the bottom. >> >> Thanks, Trevor. The answer begs the question that it would appear >> deliberate that this works wrongly, but it still seems to work wrongly by >> default. It would seem that a StaffGroup _should_ accept a MensuralStaff by >> default? > > That depends on whether the system start brace provided by StaffGroup > is used in mensural music. I am not sure about that. Unless the current behavior is _advantageous_ in some situations, there is little point in retaining it. > I know nothing about ancient music so I've no idea whether this is the > case or not. It is not uncommon for music to "mix and match" styles. Granted, this is more the case for Gregorian chant where the notation is not just visually distinct (which is mostly the case for mensural) but rather quite different. But for things like incipits and similar, the combination is not unthinkable either. So we should focus on the question "is there a conceivable reason where the current behavior is actually desirable for more than `user educational' reasons?". If the answer is "no", it seems like we have nothing to gain from keeping it. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Bug in lyrics placement in mensural music?
- Original Message - From: "Trevor Daniels" To: "Phil Holmes" ; "LilyPond User Group" Sent: Friday, September 28, 2012 10:50 AM Subject: Re: Bug in lyrics placement in mensural music? Phil Holmes wrote Friday, September 28, 2012 9:40 AM Phil Holmes wrote Thursday, September 27, 2012 5:02 PM The code below produces the image attached. As can be seen, using a StaffGroup with mensural staves places the lyrics above the top stave, and I can't find an over-ride that gets them in the proper place. I _think_ this must be a bug, but wondering if anyone knows better? No, it's not a bug. The problem is not with the lyrics but with MensuralStaff, which is not accepted by StaffGroup, so they both get pushed to the bottom. Thanks, Trevor. The answer begs the question that it would appear deliberate that this works wrongly, but it still seems to work wrongly by default. It would seem that a StaffGroup _should_ accept a MensuralStaff by default? That depends on whether the system start brace provided by StaffGroup is used in mensural music. I know nothing about ancient music so I've no idea whether this is the case or not. Well - strictly, staff groups aren't used at all in music from this period - each part was copied out separately (rather like orchestral music). However, if you're recreating music of this style, you'd want the option to have them all together for checking purposes, if nothing else (like a conductor's score). Whilst I eventually found that you don't need the staff group, it does seem a natural way to do this, and it took me a while to find out a workaround to get lyrics working. My analysis would be similar to David's - unless there's a clear reason for not allowing a MensuralStaff in a StaffGroup (and I can't think of one) it reduces the scope for wasted time if it's added. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Articulation with parenthesis-open and with parenthesis-close?
Hello list, in my current score, there are long, consecutive lists of notes with articulations (dashes) in parentheses. Now it would improve readability a lot if the first of these parenthesized dashes has only a parenthesis-open, the last has only a parenthesis-close, and the rest has a regular parenthesis. I have seen this in printed music more than once. I would be happy if I could define new articulations like pOD (for parenthesized-open-dash) and pCD (for parenthesized-close-dash) or whatever; best would be to have articulation modifiers (which take the articulation at hand as an argument): -\parenthesizeOpen -| and -\parenthesizeClose -|. Searching list and archives and snippets didn't bring me where I want. I tried to define pDO like this, modifying an example from 2008: http://lilypond.1069038.n5.nabble.com/Custom-articulations-pitched-single-note-trills-td40530.html: \version "2.16.0" pOpenDashMarkup = \markup{ \teeny ( \musicglyph #"scripts.dstaccatissimo" } pOD = #(let* ((music (make-articulation "staccatissimo")) (popen-dash (lambda (grob) (grob-interpret-markup grob pOpenDashMarkup (ly:music-set-property! music 'tweaks (acons 'stencil popen-dash (ly:music-property music 'tweaks))) music) a\pOD But this gives me: programming error: Cannot get a text stencil from this font Also, I wondered why I cannot use #"scripts.staccatissimo". That gives me: warning: Cannot find glyph scripts.staccatissimo I would much prefer to not have to indicate dstaccatissimo and ustaccatissimo by hand. Rutger Hofman Amsterdam ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Articulation with parenthesis-open and with parenthesis-close?
On 28/09/2012 12:06, Rutger Hofman wrote: > in my current score, there are long, consecutive lists of notes with > articulations (dashes) in parentheses. Now it would improve > readability a lot if the first of these parenthesized dashes has only > a parenthesis-open, the last has only a parenthesis-close, and the > rest has a regular parenthesis. I have seen this in printed music more > than once. Coincidentally, I had the same problem the day before yesterday. Here is what I have (using the \parenthesize command and modifying its behavior): % #(define-public (parentheses-item::calc-parenthesis-left-stencils grob) (let* ((font (ly:grob-default-font grob))) (list (ly:font-get-glyph font "accidentals.leftparen") empty-stencil))) #(define-public (parentheses-item::calc-parenthesis-right-stencils grob) (let* ((font (ly:grob-default-font grob))) (list empty-stencil (ly:font-get-glyph font "accidentals.rightparen" parenthesizeLeft = #(define-music-function (parser loc arg) (ly:music?) #{ -\tweak ParenthesesItem #'stencils #parentheses-item::calc-parenthesis-left-stencils -\parenthesize $arg #}) parenthesizeRight = #(define-music-function (parser loc arg) (ly:music?) #{ -\tweak ParenthesesItem #'stencils #parentheses-item::calc-parenthesis-right-stencils -\parenthesize $arg #}) % The \parenthesizeLeft and \parenthesizeRight work exactly like \parenthesize, i.e.: e4.-\parenthesizeLeft->\> 4.-\parenthesizeRight-> | % 3 HTH, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Articulation with parenthesis-open and with parenthesis-close?
On 09/28/2012 01:34 PM, Reinhold Kainhofer wrote: On 28/09/2012 12:06, Rutger Hofman wrote: in my current score, there are long, consecutive lists of notes with articulations (dashes) in parentheses. Now it would improve readability a lot if the first of these parenthesized dashes has only a parenthesis-open, the last has only a parenthesis-close, and the rest has a regular parenthesis. I have seen this in printed music more than once. Coincidentally, I had the same problem the day before yesterday. Here is what I have (using the \parenthesize command and modifying its behavior): % #(define-public (parentheses-item::calc-parenthesis-left-stencils grob) (let* ((font (ly:grob-default-font grob))) (list (ly:font-get-glyph font "accidentals.leftparen") empty-stencil))) #(define-public (parentheses-item::calc-parenthesis-right-stencils grob) (let* ((font (ly:grob-default-font grob))) (list empty-stencil (ly:font-get-glyph font "accidentals.rightparen" parenthesizeLeft = #(define-music-function (parser loc arg) (ly:music?) #{ -\tweak ParenthesesItem #'stencils #parentheses-item::calc-parenthesis-left-stencils -\parenthesize $arg #}) parenthesizeRight = #(define-music-function (parser loc arg) (ly:music?) #{ -\tweak ParenthesesItem #'stencils #parentheses-item::calc-parenthesis-right-stencils -\parenthesize $arg #}) % The \parenthesizeLeft and \parenthesizeRight work exactly like \parenthesize, i.e.: e4.-\parenthesizeLeft->\> 4.-\parenthesizeRight-> | % 3 HTH, Reinhold Thanks, this is great! Rutger ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Replacing the r1 glyph
2012/9/28 Oscar Dub : > The scheme required is a lot clearer to me now and works exactly as I > wanted. I really appreciate the advice. Glad to hear that. [...] > Looking at the code being referred to, the issue seems to be with the > eps->stencil function. Trying with other .eps files from different sources > results in the same problem. Does anyone have any ideas why this isn't > turning out the way I hoped? > > Oscar Hi Oscar, well, I sometimes heard complaints about not working eps-files. I guess (but I'm really no expert with it) that it depends on _how_ the .eps is created. At least mrkp = \markup { \epsfile #X #4 #"note.eps" } using the attached file works, with the code posted in my earlier mail. Cheers, Harm note.eps Description: PostScript document ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [2.15.36] A hidden note blocks beams from drawing
Hello, 2012/9/28 Trevor Daniels > James Harkins wrote Friday, September 28, 2012 8:08 AM > > The beams on the two e's are omitted in this tiny example (version > 2.15.36). > > \relative c' { r8 \hideNotes f8 \unHideNotes e8. e16 e2 } > > The beams are *not* omitted in this tiny example. > > \relative c' { r4 e8. e16 e2 } > > Thank you for the report, this has been added as http://code.google.com/p/lilypond/issues/detail?id=2866 Marek bug squad member ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user