Re: Shorten a beam stem length

[Andrew Bernard]

Hi Joe,

Set Beam.positions.

I use this concept continually, for my work, in almost every bar. Here are
a couple of utility functions I wrote that you may find handy. Nothing
special, just convenient.

setBeamPos =
#(define-music-function
  (left right)
  (number? number?)
  "Manually set beam position for next group."
  #{
\once \override Beam.positions = #(cons left right)
  #})

setBeamPosAll =
#(define-music-function
  (left right)
  (number? number?)
  "Manually set beam position for following groups."
  #{
\override Beam.positions = #(cons left right)
  #})


Also, in your code, if you mean a length of 1, just use #1 for Scheme, not
#’(1) as you had.


Andrew

== snip

\version "2.19.39"
\language "english"
global = {\time 2/4 \key d \minor }
<<
  \global \relative c'
  {
\stemDown 4 ~ |

\once \override Beam.positions = #'(-4 . -4)
8. 16 \revert Stem.Details 16 ()  () |
  }
  \\
  {
\skip 4 g'4~ |
\once \override Flag.style = #'no-flag g'8. \skip 16 \skip 4 |
  }
>>

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

oddHeaderMarkup in score header

[Jaja]

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. 

Any idea?

#! Sent from my iPhone #!
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Shorten a beam stem length

[Joseph N. Srednicki]

Please see the code fragment below.

 

In measure 2, I want to shorten the stems of the first two beamed notes.

 

I tried using \override Stem.detail.beamed-lengths, but I cannot get it to
work.

 

Can someone point me in the right direction?

 

Thanks for any help that you are willing to provide.

 

Joe Srednicki

 

\version "2.19.39"

\language "english"

global = {\time 2/4 \key d \minor }

<< \global \relative c'

  {

\stemDown 4 ~ |

 \override Stem.details.beamed-lengths = #'(1) 8. 16
\revert Stem.Details 16 ()  () |

  }

  \\

  {

\skip 4 g'4~ |

\once \override Flag.style = #'no-flag g'8. \skip 16 \skip 4 |

  }

>> 

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

Re: tiny function

[Thomas Morley]

2016-07-01 11:50 GMT+02:00 David Kastrup :
> David Kastrup  writes:
>
>> Thomas Morley  writes:
>>
>>> 2016-07-01 7:05 GMT+02:00 David Kastrup :
 Thomas Morley  writes:
>>>
> %% works:
> tstII =
> \with { instrumentName = "foo" shortInstrumentName = "foo" }
> \new Staff \tstII { r1 }

 Issue 4911 is supposed to harmonize this by stopping the second example
 from working.  This makes it possible to recognize the syntax without
 knowing the type of \tstII in advance (could be a music expression,
 leading to completely different structure).
>>>
>>> I'm in two minds here.
>>> Hormonizing code is always preferable, but being able to spare the
>>> extra \with would be nice as well.
>>
>> Why?  There are technical considerations underlying this change that are
>> also related to usability changes, like editors having a chance to
>> properly identify and indent parts of an expression.
>>
>> It is not possible to let an argument-less scheme function work in the
>> same manner/syntax as a fixed context modification works right now.
>> Fixing that comes at a high cost, basically requiring special-casing
>> scheme functions in a similar vein as now music/event functions are
>> special-cased.  Which is something that makes it impossible to create
>> structures of music/event functions and other things.
>
> Sigh.  I make a hash of my communication.  This sounds just like a rant.

Nah, I didn't understand it like that.

> But the "Why?" was actually an honest question.  A lot of the work I do
> is focused about making entry more convenient and better reflecting the
> writers' ways of thinking about music.  LilyPond has sort-of a free-form
> syntax that tends to create quite a few ambiguities.  So there are some
> balancing acts involved here.
>
> Now in this case I was working on some parser refactoring and it dumped
> out something like a dozen shift/reduce conflicts (meaning ambiguities
> in the resulting syntax in need of resolution) of which more than a
> third were due to the \with thing.  The particular stuff I was working
> on was of the
>
> xxx = ...
> \xxx
>
> variety where xxx needs to get consulted to decide whether it is still
> part of ... or not.  Now many such decisions can be made on the basis
> "anything of form \xxx cannot become part of ...".  For example, if I
> allow a.b and have seen a, I only need to know whether the next token is
> . or not, and I don't need to know what value/type \xxx has, only that
> it is not a period.
>
> But to make decisions on that level, \xxx basically falls into two
> tokens, the first just saying "this is an escaped identifier" and the
> second actually looking at the type of xxx.
>
> Now the parser works only with very limited and specific lookahead.  If
> I split escape sequences like \xxx into two tokens effectively, the
> parser stops being able to make some decisions timely that it currently
> still can do with a lookahead of a single token.
>
> I am still making a hash of my communication.  Being able to omit \with
> comes at a cost in complexity because
>
> \new Staff \xxx
>
> causes completely different syntactical meaning depending on whether
> \xxx is a context modification or music.  When writing
>
> \new Staff \with { \xxx }
>
> \xxx _still_ can be either a music expression (like \hide BarLine) or a
> context modification, but at that point it does not cause a complete
> rewiring of the parse tree: LilyPond can just evaluate, take a look at
> the resulting expression, and then decide what to do with it, namely
> _how_ to make it part of the resulting context modification.  There is
> still ambiguity but it does not influence how to parse the expression.
>
> So being able to omit \with comes at a cost, and it works only with
> fixed identifiers.  So how to justify the cost?  And that's where "why?"
> comes into play.  User friendliness is an argument.
>
> Now personally, I find it distracting to see something like
> \RemoveEmptyStaves without \with.  I haven't omitted it myself, and it's
> present in most of LilyPond's documentation and examples as well (the
> convert-ly rule has very little actual impact on the code).
> Independently of just having figured out or remembered that this thing
> comes at a non-zero cost in Bison parsing complexity.
>
> Obviously, that's not how you feel about the construct.

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.


Otoh, we can store things like \paper, \layout, \midi, \with and as
off issue 4908 even \header in variables.

Re: space the width of key signature

[Karlin High]

On 7/1/2016 12:18 PM, Dominic wrote:
> Why not use StanzaNumbers instead of instrumentName to label verse numbers?
> http://lilypond.org/doc/v2.19/Documentation/notation/stanzas
>
Br. Gabriel Marie: Is the need for a stanza number at each line caused 
by having so many stanza that readers lose their places when they move 
to a new line?

Karlin High
Missouri, USA

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

Re: Remove trailing time-signature

[Noeck]

Hi,

Am 01.07.2016 um 20:30 schrieb Br. Gabriel-Marie | SSPX:
> Well, so this will get rid of the time-signature,
> 
> \override TimeSignature.break-visibility = #all-invisible

I don't know where you put this but I think you need a Staff (or Score)
there because the TimeSignature is in the Staff and not in the Voice
context:

\once \override Staff.TimeSignature.break-visibility =
#end-of-line-invisible


> 
> But I still can't get rid of the three sharps that go with the clef. 
> This keeps on appearing at the end of the line and I can't get rid of
> it.  It seems to persist no matter what setting I use.
> 
> \override KeySignature.break-visibility = #begin-of-line-visible
> \override ClefModifier.break-visibility = #begin-of-line-visible
> \override KeyCancellation.break-visibility = #begin-of-line-visible
> 

That works just the same:

\once \override Staff.KeyCancellation.break-visibility =
#end-of-line-invisible

In general a minimal example like this would be good for others to help
you. Something like this:

\relative {
  \key a \major
  \time 3/4
  b4 g'2 \break
  \once \override Staff.TimeSignature.break-visibility =
#end-of-line-invisible
  \once \override Staff.KeyCancellation.break-visibility =
#end-of-line-invisible
  \key c \major
  \time 4/4
  f1
}

Best,
Joram

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

Re: space the width of key signature

[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?



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

Re: Remove trailing time-signature

[Br. Gabriel-Marie | SSPX]

Well, so this will get rid of the time-signature,

\override TimeSignature.break-visibility = #all-invisible

But I still can't get rid of the three sharps that go with 
the clef.  This keeps on appearing at the end of the line 
and I can't get rid of it.  It seems to persist no matter 
what setting I use.


\override KeySignature.break-visibility = 
#begin-of-line-visible
\override ClefModifier.break-visibility = 
#begin-of-line-visible
\override KeyCancellation.break-visibility = 
#begin-of-line-visible






On 7/1/2016 12:04 PM, Br. Gabriel-Marie | SSPX wrote:

Oh, I got this one too.

\override TimeSignature.break-visibility = #all-invisible

I wouldn't have posted, but I already spent 20 minutes 
trying to figure it out!  Then when I post - voila!  I get it.


Thanks, y'all, for all of your help.

On 7/1/2016 11:59 AM, Br. Gabriel-Marie | SSPX wrote:
During my piece I have a \break which causes the 
time-signature to be inserted at the end of that line, 
but all my music fits onto one small page, so I don't 
want that extra markup.


So how do I suppress the extra time-signature at the end 
of the line?


I found this, but it doesn't seem to do the trick:
\override Score.TimeSignature. = #end-of-line-invisible




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

Re: space the width of key signature

[Dominic]

Why not use StanzaNumbers instead of instrumentName to label verse numbers?
http://lilypond.org/doc/v2.19/Documentation/notation/stanzas



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/space-the-width-of-key-signature-tp192079p192083.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: Remove trailing time-signature

[Br. Gabriel-Marie | SSPX]

Oh, I got this one too.

\override TimeSignature.break-visibility = #all-invisible

I wouldn't have posted, but I already spent 20 minutes 
trying to figure it out!  Then when I post - voila!  I get it.


Thanks, y'all, for all of your help.

On 7/1/2016 11:59 AM, Br. Gabriel-Marie | SSPX wrote:
During my piece I have a \break which causes the 
time-signature to be inserted at the end of that line, but 
all my music fits onto one small page, so I don't want 
that extra markup.


So how do I suppress the extra time-signature at the end 
of the line?


I found this, but it doesn't seem to do the trick:
\override Score.TimeSignature. = #end-of-line-invisible


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

Remove trailing time-signature

[Br. Gabriel-Marie | SSPX]

During my piece I have a \break which causes the 
time-signature to be inserted at the end of that line, but 
all my music fits onto one small page, so I don't want that 
extra markup.


So how do I suppress the extra time-signature at the end of 
the line?


I found this, but it doesn't seem to do the trick:
\override Score.TimeSignature. = #end-of-line-invisible

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

Re: space the width of key signature

[Br. Gabriel-Marie | SSPX]

Ah!  I think I got this one:

 \override LyricText #'extra-offset = #'(0.8 . 0)

This will allow me to add extra space between the numbers 
(which are in the right place) and the start of the lyric text.


On 7/1/2016 10:46 AM, 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

space the width of key signature

[Br. Gabriel-Marie | SSPX]

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

NR 2.10.2 - arabic key signatures

[Federico Bruni]

Hi all

In the following paragraph, taken from 
http://lilypond.org/doc/v2.19/Documentation/notation/arabic-music#arabic-key-signatures


Other maqams in the same bayati group, as shown in the table below: 
(bayati, hussaini, saba, and ushaq) can be indicated in the same way. 
These are all variations of the base and most common maqam in the 
group, which is bayati. They usually differ from the base maqam in 
their upper tetrachords, or certain flow details that don’t change 
their fundamental nature, as siblings.


The last sentence seems quite obscure to me. What are "flow details"? 
What are "siblings" in this context?
I guess that it's about lilypond internals, but the average user (like 
me) reading the Notation Reference is not supposed to know about them, 
right?


I'm trying to translate this stuff but I do not understand it.

Thanks
Federico


___
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:
>
>> 2016-07-01 7:05 GMT+02:00 David Kastrup :
>>> Thomas Morley  writes:
>>
 %% works:
 tstII =
 \with { instrumentName = "foo" shortInstrumentName = "foo" }
 \new Staff \tstII { r1 }
>>>
>>> Issue 4911 is supposed to harmonize this by stopping the second example
>>> from working.  This makes it possible to recognize the syntax without
>>> knowing the type of \tstII in advance (could be a music expression,
>>> leading to completely different structure).
>>
>> I'm in two minds here.
>> Hormonizing code is always preferable, but being able to spare the
>> extra \with would be nice as well.
>
> Why?  There are technical considerations underlying this change that are
> also related to usability changes, like editors having a chance to
> properly identify and indent parts of an expression.
>
> It is not possible to let an argument-less scheme function work in the
> same manner/syntax as a fixed context modification works right now.
> Fixing that comes at a high cost, basically requiring special-casing
> scheme functions in a similar vein as now music/event functions are
> special-cased.  Which is something that makes it impossible to create
> structures of music/event functions and other things.

Sigh.  I make a hash of my communication.  This sounds just like a rant.
But the "Why?" was actually an honest question.  A lot of the work I do
is focused about making entry more convenient and better reflecting the
writers' ways of thinking about music.  LilyPond has sort-of a free-form
syntax that tends to create quite a few ambiguities.  So there are some
balancing acts involved here.

Now in this case I was working on some parser refactoring and it dumped
out something like a dozen shift/reduce conflicts (meaning ambiguities
in the resulting syntax in need of resolution) of which more than a
third were due to the \with thing.  The particular stuff I was working
on was of the

xxx = ...
\xxx

variety where xxx needs to get consulted to decide whether it is still
part of ... or not.  Now many such decisions can be made on the basis
"anything of form \xxx cannot become part of ...".  For example, if I
allow a.b and have seen a, I only need to know whether the next token is
. or not, and I don't need to know what value/type \xxx has, only that
it is not a period.

But to make decisions on that level, \xxx basically falls into two
tokens, the first just saying "this is an escaped identifier" and the
second actually looking at the type of xxx.

Now the parser works only with very limited and specific lookahead.  If
I split escape sequences like \xxx into two tokens effectively, the
parser stops being able to make some decisions timely that it currently
still can do with a lookahead of a single token.

I am still making a hash of my communication.  Being able to omit \with
comes at a cost in complexity because

\new Staff \xxx

causes completely different syntactical meaning depending on whether
\xxx is a context modification or music.  When writing

\new Staff \with { \xxx }

\xxx _still_ can be either a music expression (like \hide BarLine) or a
context modification, but at that point it does not cause a complete
rewiring of the parse tree: LilyPond can just evaluate, take a look at
the resulting expression, and then decide what to do with it, namely
_how_ to make it part of the resulting context modification.  There is
still ambiguity but it does not influence how to parse the expression.

So being able to omit \with comes at a cost, and it works only with
fixed identifiers.  So how to justify the cost?  And that's where "why?"
comes into play.  User friendliness is an argument.

Now personally, I find it distracting to see something like
\RemoveEmptyStaves without \with.  I haven't omitted it myself, and it's
present in most of LilyPond's documentation and examples as well (the
convert-ly rule has very little actual impact on the code).
Independently of just having figured out or remembered that this thing
comes at a non-zero cost in Bison parsing complexity.

Obviously, that's not how you feel about the construct.  So I have
historically already felt bad about the construct and avoided it, and
the LilyPond code base does look like particularly embracing it either
even though it's been basically available forever.  It's always sort of
a bad feeling to let something stop working but I judged the cost and
said "ok, nobody seems to particularly want that anyway".

Obviously, I was wrong about that and need to reestimate the cost.
I might still end up with the same decision after considering all
available information.  But right now I am obviously missing
information.

-- 
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:

> 2016-07-01 7:05 GMT+02:00 David Kastrup :
>> Thomas Morley  writes:
>
>>> %% works:
>>> tstII =
>>> \with { instrumentName = "foo" shortInstrumentName = "foo" }
>>> \new Staff \tstII { r1 }
>>
>> Issue 4911 is supposed to harmonize this by stopping the second example
>> from working.  This makes it possible to recognize the syntax without
>> knowing the type of \tstII in advance (could be a music expression,
>> leading to completely different structure).
>
> I'm in two minds here.
> Hormonizing code is always preferable, but being able to spare the
> extra \with would be nice as well.

Why?  There are technical considerations underlying this change that are
also related to usability changes, like editors having a chance to
properly identify and indent parts of an expression.

It is not possible to let an argument-less scheme function work in the
same manner/syntax as a fixed context modification works right now.
Fixing that comes at a high cost, basically requiring special-casing
scheme functions in a similar vein as now music/event functions are
special-cased.  Which is something that makes it impossible to create
structures of music/event functions and other things.


> To join both while letting it recognizable I tried:
>
> #(defmacro-public define-with-function rest
>  `(define-syntax-function ly:context-mod? ,@rest))
>
> tstI =
> #(define-with-function ()() #{ \with { instrumentName = "-name-" } #})
>
> \new Staff \tstI { r1 }
>
> Doesn't work.
> A mistake somewhere or is it all rubbish?

Context mod functions are not special-cased.  If you write

(define my-music? (lambda (x) (ly:music? x)))
(define-syntax-function my-music? ...)

the result will stop working as a music function.  Similar for event
functions.  But at the current point of time, those are the only two
special-cased function types.  I want to decrease rather than increase
the number of special-cases here.

>>> %%(3)
>>> #(define (set-instrument-names-to-number-string nmbr mus)
>>> (if (eq? (ly:music-property mus 'name) 'ContextSpeccedMusic)
>>> (ly:music-set-property! mus 'property-operations
>>>   (list
>>> (list
>>>   'assign
>>>   'instrumentName
>>>   (format #f "~a." nmbr))
>>> (list
>>>   'assign
>>>   'shortInstrumentName
>>>   (format #f "~a." nmbr
>>>   mus)
>>> mus)
>>>
>>> tst =
>>> #(define-music-function (nmbr mus)(number? ly:music?)
>>> (set-instrument-names-to-number-string nmbr mus))
>>>
>>> \tst #3 \new Staff { r1 }
>>
>> Hm.  At the current point of time, destructuring expression requires
>> Scheme programming.  And absorbing \new Staff into \tst #3 makes things
>> much less flexible (\context Staff = "..." just becomes impossible
>> then).
>
> Wasn't aware of this problem. Thanks spotting it.

No, you misunderstand.  This is not a problem with your code.  It's
rather a complaint that there is no reasonably better or more readable
way to write your code while keeping it working for a similarly large
number of use cases.

-- 
David Kastrup

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

Re: tiny function

[Thomas Morley]

2016-07-01 7:05 GMT+02:00 David Kastrup :
> Thomas Morley  writes:

>> %% works:
>> tstII =
>> \with { instrumentName = "foo" shortInstrumentName = "foo" }
>> \new Staff \tstII { r1 }
>
> Issue 4911 is supposed to harmonize this by stopping the second example
> from working.  This makes it possible to recognize the syntax without
> knowing the type of \tstII in advance (could be a music expression,
> leading to completely different structure).

I'm in two minds here.
Hormonizing code is always preferable, but being able to spare the
extra \with would be nice as well.
To join both while letting it recognizable I tried:

#(defmacro-public define-with-function rest
 `(define-syntax-function ly:context-mod? ,@rest))

tstI =
#(define-with-function ()() #{ \with { instrumentName = "-name-" } #})

\new Staff \tstI { r1 }

Doesn't work.
A mistake somewhere or is it all rubbish?


>> %%(3)
>> #(define (set-instrument-names-to-number-string nmbr mus)
>> (if (eq? (ly:music-property mus 'name) 'ContextSpeccedMusic)
>> (ly:music-set-property! mus 'property-operations
>>   (list
>> (list
>>   'assign
>>   'instrumentName
>>   (format #f "~a." nmbr))
>> (list
>>   'assign
>>   'shortInstrumentName
>>   (format #f "~a." nmbr
>>   mus)
>> mus)
>>
>> tst =
>> #(define-music-function (nmbr mus)(number? ly:music?)
>> (set-instrument-names-to-number-string nmbr mus))
>>
>> \tst #3 \new Staff { r1 }
>
> Hm.  At the current point of time, destructuring expression requires
> Scheme programming.  And absorbing \new Staff into \tst #3 makes things
> much less flexible (\context Staff = "..." just becomes impossible
> then).

Wasn't aware of this problem. Thanks spotting it.

Cheers,
  Harm

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