Re: GSoC update; Q's about final/draft modes, and triggering footnotes

[Jeffery Shivers]

>
> For greater flexibility, would it be feasible to allow users to create and
> name any number of their own modes (rather than having two "hard-coded")?
> ​
>

Just to put my two cents in, I ​had thought about that as well and almost
suggested it in the OP. If a single project could employ certain settings
in various modes that aren't necessarily *not* final, for instance, and OLL
could help easily navigate those modes, it would certainly be an advantage
to using OLL in general. :-)

On Sat, Jul 2, 2016 at 9:34 PM, Jeffery Shivers 
wrote:

> I'd appreciate any thoughts on the following syntax for implementing
> footnotes with annotations:
>
> \criticalRemark \with {
> message = "my annotation"
> } #'(1 . 2) "my footnote" Slur a4_\the-footnote-hook ( ...
>
> vs.
>
> \criticalRemark \with {
> message = "my annotation"
> footnote-offset = '(1 . 2)
> footnote-text = "my footnote"
> } Slur a4_\the-footnote-hook ( ...
>
> vs. either of the above *without* the need for the footnote hook at all.
> I'm not totally sure how easy/possible it would be to automate the footnote
> by the presence of offset/text arguments, but I certainly think it would be
> work trying. Of course, I can see why taking away that need for a hook
> could also be considered somewhat intrusive of the package, so opinions
> *against* that would be good to hear.
>
> In the first example, the offset and text arguments would be optional. And
> of course anything in the annotation properties list (like
> footnote-offset/text in the second example) are always optional, except for
> message, I think.
>
> Thanks!
> jeffery
>
> On Wed, Jun 29, 2016 at 11:40 PM, Paul  wrote:
>
>> On 06/29/2016 10:03 AM, Urs Liska wrote:
>>
>>> Implementation-wise it is basically nothing to add another mode by
>>> simply allowing additional values for the "mode" option. Packages can also
>>> quite easily implement that by extending the conditionals in their
>>> functions to respond to more than two modes. However, to be useful this
>>> must be discussed rather on the conceptual side, i.e. what kind of mode
>>> would make sense and how to propagate that through different packages
>>> (doesn't make much sense to have a mode that doesn't do much). So, this
>>> aspect is where this discussion should be done. FWIW, just creating an
>>> arbitrary option and configuring your personal files to do some
>>> configuration based on that option might as well provide everything you
>>> asked for, without even touching the openLilyLib packages themselves. HTH
>>> Urs
>>>
>>
>> Ah, ok, I see.  In that case, please disregard my thought.
>>
>> Cheers,
>>
>> -Paul
>>
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: GSoC update; Q's about final/draft modes, and triggering footnotes

[Jeffery Shivers]

I'd appreciate any thoughts on the following syntax for implementing
footnotes with annotations:

\criticalRemark \with {
message = "my annotation"
} #'(1 . 2) "my footnote" Slur a4_\the-footnote-hook ( ...

vs.

\criticalRemark \with {
message = "my annotation"
footnote-offset = '(1 . 2)
footnote-text = "my footnote"
} Slur a4_\the-footnote-hook ( ...

vs. either of the above *without* the need for the footnote hook at all.
I'm not totally sure how easy/possible it would be to automate the footnote
by the presence of offset/text arguments, but I certainly think it would be
work trying. Of course, I can see why taking away that need for a hook
could also be considered somewhat intrusive of the package, so opinions
*against* that would be good to hear.

In the first example, the offset and text arguments would be optional. And
of course anything in the annotation properties list (like
footnote-offset/text in the second example) are always optional, except for
message, I think.

Thanks!
jeffery

On Wed, Jun 29, 2016 at 11:40 PM, Paul  wrote:

> On 06/29/2016 10:03 AM, Urs Liska wrote:
>
>> Implementation-wise it is basically nothing to add another mode by simply
>> allowing additional values for the "mode" option. Packages can also quite
>> easily implement that by extending the conditionals in their functions to
>> respond to more than two modes. However, to be useful this must be
>> discussed rather on the conceptual side, i.e. what kind of mode would make
>> sense and how to propagate that through different packages (doesn't make
>> much sense to have a mode that doesn't do much). So, this aspect is where
>> this discussion should be done. FWIW, just creating an arbitrary option and
>> configuring your personal files to do some configuration based on that
>> option might as well provide everything you asked for, without even
>> touching the openLilyLib packages themselves. HTH Urs
>>
>
> Ah, ok, I see.  In that case, please disregard my thought.
>
> Cheers,
>
> -Paul
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: space the width of key signature

[David Nalesnik]

On Sat, Jul 2, 2016 at 8:10 PM, David Nalesnik  wrote:

>
> I think your method is sound.  Besides the fact that it works, I
> believe that items that respond to break-visibility are treated in a
> similar manner.  I could be wrong -- and please correct me if I am --
> but multiple copies of such things as Clef are made and then thrown
> away when not needed
>
> David

Yes, Clef grobs are created at every barline and suicided later.

(The snippet

{
  c1 c c c
}

creates *5* clefs.  I simply added a printf to
Clef_engraver::create_clef to verify this.)

There is just no way to know where line breaks will be when grobs are
created, so your method is probably the only one feasible.  As
wasteful as it seems, it is the way things are done with breakable
items.

So, kudos!

David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Non-blank chord repeat

[Lee Daniel Crocker]

On Sat, Jul 2, 2016, 5:12 PM Thomas Morley  wrote:

>
> > minus =\once \override ChordName.text = "-"
>
> Works beautifully, thanks, especially with a full em dash.


> "Georgia on my Mind" is a rhythmic nightmare, and that helps tame it.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: space the width of key signature

[David Nalesnik]

On Sat, Jul 2, 2016 at 7:53 PM, David Nalesnik  wrote:
> On Sat, Jul 2, 2016 at 7:21 PM, David Nalesnik  
> wrote:
>> On Sat, Jul 2, 2016 at 6:25 PM, Thomas Morley  
>> wrote:
>>
>>>
>>> Thanks for your code, it will be a great simplification.
>>> Now I'd love to get rid of the engraver. All those StanzaNumber-grobs,
>>> first they are created and then most of them thrown away...
>>> The exercise is to set the stanza-context-property exactly at line-break...
>>>
>>
>> Though it works :)
>>
>> Possibly some hint is to be had by looking at how clefs are managed.
>> How are clefs created by default at the beginning of staffs?
>>
>> At the moment I'm not getting very far looking at the Clef engraver
>> myself.  I'm not understanding what would trigger an explicit clef at
>> a line break, since I see no reference to line breaks anywhere.
>>
>
>
> Oh, that would be break-visibility.  I suppose StanzaNumber would have
> to support that.
>


I think your method is sound.  Besides the fact that it works, I
believe that items that respond to break-visibility are treated in a
similar manner.  I could be wrong -- and please correct me if I am --
but multiple copies of such things as Clef are made and then thrown
away when not needed

David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: space the width of key signature

[David Nalesnik]

On Sat, Jul 2, 2016 at 7:21 PM, David Nalesnik  wrote:
> On Sat, Jul 2, 2016 at 6:25 PM, Thomas Morley  
> wrote:
>
>>
>> Thanks for your code, it will be a great simplification.
>> Now I'd love to get rid of the engraver. All those StanzaNumber-grobs,
>> first they are created and then most of them thrown away...
>> The exercise is to set the stanza-context-property exactly at line-break...
>>
>
> Though it works :)
>
> Possibly some hint is to be had by looking at how clefs are managed.
> How are clefs created by default at the beginning of staffs?
>
> At the moment I'm not getting very far looking at the Clef engraver
> myself.  I'm not understanding what would trigger an explicit clef at
> a line break, since I see no reference to line breaks anywhere.
>


Oh, that would be break-visibility.  I suppose StanzaNumber would have
to support that.

DN

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: space the width of key signature

[David Nalesnik]

On Sat, Jul 2, 2016 at 6:25 PM, Thomas Morley  wrote:

>
> Thanks for your code, it will be a great simplification.
> Now I'd love to get rid of the engraver. All those StanzaNumber-grobs,
> first they are created and then most of them thrown away...
> The exercise is to set the stanza-context-property exactly at line-break...
>

Though it works :)

Possibly some hint is to be had by looking at how clefs are managed.
How are clefs created by default at the beginning of staffs?

At the moment I'm not getting very far looking at the Clef engraver
myself.  I'm not understanding what would trigger an explicit clef at
a line break, since I see no reference to line breaks anywhere.

David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Non-blank chord repeat

[Thomas Morley]

2016-07-03 1:58 GMT+02:00 Thomas Morley :
> 2016-07-03 0:03 GMT+02:00 Lee Daniel Crocker :
>> I'm printing lead sheets with just chords and lyrics, and this makes the
>> rhythm of the tune hard to see. What I'd like to do print chords at regular
>> intervals, say every half note, and rather than having repeats suppressed,
>> have them print "-".
>>
>> For example, "G - C - D C" for two beats of G, two of C, one of D, one of C.
>>
>> I'd be happy to do this manually by inserting a chord named "-" if there
>> were a way to do that. Or I could enter the chords at regular intervals and
>> have it mark the repeats with "-" somehow. Or maybe enter "N.C." and have
>> that print as "-" somehow?
>>
>> --
>> To the extent possible under law, I, Lee Daniel Crocker,
>> waive all copyright and related or neighboring rights to all
>> creative works original to me
>
> Hi,
>
> you could do
>
> (1) manually:
>
> minus =\once \override ChordName.text = "-"
>
> <<
> \new ChordNames
> \chordmode {
>   g4 \minus g c \minus c d c
> }
> \new Staff { \repeat unfold 6 c''4 }
>>>
>
> (2) automatic

This code is insufficient. :(
Let me see, if can come up with something better tomorrow.

> #(define dash-repeated-chords
>   (lambda (context)
>(let ((chord '()))
>  `((acknowledgers
>  (chord-name-interface .
>,(lambda (engraver grob source-engraver)
>  (if (equal? (ly:grob-property grob 'text) chord)
>  (ly:grob-set-property! grob 'text "-"))
>  (set! chord (ly:grob-property grob 'text)
> (finalize . ,(lambda (translator) (set! chord '(
>
> <<
> \new ChordNames \with { \consists #dash-repeated-chords }
> \chordmode {
>   g4 g c c d c
> }
> \new Staff { \repeat unfold 6 c''4 }
>>>
>
> HTH,
>   Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: applyOutput Lyrics.LyricText not working?

[David Kastrup]

Thomas Morley  writes:

> 2016-07-03 0:19 GMT+02:00 David Kastrup :
>>
>> Two possible ways to fix this:
>>
>> 1) add the Output_property_engraver on all possibly interesting
>> Bottom(?) contexts
>> 2) Move the Output_property_engraver to Score level only and change it
>> so that it sends the respective grob starting from the originating
>> engraver context to the first (all?) context in the parentage of that
>> context that matches the alias.
>>
>> The second solution is more work but also more likely to work as
>> expected without further thinking.
>
> Thanks for the hints, I'll have to test how it will work...
>
> What's the reason Output_property_engraver is not added more or less 
> everywhere?

Efficiency?  Oversight?  We had a similar situation with the
Tweak_engraver at some point of time, before

commit 77d99c047772da8e897af75c49b00523556da01e
Author: David Kastrup 
Date:   Thu Apr 4 11:12:38 2013 +0200

Issue 3296: Move Tweak_engraver to Score level

This makes it possible to tweak items announced at Score level, like
MetronomeMark and RehearsalMark.

The advantage is that tweaks will be applied once regardless of the
context structure (the Score context should exist only once).

Due to the hierarchical nature of acknowledgers, acknowledgers in
lower contexts will now get to see the grobs before tweaks have been
applied.  However, grobs are still unfinished (except for type,
properties initialized via context properties and cause) at the time
they are announced, with other details only getting filled in by the
engraver after announcement, so the potential for trouble seems low.
Acknowledgers should usually just register a grob (or write grob data)
with any actual reading of grob data occurring at the end of the
timestep instead.


-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Non-blank chord repeat

[Thomas Morley]

2016-07-03 0:03 GMT+02:00 Lee Daniel Crocker :
> I'm printing lead sheets with just chords and lyrics, and this makes the
> rhythm of the tune hard to see. What I'd like to do print chords at regular
> intervals, say every half note, and rather than having repeats suppressed,
> have them print "-".
>
> For example, "G - C - D C" for two beats of G, two of C, one of D, one of C.
>
> I'd be happy to do this manually by inserting a chord named "-" if there
> were a way to do that. Or I could enter the chords at regular intervals and
> have it mark the repeats with "-" somehow. Or maybe enter "N.C." and have
> that print as "-" somehow?
>
> --
> To the extent possible under law, I, Lee Daniel Crocker,
> waive all copyright and related or neighboring rights to all
> creative works original to me

Hi,

you could do

(1) manually:

minus =\once \override ChordName.text = "-"

<<
\new ChordNames
\chordmode {
  g4 \minus g c \minus c d c
}
\new Staff { \repeat unfold 6 c''4 }
>>

(2) automatic

#(define dash-repeated-chords
  (lambda (context)
   (let ((chord '()))
 `((acknowledgers
 (chord-name-interface .
   ,(lambda (engraver grob source-engraver)
 (if (equal? (ly:grob-property grob 'text) chord)
 (ly:grob-set-property! grob 'text "-"))
 (set! chord (ly:grob-property grob 'text)
(finalize . ,(lambda (translator) (set! chord '(

<<
\new ChordNames \with { \consists #dash-repeated-chords }
\chordmode {
  g4 g c c d c
}
\new Staff { \repeat unfold 6 c''4 }
>>

HTH,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: space the width of key signature

[Thomas Morley]

2016-07-02 20:07 GMT+02:00 David Nalesnik :
> Hi,
>
> On Sat, Jul 2, 2016 at 12:49 PM, David Nalesnik
>  wrote:
>> Hi Harm,
>>
>> On Sat, Jul 2, 2016 at 10:43 AM, Thomas Morley  
>> wrote:
>>> 2016-07-01 20:43 GMT+02:00 Br. Gabriel-Marie | SSPX :
 Because stanza numbers only appear on the first line.  Using instrumentName
 to label verse numbers provides automatic numbering on every line.  It
 wasn't my idea, actually, credit for that goes to Thomas Morley  a few
 issues ago in Vol 163:issue 95.  It works quite well.

 On 7/1/2016 1:30 PM, lilypond-user-requ...@gnu.org wrote:
>
> Why not use StanzaNumbers instead of instrumentName to label verse
> numbers?
>>>
>>>
>>> Meanwhile I tried to make StanzaNumber at every line-begin work, see 
>>> attached.
>>> Though, it's stacking workarounds, thus pretty expensive.
>>> At least it _is_ possible, even now.
>>> Maybe someone steps in futher improving it.
>>
>> It is possible to check the break status of the NonMusicalPaperColumn
>> to the left of the StanzaNumber.  This eliminates the need to filter a
>> list of all grobs on the line.
>>
>> First, you need the StanzaNumber's column.  Then you can get its left
>> neighbor (which is needed b/c the stanza's column is a PaperColumn and
>> won't carry useful break info.).  If the neighbor is non-musical and
>> right-broken, we're at the start of the line.
>>
>> &=
>>
>> #(define (at-line-beginning? grob)
>>(let* ((col (ly:item-get-column grob))
>>   (ln (ly:grob-object col 'left-neighbor)))
>>  (not (and (eq? #t (ly:grob-property ln 'non-musical))
>>(= 1 (ly:item-break-dir ln))
>>
>> #(define (keep-stanza-number-at-line-begin grob)
>>(if (at-line-beginning? grob)
>>(ly:grob-suicide! grob)))
>>
>> &
>
> Sorry, logic fail:
>
> #(define (at-line-beginning? grob)
>(let* ((col (ly:item-get-column grob))
>   (ln (ly:grob-object col 'left-neighbor))
>   (col-to-check (if (ly:grob? ln) ln col)))
>  (and (eq? #t (ly:grob-property col-to-check 'non-musical))
>   (= 1 (ly:item-break-dir col-to-check)
>
> #(define (keep-stanza-number-at-line-begin grob)
>(if (not (at-line-beginning? grob))
>(ly:grob-suicide! grob)))
>
> %
>
> This should work with grobs whose column is itself non-musical.  So
> you could do this:
>
> \new Staff {
>   \override Staff.Clef.after-line-breaking =
>   #(lambda (grob)
>  (if (at-line-beginning? grob)
>  (set! (ly:grob-property grob 'color) red)))
>
>   c1
>   \break
>   c1 \clef bass c1
>   \break
>   \clef treble c1
> }
>
>
> %%%
>
> Best,
> DN

Thanks for your code, it will be a great simplification.
Now I'd love to get rid of the engraver. All those StanzaNumber-grobs,
first they are created and then most of them thrown away...
The exercise is to set the stanza-context-property exactly at line-break...

Thanks,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: applyOutput Lyrics.LyricText not working?

[Thomas Morley]

2016-07-03 0:19 GMT+02:00 David Kastrup :
> Thomas Morley  writes:
>
>> Hi,
>>
>> consider the following two snippets:
>>
>> \version "2.19.44"
>>
>> \new ChordNames
>>   \chordmode {
>>\applyOutput ChordNames.ChordName
>>  #(lambda (g ctx p)
>>(write-me "\ng" g)
>>(write-me "ctx" ctx)
>>(write-me "p" p)
>>)
>> c
>>   }
>>
>> \new Lyrics
>>   \lyricmode {
>>\applyOutput Lyrics.LyricText
>>  #(lambda (g ctx p)
>>(write-me "\ng" g)
>>(write-me "ctx" ctx)
>>(write-me "p" p)
>>)
>> foo
>>   }
>>
>> I get terminal-output as requested from the first example but none
>> from the second.
>>
>> Am I doing something wrong?
>> Is there a limitation I'm not aware?
>> Or simply a bug?
>
> Well, call it what you want...
>
>
>
> Two possible ways to fix this:
>
> 1) add the Output_property_engraver on all possibly interesting
> Bottom(?) contexts
> 2) Move the Output_property_engraver to Score level only and change it
> so that it sends the respective grob starting from the originating
> engraver context to the first (all?) context in the parentage of that
> context that matches the alias.
>
> The second solution is more work but also more likely to work as
> expected without further thinking.
>
> --
> David Kastrup
>

Thanks for the hints, I'll have to test how it will work...

What's the reason Output_property_engraver is not added more or less everywhere?

Thanks,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: applyOutput Lyrics.LyricText not working?

[David Kastrup]

Thomas Morley  writes:

> Hi,
>
> consider the following two snippets:
>
> \version "2.19.44"
>
> \new ChordNames
>   \chordmode {
>\applyOutput ChordNames.ChordName
>  #(lambda (g ctx p)
>(write-me "\ng" g)
>(write-me "ctx" ctx)
>(write-me "p" p)
>)
> c
>   }
>
> \new Lyrics
>   \lyricmode {
>\applyOutput Lyrics.LyricText
>  #(lambda (g ctx p)
>(write-me "\ng" g)
>(write-me "ctx" ctx)
>(write-me "p" p)
>)
> foo
>   }
>
> I get terminal-output as requested from the first example but none
> from the second.
>
> Am I doing something wrong?
> Is there a limitation I'm not aware?
> Or simply a bug?

Well, call it what you want...

\version "2.19.44"

\new ChordNames
  \chordmode {
   \applyOutput ChordNames.ChordName
 #(lambda (g ctx p)
   (write-me "\ng" g)
   (write-me "ctx" ctx)
   (write-me "p" p)
   )
c
  }

\new Lyrics \with { \consists "Output_property_engraver" }
  \lyricmode {
   \applyOutput Lyrics.LyricText
 #(lambda (g ctx p)
   (write-me "\ng" g)
   (write-me "ctx" ctx)
   (write-me "p" p)
   )
foo
  }

Two possible ways to fix this:

1) add the Output_property_engraver on all possibly interesting
Bottom(?) contexts
2) Move the Output_property_engraver to Score level only and change it
so that it sends the respective grob starting from the originating
engraver context to the first (all?) context in the parentage of that
context that matches the alias.

The second solution is more work but also more likely to work as
expected without further thinking.

-- 
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Non-blank chord repeat

[Lee Daniel Crocker]

I'm printing lead sheets with just chords and lyrics, and this makes the
rhythm of the tune hard to see. What I'd like to do print chords at regular
intervals, say every half note, and rather than having repeats suppressed,
have them print "-".

For example, "G - C - D C" for two beats of G, two of C, one of D, one of
C.

I'd be happy to do this manually by inserting a chord named "-" if there
were a way to do that. Or I could enter the chords at regular intervals and
have it mark the repeats with "-" somehow. Or maybe enter "N.C." and have
that print as "-" somehow?

--
To the extent possible under law, I, Lee Daniel Crocker,
waive all copyright and related or neighboring rights to all
creative works original to me
.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Create custom Staff type

[dtsmarin]

Thanks Paul,
This helps a lot. But I'm very pleased with the solution Abraham Lee posted
before.
This snippet is very useful though for other things I want to try.
-Dimitris 



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Create-custom-Staff-type-tp192105p192114.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

applyOutput Lyrics.LyricText not working?

[Thomas Morley]

Hi,

consider the following two snippets:

\version "2.19.44"

\new ChordNames
  \chordmode {
   \applyOutput ChordNames.ChordName
 #(lambda (g ctx p)
   (write-me "\ng" g)
   (write-me "ctx" ctx)
   (write-me "p" p)
   )
c
  }

\new Lyrics
  \lyricmode {
   \applyOutput Lyrics.LyricText
 #(lambda (g ctx p)
   (write-me "\ng" g)
   (write-me "ctx" ctx)
   (write-me "p" p)
   )
foo
  }

I get terminal-output as requested from the first example but none
from the second.

Am I doing something wrong?
Is there a limitation I'm not aware?
Or simply a bug?

Thanks,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Create custom Staff type

[Paul]

On 07/02/2016 02:08 PM, David Kastrup wrote:

\layout {
   \context { \Staff
 \name "HiddenStaff"
 \alias "Staff"
 \RemoveAllEmptyStaves
   }
   \inherit-acceptability HiddenStaff Staff
}


See also this snippet: http://lsr.di.unimi.it/LSR/Item?id=882

\inherit-acceptability simplifies things considerably but note that it 
is in the latest development version, 2.19, but not in the stable 2.18 
version.


-Paul

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Create custom Staff type

[David Kastrup]

tisimst  writes:

> Dimitris,
>
> On Saturday, July 2, 2016, dtsmarin [via Lilypond] <
> ml-node+s1069038n192107...@n5.nabble.com> wrote:
>
>> Thank you, but this is not what I'm looking for.
>> I want a special type of "Engraver_group" like Staff, GrandStaff etc.
>> e.g.
>> scoreAViolaPart = \new GrandStaff \with {  \clef "alto"
>> } << \set GrandStaff.systemStartDelimiter = #'SystemStartSquare
>>   \new Staff = "A" << \global \scoreAViolaAI \\ \scoreAViolaAII >>
>>   \new *HiddenStaff* = "B" <<  \global \scoreAViolaBI \\ \scoreAViolaBII
>> >>
>> >>
>>
>> This way, the command \RemoveEmptyStaves will only affect the HiddenStaff
>> staves, that will have by default this command enabled.
>>
>> I hope this makes sense.
>>
>
> Maybe all you need is :
>
> \new Staff \with { \RemoveAllEmptyStaves } {...}

I cannot figure out at all what the original poster wants.  If your
proposal is in any way going in the direction he is aiming for, chances
are that

\layout {
  \context { \Staff
\name "HiddenStaff"
\alias "Staff"
\RemoveAllEmptyStaves
  }
  \inherit-acceptability HiddenStaff Staff
}

will do what he wants with regard to an additional HiddenStaff context
(though I have no idea why one would use that name, and one may want to
do the same for \midi though without \RemoveAllEmptyStaves in order to
not have the Midi production confused by HiddenStaff).

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: space the width of key signature

[David Nalesnik]

Hi,

On Sat, Jul 2, 2016 at 12:49 PM, David Nalesnik
 wrote:
> Hi Harm,
>
> On Sat, Jul 2, 2016 at 10:43 AM, Thomas Morley  
> wrote:
>> 2016-07-01 20:43 GMT+02:00 Br. Gabriel-Marie | SSPX :
>>> Because stanza numbers only appear on the first line.  Using instrumentName
>>> to label verse numbers provides automatic numbering on every line.  It
>>> wasn't my idea, actually, credit for that goes to Thomas Morley  a few
>>> issues ago in Vol 163:issue 95.  It works quite well.
>>>
>>> On 7/1/2016 1:30 PM, lilypond-user-requ...@gnu.org wrote:

 Why not use StanzaNumbers instead of instrumentName to label verse
 numbers?
>>
>>
>> Meanwhile I tried to make StanzaNumber at every line-begin work, see 
>> attached.
>> Though, it's stacking workarounds, thus pretty expensive.
>> At least it _is_ possible, even now.
>> Maybe someone steps in futher improving it.
>
> It is possible to check the break status of the NonMusicalPaperColumn
> to the left of the StanzaNumber.  This eliminates the need to filter a
> list of all grobs on the line.
>
> First, you need the StanzaNumber's column.  Then you can get its left
> neighbor (which is needed b/c the stanza's column is a PaperColumn and
> won't carry useful break info.).  If the neighbor is non-musical and
> right-broken, we're at the start of the line.
>
> &=
>
> #(define (at-line-beginning? grob)
>(let* ((col (ly:item-get-column grob))
>   (ln (ly:grob-object col 'left-neighbor)))
>  (not (and (eq? #t (ly:grob-property ln 'non-musical))
>(= 1 (ly:item-break-dir ln))
>
> #(define (keep-stanza-number-at-line-begin grob)
>(if (at-line-beginning? grob)
>(ly:grob-suicide! grob)))
>
> &

Sorry, logic fail:

#(define (at-line-beginning? grob)
   (let* ((col (ly:item-get-column grob))
  (ln (ly:grob-object col 'left-neighbor))
  (col-to-check (if (ly:grob? ln) ln col)))
 (and (eq? #t (ly:grob-property col-to-check 'non-musical))
  (= 1 (ly:item-break-dir col-to-check)

#(define (keep-stanza-number-at-line-begin grob)
   (if (not (at-line-beginning? grob))
   (ly:grob-suicide! grob)))

%

This should work with grobs whose column is itself non-musical.  So
you could do this:

\new Staff {
  \override Staff.Clef.after-line-breaking =
  #(lambda (grob)
 (if (at-line-beginning? grob)
 (set! (ly:grob-property grob 'color) red)))

  c1
  \break
  c1 \clef bass c1
  \break
  \clef treble c1
}


%%%

Best,
DN

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Create custom Staff type

[dtsmarin]

Well this works for me, it just takes more time to configure in the file but
I'm fine.
 Thanks again Abraham!



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Create-custom-Staff-type-tp192105p192110.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: space the width of key signature

[David Nalesnik]

Hi Harm,

On Sat, Jul 2, 2016 at 10:43 AM, Thomas Morley  wrote:
> 2016-07-01 20:43 GMT+02:00 Br. Gabriel-Marie | SSPX :
>> Because stanza numbers only appear on the first line.  Using instrumentName
>> to label verse numbers provides automatic numbering on every line.  It
>> wasn't my idea, actually, credit for that goes to Thomas Morley  a few
>> issues ago in Vol 163:issue 95.  It works quite well.
>>
>> On 7/1/2016 1:30 PM, lilypond-user-requ...@gnu.org wrote:
>>>
>>> Why not use StanzaNumbers instead of instrumentName to label verse
>>> numbers?
>
>
> Meanwhile I tried to make StanzaNumber at every line-begin work, see attached.
> Though, it's stacking workarounds, thus pretty expensive.
> At least it _is_ possible, even now.
> Maybe someone steps in futher improving it.

It is possible to check the break status of the NonMusicalPaperColumn
to the left of the StanzaNumber.  This eliminates the need to filter a
list of all grobs on the line.

First, you need the StanzaNumber's column.  Then you can get its left
neighbor (which is needed b/c the stanza's column is a PaperColumn and
won't carry useful break info.).  If the neighbor is non-musical and
right-broken, we're at the start of the line.

&=

#(define (at-line-beginning? grob)
   (let* ((col (ly:item-get-column grob))
  (ln (ly:grob-object col 'left-neighbor)))
 (not (and (eq? #t (ly:grob-property ln 'non-musical))
   (= 1 (ly:item-break-dir ln))

#(define (keep-stanza-number-at-line-begin grob)
   (if (at-line-beginning? grob)
   (ly:grob-suicide! grob)))

&

The override to use would be:

%
\override StanzaNumber.after-line-breaking =
#keep-stanza-number-at-line-begin
&

I don't know how infallible this is :)

Hope this is useful!

David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Create custom Staff type

[tisimst]

Dimitris,

On Saturday, July 2, 2016, dtsmarin [via Lilypond] <
ml-node+s1069038n192107...@n5.nabble.com> wrote:

> Thank you, but this is not what I'm looking for.
> I want a special type of "Engraver_group" like Staff, GrandStaff etc.
> e.g.
> scoreAViolaPart = \new GrandStaff \with {  \clef "alto"
> } << \set GrandStaff.systemStartDelimiter = #'SystemStartSquare
>   \new Staff = "A" << \global \scoreAViolaAI \\ \scoreAViolaAII >>
>   \new *HiddenStaff* = "B" <<  \global \scoreAViolaBI \\ \scoreAViolaBII
> >>
> >>
>
> This way, the command \RemoveEmptyStaves will only affect the HiddenStaff
> staves, that will have by default this command enabled.
>
> I hope this makes sense.
>

Maybe all you need is :

\new Staff \with { \RemoveAllEmptyStaves } {...}

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Create-custom-Staff-type-tp192105p192108.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Create custom Staff type

[dtsmarin]

Thank you, but this is not what I'm looking for. 
I want a special type of "Engraver_group" like Staff, GrandStaff etc.
e.g. 
scoreAViolaPart = \new GrandStaff \with {  \clef "alto"
} << \set GrandStaff.systemStartDelimiter = #'SystemStartSquare
  \new Staff = "A" << \global \scoreAViolaAI \\ \scoreAViolaAII >>
  \new *HiddenStaff* = "B" <<  \global \scoreAViolaBI \\ \scoreAViolaBII >>
>>

This way, the command \RemoveEmptyStaves will only affect the HiddenStaff
staves, that will have by default this command enabled. 

I hope this makes sense.






--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Create-custom-Staff-type-tp192105p192107.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Create custom Staff type

[David Wright]

On Sat 02 Jul 2016 at 09:21:00 (-0700), dtsmarin wrote:
> Hello,
> I want to create a Staff type which will be used for hiding extra staves Ι
> don't need.
> Since I use every other available type of staves (Group,Grand,Piano etc.)
> applying removeemptystaves will also affect other staves that I need. 
> 
> I tried to tweak the engraver-init file (found in
> usr/shared/lilypond/current/ly) but I don't know what exactly to tweak to
> make this work.
> 
> it should work like this: \new HiddenStaff  

\stopStaff ? See
http://lists.gnu.org/archive/html/lilypond-user/2016-06/msg00175.html

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Create custom Staff type

[dtsmarin]

Hello,
I want to create a Staff type which will be used for hiding extra staves Ι
don't need.
Since I use every other available type of staves (Group,Grand,Piano etc.)
applying removeemptystaves will also affect other staves that I need. 

I tried to tweak the engraver-init file (found in
usr/shared/lilypond/current/ly) but I don't know what exactly to tweak to
make this work.

it should work like this: \new HiddenStaff  





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Create-custom-Staff-type-tp192105.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: space the width of key signature

[Thomas Morley]

2016-07-01 20:43 GMT+02:00 Br. Gabriel-Marie | SSPX :
> Because stanza numbers only appear on the first line.  Using instrumentName
> to label verse numbers provides automatic numbering on every line.  It
> wasn't my idea, actually, credit for that goes to Thomas Morley  a few
> issues ago in Vol 163:issue 95.  It works quite well.
>
> On 7/1/2016 1:30 PM, lilypond-user-requ...@gnu.org wrote:
>>
>> Why not use StanzaNumbers instead of instrumentName to label verse
>> numbers?


Meanwhile I tried to make StanzaNumber at every line-begin work, see attached.
Though, it's stacking workarounds, thus pretty expensive.
At least it _is_ possible, even now.
Maybe someone steps in futher improving it.

Cheers,
  Harm
\version "2.19.44"

#(define create-stanza-number-grob-engraver
;; puts out a StanzaNumber for every LyricText-grob
  (lambda (context)
   (let ((stanza (ly:context-property context 'stanza)))
 `((acknowledgers
 (lyric-syllable-interface .
   ,(lambda (engraver grob source-engraver)
 (let ((new-stanza-grob 
 (ly:engraver-make-grob engraver 'StanzaNumber '(
 ;; set 'id to select them later
 (ly:grob-set-property! new-stanza-grob 'id (markup->string stanza))
 (ly:grob-set-property! new-stanza-grob 'text stanza)
 
#(define (delete-adjacent-duplicates lst)
"Delete all duplicates in a list of strings."
  (if (and (not (null? lst)) (every string? lst))
  (fold-right (lambda (elem ret)
(if (equal? elem (first ret))
ret
(cons elem ret)))
  (list (last lst))
  (sort lst stringlist (ly:grob-object sys 'all-elements)))
   ;; get all StanzaNumbers
   (stanzas
 (filter
   (lambda (e)
 (grob::has-interface e 'stanza-number-interface))
   all-elts))
   ;; get all stanza-ids, without duplicates
   (stanza-ids
 (delete-adjacent-duplicates
   (filter
 string?
 (map
   (lambda (x)
 (ly:grob-property x 'id))
   stanzas
   ;; put StanzaNumbers into sub-lists according to the 'id
   (id-selected-stanzas
 (map
   (lambda (val)
 (filter
   (lambda (x)
 (equal? (ly:grob-property x 'id) val))
   stanzas))
   stanza-ids)))
  ;; keep only the first StanzaNumber of every line
  ;; all other's stencil is set #f
  ;; TODO there may be a StanzaNumber not catchable this way
  (for-each
 (lambda (lst)
   (if (not (null? (cdr lst)))
   (for-each
 (lambda (stz)
   (ly:grob-set-property! stz 'stencil #f))
 (cdr lst
 id-selected-stanzas)

keepLineStartStanzaNumbers =
\layout {
  \context {
  \Score
  \override NonMusicalPaperColumn.after-line-breaking = 
#keep-stanza-number-at-line-begin
  }
}

numberLyrics =
#(define-scheme-function (nmbr)(number?)
"Return a context-modification setting @code{stanza} and consisting 
@code{create-stanza-number-grob-engraver}."
#{
  \with {
stanza = \markup \italic #(format #f "~a." nmbr)
\consists #create-stanza-number-grob-engraver
  }
#})


%% EXAMPLE


\paper { ragged-last-bottom = ##f }

\score {
  <<
\new Staff { \key cis \major \repeat unfold 6 {  c''4 d'' e'' } }
\new Lyrics \with \numberLyrics 1
  \lyricmode {
\repeat unfold 6 {  foo -- bar -- buzz }
  }
  
\new Lyrics \with \numberLyrics 2
  \lyricmode {
\repeat unfold 6 {  very-very-long-syllable bur -- buuuzz }
  }
  
\new Lyrics \with \numberLyrics 3
  \lyricmode {
\repeat unfold 6 {  fuu -- bla -- blibbb }
  }
  >>
  \header { piece = \markup \rounded-box \fill-line { "Using StanzaNumber" } }
  \layout { \keepLineStartStanzaNumbers }
}

\score {
  <<
\new Staff { \key cis \major \repeat unfold 6 {  c''4 d'' e'' } }
\new Lyrics \with { instrumentName = "1." shortInstrumentName = "1." }
  \lyricmode {
\repeat unfold 6 {  foo -- bar -- buzz }
  }
  
\new Lyrics \with { instrumentName = "2." shortInstrumentName = "2." }
  \lyricmode {
\repeat unfold 6 {  very-very-long-syllable bur -- buuuzz }
  }
  
\new Lyrics \with { instrumentName = "3." shortInstrumentName = "3." }
  \lyricmode {
\repeat unfold 6 {  fuu -- bla -- blibbb }
  }
  >>
  \header { piece = \markup \rounded-box \fill-line { "Using InstrumentName" } }
  \layout {
  	\context {
   

Re: space the width of key signature

[Simon Albrecht]

This kind of problems clearly shows that it would be better to have a 
possibility of using actual stanza numbers. I created 
.


Best, Simon

On 01.07.2016 17:46, Br. Gabriel-Marie | SSPX wrote:
There is this one song that is in c-minor and so the key signature 
shows the three flat signs at the beginning of each staff.


But c-major doesn't need any extra signs.

However, I am numbering my lyrics like this so that I get numbers on 
every line:

\new Lyrics \with { instrumentName = "8." shortInstrumentName = "8." }

\context{
\Lyrics
%  Verse numbering using instrumentname
\override InstrumentName.X-offset = 3
\override InstrumentName.font-size = 0
}

This puts my numbering just under the three flat signs in c-minor.

But my problem is that in c-major the lyric text overlaps the numbers.

So, how can I insert a "blank" in the staff where I'd normally have 
the three flats?  (I'm looking in the docs at \staff and horizontal 
spacing)



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: oddHeaderMarkup in score header

[Simon Albrecht]

On 02.07.2016 03:30, Jaja wrote:

I tried to typeset multiple scores without using bookpart or book block. So 
far, oddHeaderMarkup and evenHeaderMarkup cannot be applied to score header. 
The same problem happened with oddFooterMarkup and evenFooterMarkup.

It would be very flexible and speed my work a lot if there is solution to it.


The variables you name are paper variables, so they can only be applied 
to bookparts or books. In order to get score headers, use

\score {
  … music …
  \header {}
}
and—if necessary—customise them as explained in 
.


If there are further questions, please give a code example. 



Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Shorten a beam stem length

[Simon Albrecht]

On 02.07.2016 04:22, Andrew Bernard wrote:
Also, in your code, if you mean a length of 1, just use #1 for Scheme, 
not #’(1) as you had.


Actually even the hash sign is unnecessary. Numbers mean the same in 
LilyPond syntax as in Scheme syntax (except for the special case of #.3 
– that doesn’t work in LilyPond syntax.


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: tiny function

[David Kastrup]

David Kastrup  writes:

> Thomas Morley  writes:
>
>> Otoh, we can store things like \paper, \layout, \midi, \with and as
>> off issue 4908 even \header in variables.
>> But when called, the variable needs to be wrapped in a proper manner,
>> sometimes not. Example:
>>
>> ppr = \paper { ragged-right = ##f }
>>
>> %% works
>> \book {
>>   \paper { \ppr }
>>   { ces''1 }
>> }
>>
>> %% doesn't work
>> \book {
>>   \ppr
>>   { cis''1 }
>> }
>>
>> %% works
>> \ppr
>> { cisis''1 }
>>
>> Admittedly, this example is about \paper not \with, more, I use always
>> fixed values no function calls and other things are coming into the
>> game.
>
> Argh!
>
> This is just a bug.  It's supposed to work but apparently fails.  The
> parser obviously does all of the parsing (there is no error message) but
> the processing does not quite do the right thing.

Tracker issue: 4912 (https://sourceforge.net/p/testlilyissues/issues/4912/)
Rietveld issue: 299490043 (https://codereview.appspot.com/299490043)
Issue description:
  Fix output definition use in \book and \bookpart  The only explicit
  output definition blocks allowed in \book and \bookpart blocks were
  paper blocks.  Output definitions supplied with Scheme expressions
  were erroneously interpreted like global output definitions,
  accepting all output definition types and overriding the global
  defaults with them.  Now the only output definitions accepted as
  Scheme expressions are paper blocks.  As opposed to previously, they
  actually set the paper block of the respective book or bookpart.


Sometimes a bug is just a bug.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: tiny function

[David Kastrup]

Thomas Morley  writes:

> Well, not really. As said before, my feelings were ambivalent.
>
> After reconsidering:
>
> It's more a possibility I sometimes use. Mostly because of lazyness in typing.
>
> Writing
> \new Staff \with \some-function-returning-a-context-modification ...
> instead of
> \new Staff \some-function-returning-a-context-modification ...
> is not a big deal. A few key-strokes nothing else ...
> Though, I thought it was the OP's main point.

I am not sure it was the main point.  The problem is that the function
does need the \with (and scheme functions are comparatively new as
opposed to \with \identifier) indeed and cannot omit it.

> Otoh, we can store things like \paper, \layout, \midi, \with and as
> off issue 4908 even \header in variables.
> But when called, the variable needs to be wrapped in a proper manner,
> sometimes not. Example:
>
> ppr = \paper { ragged-right = ##f }
>
> %% works
> \book {
>   \paper { \ppr }
>   { ces''1 }
> }
>
> %% doesn't work
> \book {
>   \ppr
>   { cis''1 }
> }
>
> %% works
> \ppr
> { cisis''1 }
>
> Admittedly, this example is about \paper not \with, more, I use always
> fixed values no function calls and other things are coming into the
> game.

Argh!

This is just a bug.  It's supposed to work but apparently fails.  The
parser obviously does all of the parsing (there is no error message) but
the processing does not quite do the right thing.

> Though, I'd love to see it consistent for all of \paper, \layout,
> \midi, \with and \header, regardless if it's a function call or not,
> regardless where called.

In some respects that depends on where the parser goes.  It's really
really quite at its limit concerning parsing comparatively free-form
expressions with its lookahead.  So it's often give one, take one.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user