[2.15.36] A hidden note blocks beams from drawing

2012-09-28 Thread James Harkins 
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

2012-09-28 Thread 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 }
> 
> 
> 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

2012-09-28 Thread David Kastrup 
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?

2012-09-28 Thread Phil Holmes 
- 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?

2012-09-28 Thread Trevor Daniels 

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?

2012-09-28 Thread David Kastrup 
"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?

2012-09-28 Thread Phil Holmes 
- 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?

2012-09-28 Thread Rutger Hofman 

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?

2012-09-28 Thread Reinhold Kainhofer 
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?

2012-09-28 Thread Rutger Hofman 

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-09-28 Thread Thomas Morley 
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

2012-09-28 Thread Marek Klein 
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