Re: [Best Practices] splitting and combining choral parts

[Kieren MacMillan]

Hi Simon,

> It always uses a consistent number of staves for the music (which might also 
> be due to the music)

This (i.e., the last bit) is the salient point. Look at essentially any opera 
or musical score (full or pianovocal), and a large proportion of [modern] 
choral scores, and you will see a great deal of frenching and part-combining 
and choral-unison-with-occasional-polyphony.*** 

And whether or not the particular example ("Wither’s Carol” mm. 1-17) that I 
included should or should not be in four staves is irrelevant.

I think it’s the perfect example to work out the best practices by which larger 
scores can/should be coded. I’m not really interested in tackling the final 
engraving of my 25-minute holiday suite for double orchestra, double choir, 
barbershop quartet, and children’s choir as the “test example”.  ;)

Cheers,
Kieren.

***  p.s. I couldn’t even find one example, in all my scores of pieces composed 
before 1900, containing a choral unison section of more than four consecutive 
measures. Anyone [counter]examples out there?


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

aligning melisma and non-melisma lyrics across staves in the same system

[Kieren MacMillan]

Hello all,

I know there is a way to have accidentals “cross-canceled” between staves in 
the same system.
(I’ve used it… and it’s wonderful!)

Would it be similarly possible to have lyrics aligned between staves when one 
or more of the lyrics is melisma-attached (and is thus automatically 
left-aligned, according to the value of lyricMelismaAlignment) and one or more 
lyrics is not (and is thus centred, generally)?

Thanks,
Kieren.

%%  EXAMPLE BEGINS
\version "2.19.31"

\score {
  <<
\new Staff \new Voice { c''1( d'') }
\addlyrics { Left __ }
\new Staff \new Voice { c''1 d'' }
\addlyrics { Left not! }
  >>
}
%%  EXAMPLE ENDS


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Layout of a (piano) hand indicator

[Robin Bannister]

David Kastrup wrote:


Of course, the `let' is spurious.  You can just use thumbBracketSettings
directly instead of settings.


The 'let' is my plodding anti-cryptic:
a small step with a locally relevant name, and a slot for comment



Probably as of 2.14 or something.


Written with 2.12 early 2009.
Untouched since then.
I've never used it.


Cheers,
Robin

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

Re: [Best Practices] splitting and combining choral parts

[Kieren MacMillan]

Hi Simon,

> The other major point is that it doesn’t print ‘redundant’ lyrics, i.e. 
> passages with equal rhythm and wording in multiple voices have the lyrics 
> printed only once, mostly below the topmost of the staves.

I finally looked at this example. (Thanks again for including it!)

1. To my eye, the omission of lyrics as you’ve done it here accomplishes the 
worst of both worlds: the gaps are disconcerting (e.g., are the Basses really 
supposed to travel with their eye, unaided, from the extender in m.16 up to the 
Soprano lyrics in m.17??), and there is no real space savings [as would be 
accomplished through the condensing of staves with similar music].

2. Some of the extender suppression is definitely an improvement. But as I 
pointed out earlier in this thread, that kind of tweak should really only be 
done after the final layout is calculated. For [an admittedly extreme] example, 
change the system-count to 12, and then try to convince me that the extender on 
“our” in m. 1 should have been [hard-]omitted.  ;)  This is a separate issue, 
and should [as we’ve agreed] be done automatically, with user-definable 
thresholds, etc.

3. As to the lyric alignment… I like a few of the adjustments (e.g., m. 6 
“drest”), but dislike most others (e.g., m. 6 “leaves”, m. 9 “Though”, m. 11 
“Round"). Several adjustments actually cause unnecessary spacing oddities 
(e.g., m. 12 “Drown” in Bass).

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: [Best Practices] splitting and combining choral parts

[Kieren MacMillan]

Hi Michael,

Thanks for your response…
But people are apparently missing my point/question.

I’m not asking for advice about LyricExtenders, or whether this particular 
score should be in four staves, or about the spacing of the staves and lyrics, 
or autobeaming, or anything like that.

The closest point discussed, in terms of actual relevance, is whether or not 
lyrics should be included below all staves or only between S+A and T+B or 
whatever. THAT — or, more to the point, the mechanism(s) required to make that 
choice easy to do and undo — is what I’m interested in working on.

> I find switches between the number of staves for short periods
> (i.e. a few bars this, a few bars that and another few bars some
> other way) confusing and it takes too much of my precious attention
> when performing.

See my other response.

As just one randomly-selected example: a quick scan of the full score of “Peter 
Grimes” (I have a lovely hardbound Boosey & Hawkes edition) shows a wide range 
of frenching for the vocals (chorus and solists), including systems with 4 
choral staves (S+A+T+B) 3 choral staves (SA+T+B), and 1 choral staff (“CHOR”). 
To include the maximum number of staves on every page — which would be at least 
13, including all soloists, etc. — would obviously be ludicrous.

Cheers,
Kieren.

p.s.

> Last not least for vocal lines I always turn off autoBeam and manually
> put beams to groups that are sung on a single syllable. For my singers
> eyes that strongly helps to keep words and music in a proper flow.

I would never do this: in all but the rhythmically simplest music, 
beam-to-melisma does nothing but make sight-reading and rehearsing more 
difficult.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Confused about output

[Shane Brandes]

Thanks Malte,

That saves me from having to restructure the piece.

Shane

On Wed, Nov 25, 2015 at 2:10 AM, Malte Meyn  wrote:
>
>
> Am 25.11.2015 um 02:19 schrieb Shane Brandes:
>>
>> After fiddling with this for hours i cannot figure out why the added
>> lyrics e and i drop below the bass as opposed to the voices they ought
>> to be associated with which is here "melody" and "mel" that live on
>> the soprano staff. What am I missing?
>
>
> You can use alignBelowContext. I must admit I didn’t really overlook your
> code structure so I didn’t use any variables. But it should be possible with
> your code structure too.
>
> \version "2.18.2"
>
> \score {
>   <<
> \new Staff \with {
>   instrumentName = "Soprano"
> } \new Voice = "soprano_v1" {
>   a2
>   <<
> c'
> \new Voice {
>   \voiceTwo a
> }
> \new Lyrics \with {
>   alignBelowContext = "soprano_l1"
> } \lyricmode {
>   i
> }
>   >>
> }
> \new Lyrics = "soprano_l1" \lyricsto "soprano_v1" {
>   a e
> }
> \new Staff \with {
>   instrumentName = "Bass"
> } \relative {
>   \clef bass
>   f e
> }
> \addlyrics {
>   o u
> }
>   >>
> }
>
> ___
> 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: Layout of a (piano) hand indicator

[Thomas Morley]

2015-11-25 16:40 GMT+01:00 Robin Bannister :
> David Kastrup wrote:
>
>> Of course, the `let' is spurious.  You can just use thumbBracketSettings
>> directly instead of settings.
>
>
> The 'let' is my plodding anti-cryptic:
> a small step with a locally relevant name, and a slot for comment
>
>
>> Probably as of 2.14 or something.
>
>
> Written with 2.12 early 2009.
> Untouched since then.
> I've never used it.
>
>
> Cheers,
> Robin

Hi Robin,

how about putting it into LSR (currently running 2.18.2)?
Every now and then people ask for such a bracket so there is use for
it and at least it would be maintained every LSR-upgrade.


Cheers,
  Harm

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

Re: Strange LilyPond crash

[Michael Gerdau]

> Here's the file... Edski-2015-11-16_v4_test.ly
>  st.ly>

No problem compiling this file and creating a PDF using the current
LilyPond 2.19.32 running from inside Frescobaldi 2.18.1 on an ArchLinux
x86_64 running a Kernel 4.2.5.

Kind regards,
Michael
-- 
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver

signature.asc
Description: This is a digitally signed message part.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Kieren MacMillan]

Hi all,

What about a radical alternative?

What if each non-reference part has an additional “tick” barline (numbered 
according to the reference context) whereever the barlines don’t line up?

Just a thought…
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: [Best Practices] splitting and combining choral parts

[Kieren MacMillan]

Hi, 

> Can we focus on how to achieve automatic frenching based on divisi?

Thanks.  =)

> this seems like a lot of work.

Well, I’m know it won’t be trivial… But I was hoping we could come up with a 
"Goldilocks solution”: a rather elegant way of handling it, with a minimum of 
effort on the engraver’s (i.e., user’s) part.

> It sounds like we want Lily to look at the line she's working on
> and decide whether some of the staves can be
> combined based on the content they have.

Eventually, sure, that’s the ideal. But for now, I’d be happy with manually 
entering \letStaffVanish and \showStaff (i.e., force visibility) at the 
sections where it’s clear those are necessary.

> An ideal solution would have to allow the user to turn certain rules on or 
> off.
> This seems like complex programming to me.

I’m not sure that’s in my Five-Year Plan for this feature/framework.  ;)

> would a solution that requires user intervention be acceptable?

Without a doubt. I sort of assume(d) that Phase One would be completely 
user-driven, with Phase Two [and beyond] being incremental automation of the 
various mechanisms involved.

> For example, a switch like \separateStaves which would force
> staves to be separated from the beginning of the current line, and a
> corresponding \combineStaves which would tell Lily to begin combining at the
> next line break. You would also have to specify which staves to combine.
> This puts the burden of decision on the user, hopefully simplifying the
> programming. Then, Lily just has to create a new Staff, use \partcombine,
> and assign lyrics to the voice.

Yes! This is the kind of discussion I want to have.

For \separateStaves, one can already put \letStaffVanish (resp. 
\letLyricsVanish) in the contexts that are not absolutely required, and 
\showStaff in those parts that are. And we have \quoteDuring, \partCombine, 
etc. to reduce the redundant code entry. See attached modified example.

There’s a divisi framework in openlilylib (cf. 
),
 but I haven’t investigated how mature it is, or how suitable to helping me 
solve this problem.

So… Here are some questions right off the bat:

1. How can I \addQuote and \quoteDuring lyrics?

2. If I wanted to condense the S+A staves on system 3 into a single SA staff, 
what’s the best approach?

3. Would all of this [kind of thing] be best conceived/coded as “exploding 
music” (i.e., start with a unison context, and divisi outwards), or “imploding 
music” (i.e., start with maximum spread, and combine to condense), or a 
combination thereof?

4. Is it better to use the soprano line as the unison line [as I’ve done here], 
or have a whole separate unison variable quoted in all parts [including the 
soprano]? In any case, one would want to add [as I have not] clarifying markups 
at the beginnings of systems or voice entries, as appropriate/necessary.

5. What would be the best way to simultaneously switch contexts/staves on and 
off? How can this be done with a minimum mixture of content and presentation?

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info



WithersCarol_example.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: [Best Practices] splitting and combining choral parts

[Kieren MacMillan]

p.s. To see the power of the system I’m trying to develop, add a manual line 
break at m. 8 (e.g., change line 103 to s4*2 \break s4*2), and then observe how 
the third system reacts.

=)

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Strange LilyPond crash

[Thomas Morley]

2015-11-25 20:30 GMT+01:00 Edward Ardzinski :
> Here's the file... Edski-2015-11-16_v4_test.ly
> 



lilypond Edski-2015-11-16_v4_test.ly
GNU LilyPond 2.18.2
Processing `Edski-2015-11-16_v4_test.ly'
Parsing...
Interpreting music...[8][16][24][32]
Preprocessing graphical objects...
Interpreting music...
MIDI output to `Edski-2015-11-16_v4_test.midi'...
Finding the ideal number of pages...
Fitting music on 1 or 2 pages...
Drawing systems...
Layout output to `Edski-2015-11-16_v4_test.ps'...
Converting to `./Edski-2015-11-16_v4_test.pdf'...
Success: compilation successfully completed

No problem here. Being on Ubuntu 15.04 64-bit

Please try to compile it directly via command-line, to exclude a
frescobaldi-issue.


Cheers,
  Harm

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

weird fill-line behavior

[Mike Solomon]

Hey all,

Any suggestions how to get even spacing in the example below?
It is bunching up in all sorts of unpredictable ways...

Cheers,
~Mike

\version "2.19.30"

#(set-default-paper-size "a4" 'landscape)
#(set-global-staff-size 15.15)
themeA = {
  \time 3/4
  c4 d e |
  f e d |
  c2 r4 |
}

themeB = {
  c4 d e |
  f e d |
  c2 r4 |
}

themeC = {
  c2 c4 |
  c'2 c'4 |
  a2 a4 |
  b2 b4 |
  c'4 c' c' |
  c' b a |
  g2. |
}

themeD = {
  g4 g g |
  g g e' |
  f f f |
  f f d' |
  d dis e |
  f e d |
  g2. |
}

themes = {
  \themeA
  \themeB
  \themeC
  \themeD
}

lyr = \lyricmode { Fol -- low the yel -- low brick road. Fol -- low the yel -- 
low brick road. 
Fol -- low fol -- low fol -- low fol -- low fol -- low the yel -- low brick 
road.
Fol -- low the yel -- low brick, fol -- low the yel -- low brick,
fol -- low the yel -- low brick road
} 
\markup \fill-line {
  \column {
"Wysr"
\score { << \new Staff \new Voice = "foo" { \clef bass \transpose c e, 
\themes } \new Lyrics \lyricsto "foo" \lyr >> \layout { line-width = #50 } }
  }
  \column {
"Wysr"
\score { << \new Staff \new Voice = "foo" { \clef bass \transpose c e, 
\themes } \new Lyrics \lyricsto "foo" \lyr >> \layout { line-width = #50 } }
  }
  \column {
"Wysr"
\score { << \new Staff \new Voice = "foo" { \clef bass \transpose c e, 
\themes } \new Lyrics \lyricsto "foo" \lyr >> \layout { line-width = #50 } }
  }
  \column {
"Wysr"
\score { << \new Staff \new Voice = "foo" { \clef bass \transpose c e, 
\themes } \new Lyrics \lyricsto "foo" \lyr >> \layout { line-width = #50 } }
  }
  \column {
"Wysr"
\score { << \new Staff \new Voice = "foo" { \clef bass \transpose c e, 
\themes } \new Lyrics \lyricsto "foo" \lyr >> \layout { line-width = #50 } }
  }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: weird fill-line behavior

[Noeck]

Hi Mike,

I replaced \fill-line with \justify-line and it looks much better.

This is mentioned in the change log:
http://lilypond.org/doc/v2.19/Documentation/changes/index.html
It looks like it causes the space between columns to be equal instead of
the centres. This is only available since some 2.19 version.

Cheers,
Joram

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

Re: cross-staff stems for only two of three staves

[Malte Meyn]

Am 20.11.2015 um 20:50 schrieb Malte Meyn:

Hi list,

I would like to set cross staff stems in a three-staff piano score. With
stems from the middle to lower or upper staff everything works fine but
not the other way (from outer to middle staff). Does anyone have an idea
how to fix that or work around?



Ok, here’s my dirty hack:
\once \override NoteColumn.X-offset = 0.0001
in the staff that shouldn’t be connected to the cross staff stem.

That works (the offset is so small you don’t see it) but it would be 
nice if there was a clean solution.



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

Re: weird fill-line behavior

[David Nalesnik]

Hi Mike,

On Wed, Nov 25, 2015 at 2:40 PM, Mike Solomon  wrote:

> Hey all,
>
> Any suggestions how to get even spacing in the example below?
> It is bunching up in all sorts of unpredictable ways...


Sure, use \justify-line, which equalizes the space between markups.
 \fill-line really only works well with a maximum of three markups on a
line.

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

Re: weird fill-line behavior

[Mike Solomon]

On Nov 25, 2015, at 9:49 PM, Noeck  wrote:
> 
> Hi Mike,
> 
> I replaced \fill-line with \justify-line and it looks much better.
> 
> This is mentioned in the change log:
> http://lilypond.org/doc/v2.19/Documentation/changes/index.html
> It looks like it causes the space between columns to be equal instead of
> the centres. This is only available since some 2.19 version.
> 
> Cheers,
> Joram
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user 
> 

rock - thanks!
~Mike


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

Re: [Best Practices] splitting and combining choral parts

[tyronicus]

Kieren wrote
> I’ve posted this question several times before, but the discussion always
> got truncated or derailed… I’m hoping this time we can work this through
> to a solution.

Simon and Michael, you make interesting points; yet, as an observer, I
submit that the topic has been derailed again. Can we focus on how to
achieve automatic frenching based on divisi?

Kieren, this seems like a lot of work. It sounds like we want Lily to look
at the line she's working on and decide whether some of the staves can be
combined based on the content they have. There would be a bunch of rules to
follow (do you allow Lily to combine when pitches are different but rhythms
are the same? what about a short melisma in one voice but not in the other;
would you split a whole line over that? Do you allow the alto staff and
tenor staff to combine for S/AT/B?). An ideal solution would have to allow
the user to turn certain rules on or off. This seems like complex
programming to me.

My question is, would a solution that requires user intervention be
acceptable? For example, a switch like \separateStaves which would force
staves to be separated from the beginning of the current line, and a
corresponding \combineStaves which would tell Lily to begin combining at the
next line break. You would also have to specify which staves to combine.
This puts the burden of decision on the user, hopefully simplifying the
programming. Then, Lily just has to create a new Staff, use \partcombine,
and assign lyrics to the voice.



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Best-Practices-splitting-and-combining-choral-parts-tp184051p184123.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: Strange LilyPond crash

[Edward Ardzinski]

Here's the file... Edski-2015-11-16_v4_test.ly

  



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Strange-LilyPond-crash-tp183610p184124.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: Layout of a (piano) hand indicator

[David Kastrup]

Robin Bannister  writes:

> David Kastrup wrote:
>
>> See issue 4671: probably as of version 2.19.33, convert-ly should be
>> able to do this by itself.  Another possibility is to not use
>> ly:music-function-extract at all but rather write
>>
>> #{ \whateveritwas ... #}
>>
>> here.  That should be fairly convertible.
>>
>
> OK. I had to pay a two dollar streamlining fee though.
>
>
> thumbBracket = #(define-music-function (spec) (string?)
>  (let ((settings thumbBracketSettings)) ;% as Defaults, or user defined
> #{ \thumbBracketEx $spec $settings #}))

2.18.2 requires (define-music-function (parser location spec) ...

The first version to allow (define-music-function (spec) ... is 2.19.22
and the first version to allow (thumbBracketEx spec settings) is 2.19.22
as well.  So if you drop the "parser location" arguments, there is no
point in not calling thumbBracketEx directly.

Of course, the `let' is spurious.  You can just use thumbBracketSettings
directly instead of settings.  Probably as of 2.14 or something.  So
either way there are some more possible streamlinings even when writing
for 2.18.

-- 
David Kastrup

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

PDF portfolio of 2.19.32 docs

[Nick Payne]

A fully indexed portfolio of the 2.19.32 PDF docs is available at 
https://www.dropbox.com/s/0iu46b26w0rfnk7/Lilydoc-2.19.32.pdf?dl=0 (39Mb).


Needs Adobe Reader for the indexing to work - I haven't found a 3rd 
party PDF viewer that can use the index in PDF portfolios.


Nick

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

Re: Layout of a (piano) hand indicator

[Jacques Menu]

Hello Urs,

The horizontal part is not visible if the note head lies on a line:

{
  \set fingeringOrientations = #'(left)
   8
}

{
  \set fingeringOrientations = #'(left)
   8
}

JM

> Le 24 nov. 2015 à 23:44, Urs Liska  a écrit :
> 
> 
> 
> Am 24.11.2015 um 22:39 schrieb Simon Albrecht:
>> On 24.11.2015 18:49, Urs Liska wrote:
>>> Hi all,
>>> 
>>> please consider the attached image, especially the "half-bracket" at the
>>> center. This is to indicate that this d' is to be played with the
>>> left hand.
>>> 
>>> Is there anything I could improve to the proportions and placement of
>>> that sign?
>>> 
>>> Any suggestions for improvement welcome. Suggestions for *not* improving
>>> it even more ;-)
>> 
>> I agree that it looks quite good, and that the vertical part should be
>> shorter. Also, the horizontal part could be longer in my eyes.
>> And I’d be very interested in how you did it :-)
>> 
> 
> I use a very simple \path. Originally I simply added it as a \markup and
> used extra-offset to position it. But thanks to Abraham's blog post I
> changed that to use a fingering indication. However, I'm not really sure
> this is more reliable (for example against transposition):
> 
> So this is what it looks like now:
> 
> \set fingeringOrientations = #'(left)
>  \markup {
>  \path #0.175
>  #'((moveto 0 -2)
> (rlineto 0 3)
> (rlineto 0.85 0)
> (moveto -1.5 2)) } > 8
> 
> Urs
> 
>> Yours, Simon
> 
> ___
> 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

IR issues (was: Property/ies to control the shape of ties/slurs)

[Urs Liska]

Am 23.11.2015 um 11:20 schrieb David Kastrup:
> Urs Liska  writes:
>
>> Am 23.11.2015 um 10:39 schrieb David Kastrup:
>>> Urs Liska  writes:
>>>
 I don't seem to be able to find the right property to control the shape
 of ties.

 I would like to make the default appearance of ties less flat than what
 you see in the first attachment. I *think* what I want is having a
 steeper slope. But reading through the IR for tie and tie-interface I
 didn't see anything.

 Using
 \shape #'((0 . 0) (0 . .75) (0 . .75) (0 . 0)) Tie

 results in the second attachment, which is what I'd like to achieve. But
 I don't want to use \shape but set some properties so I can put it in a
 stylesheet.

 Any suggestions?
>>> Uh, \shape ... Tie _is_ an override.  You don't get closer to "set some
>>> properties" than that.
>>>
>> Maybe I wasn't clear: I want to alter the default shape of ties to have
>> a steeper slope. \shape is not an override but a \once \override and has
>> to be applied to individual ties. But I want to change the appearance in
>> a stylesheet.
> \once is ignored in context definitions/modifications.
>
> At any rate, you can also play with settings height-limit and ratio.

OK, I've now found out how height-limit and ratio play together.
Actually ratio is the setting to deal with the behaviour of curves of
different length.

Interestingly I have to override Slur.height-limit but
Tie.details.height-limit

But looking for another property of Slurs and Ties leads me to another
question:
Is this:
http://lilypond.org/doc/v2.19/Documentation/internals/slur
and
http://lilypond.org/doc/v2.19/Documentation/internals/slur_002dinterface

really the reference for how I can change the appearance of slurs and ties?

If that's true I think it's really awful. I know the IR is a *reference*
and not a tutorial but I'm sure that *noone* will be able to look up the
information for tweaks they need anything near efficiently. The majority
of properties is described in a completely inaccessible manner.

"

|same-slope-penalty|

Demerit for slurs with attachment points that are horizontally aligned."



What the heck does that mean?

Or
"

|absolute-closeness-measure|

Factor to calculate demerit for variance between a note head and slur.

"

Huh?

And even a more "humane" item like
"

|ratio| (number)

Parameter for slur shape. The higher this number, the quicker the
slur attains its |height-limit|.

"
Is actually ambiguous, to say the least. When I read this I expected
that this controls the steepness at the edges of the slur. But
effectively it controls *if* the slur reaches its "height-limit" at all:
shorter slurs don't and longer do.


The point is: if the descriptions of the properties are that cryptic the
user can only find out by trial-and-error. Which is significantly
constrained through the fact that often there's *no* visible change when
changing a value because that property only works in conjunction with
another one or only in certain graphical situations.

Summing up: I find it practically impossible to use the NR efficiently
for learning about the possibilities for tweaking LilyPond's layout. I
have also re-read the respective sections of the Learning Manual and
they are of no help. While they lead through the basic use of the IR
they don't help anything with the issues outlined above.

*Is* there any material around that goes beyond the IR at all?
Or would we need in-depth tutorial-style explanations for at least the
more important notation items?

So far I've always kept away from touching these internals and somehow
assumed I was too dumb or - more probable - too lazy to follow the trail
of information. But now I have the impression there is really something
fundamental missing.
I would say: While we claim to provide automatic engraving most of the
time things like tweaking properties of common objects such as slurs, or
barlines, or beams etc. should really be accessible for the user and not
hidden away behind truly cryptic docstrings.

Urs


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

Re: Layout of a (piano) hand indicator

[Urs Liska]

Am 25.11.2015 um 11:26 schrieb Jacques Menu:
> Hello Urs,
>
> The horizontal part is not visible if the note head lies on a line:

I know that and therefore I wouldn't consider this a proper solution.
If I would want to make that a generally usable tool I would have to
think about some logic to support this.
But in the score at hand I just need that once ...

Urs

>
> {
>   \set fingeringOrientations = #'(left)
>      \markup {
> \path #0.175
> #'((moveto 0 -2)
>(rlineto 0 3)
>(rlineto 0.85 0)
>(moveto -1.5 2))
>   } > 8
> }
>
> {
>   \set fingeringOrientations = #'(left)
>      \markup {
> \path #0.175
> #'((moveto 0 -2)
>(rlineto 0 3)
>(rlineto 0.85 0)
>(moveto -1.5 2))
>   } > 8
> }
>
> JM
>
>> Le 24 nov. 2015 à 23:44, Urs Liska  a écrit :
>>
>>
>>
>> Am 24.11.2015 um 22:39 schrieb Simon Albrecht:
>>> On 24.11.2015 18:49, Urs Liska wrote:
 Hi all,

 please consider the attached image, especially the "half-bracket" at the
 center. This is to indicate that this d' is to be played with the
 left hand.

 Is there anything I could improve to the proportions and placement of
 that sign?

 Any suggestions for improvement welcome. Suggestions for *not* improving
 it even more ;-)
>>> I agree that it looks quite good, and that the vertical part should be
>>> shorter. Also, the horizontal part could be longer in my eyes.
>>> And I’d be very interested in how you did it :-)
>>>
>> I use a very simple \path. Originally I simply added it as a \markup and
>> used extra-offset to position it. But thanks to Abraham's blog post I
>> changed that to use a fingering indication. However, I'm not really sure
>> this is more reliable (for example against transposition):
>>
>> So this is what it looks like now:
>>
>> \set fingeringOrientations = #'(left)
>> > \markup {
>>  \path #0.175
>>  #'((moveto 0 -2)
>> (rlineto 0 3)
>> (rlineto 0.85 0)
>> (moveto -1.5 2)) } > 8
>>
>> Urs
>>
>>> Yours, Simon
>> ___
>> 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: Layout of a (piano) hand indicator

[Thomas Morley]

2015-11-25 11:42 GMT+01:00 Urs Liska :
>
>
> Am 25.11.2015 um 11:26 schrieb Jacques Menu:
>> Hello Urs,
>>
>> The horizontal part is not visible if the note head lies on a line:
>
> I know that and therefore I wouldn't consider this a proper solution.
> If I would want to make that a generally usable tool I would have to
> think about some logic to support this.
> But in the score at hand I just need that once ...
>
> Urs



There's Robin's approach:
http://lists.gnu.org/archive/html/lilypond-user/2009-07/msg00536.html

Although it does not compile with 2.19.32 even after running convert-ly.
I assume it wouldn't be that hard to do the remaining manually, right
now I've not the time, though...

Cheers,
  Harm

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

Re: Layout of a (piano) hand indicator

[David Kastrup]

Thomas Morley  writes:

> 2015-11-25 11:42 GMT+01:00 Urs Liska :
>>
>>
>> Am 25.11.2015 um 11:26 schrieb Jacques Menu:
>>> Hello Urs,
>>>
>>> The horizontal part is not visible if the note head lies on a line:
>>
>> I know that and therefore I wouldn't consider this a proper solution.
>> If I would want to make that a generally usable tool I would have to
>> think about some logic to support this.
>> But in the score at hand I just need that once ...
>>
>> Urs
>
>
>
> There's Robin's approach:
> http://lists.gnu.org/archive/html/lilypond-user/2009-07/msg00536.html
>
> Although it does not compile with 2.19.32 even after running convert-ly.
> I assume it wouldn't be that hard to do the remaining manually, right
> now I've not the time, though...

You have to replace one instance of

((ly:music-function-extract whateveritwas) (*parser*) (*location*) ...)

with

(whateveritwas ...)

Maybe ly:music-function-extract should have been renamed altogether when
removing the parser/location arguments so that one could have provided a
compatibility wrapper under that name.

I'm not sure how often this will be an issue, though.

-- 
David Kastrup

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

Re: Layout of a (piano) hand indicator

[David Kastrup]

David Kastrup  writes:

> Thomas Morley  writes:
>
>> 2015-11-25 11:42 GMT+01:00 Urs Liska :
>>>
>>>
>>> Am 25.11.2015 um 11:26 schrieb Jacques Menu:
 Hello Urs,

 The horizontal part is not visible if the note head lies on a line:
>>>
>>> I know that and therefore I wouldn't consider this a proper solution.
>>> If I would want to make that a generally usable tool I would have to
>>> think about some logic to support this.
>>> But in the score at hand I just need that once ...
>>>
>>> Urs
>>
>>
>>
>> There's Robin's approach:
>> http://lists.gnu.org/archive/html/lilypond-user/2009-07/msg00536.html
>>
>> Although it does not compile with 2.19.32 even after running convert-ly.
>> I assume it wouldn't be that hard to do the remaining manually, right
>> now I've not the time, though...
>
> You have to replace one instance of
>
> ((ly:music-function-extract whateveritwas) (*parser*) (*location*) ...)
>
> with
>
> (whateveritwas ...)
>
> Maybe ly:music-function-extract should have been renamed altogether when
> removing the parser/location arguments so that one could have provided a
> compatibility wrapper under that name.
>
> I'm not sure how often this will be an issue, though.

I'll try to see whether I can convert direct calls of the result from
ly:music-function-extract in convert-ly, though.

-- 
David Kastrup

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

Re: IR issues

[David Kastrup]

Urs Liska  writes:

> Am 23.11.2015 um 11:20 schrieb David Kastrup:
>
>> At any rate, you can also play with settings height-limit and ratio.
>
> OK, I've now found out how height-limit and ratio play together.
> Actually ratio is the setting to deal with the behaviour of curves of
> different length.
>
> Interestingly I have to override Slur.height-limit but
> Tie.details.height-limit
>
> But looking for another property of Slurs and Ties leads me to another
> question:
> Is this:
> http://lilypond.org/doc/v2.19/Documentation/internals/slur
> and
> http://lilypond.org/doc/v2.19/Documentation/internals/slur_002dinterface
>
> really the reference for how I can change the appearance of slurs and ties?
>
> If that's true I think it's really awful. I know the IR is a *reference*
> and not a tutorial but I'm sure that *noone* will be able to look up the
> information for tweaks they need anything near efficiently. The majority
> of properties is described in a completely inaccessible manner.

The IR is a programmers' reference.  For power users, it's more like a
last resort.  Of course that does not mean that incomprehensible
documentation strings are a feature rather than a problem, but it does
mean that
a) the organization of properties in a user-friendly way is not a
priority: end users should rather get stuff like \shape to work with, or
style files (which we don't really have).
b) reworking this into a consistently friendly resource where each
property description is reasonably understandable on its own is a large
chunk of work.  Some fly-by fixes will not suffice for making a dent in
the overall character of the IR.

-- 
David Kastrup

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

Re: Layout of a (piano) hand indicator

[David Kastrup]

Robin Bannister  writes:

> On 25.11.2015 12:32, David Kastrup wrote:
>> Thomas Morley  writes:
>> [...]
>>> There's Robin's approach:
>>> http://lists.gnu.org/archive/html/lilypond-user/2009-07/msg00536.html
>>>
>>> Although it does not compile with 2.19.32 even after running convert-ly.
>>> I assume it wouldn't be that hard to do the remaining manually, right
>>> now I've not the time, though...
>>
>> You have to replace one instance of
>>
>> ((ly:music-function-extract whateveritwas) (*parser*) (*location*) ...)
>
> Done - cf thumbBracket.ily
>
> I'm still on 2.18.2, but I made an exception here.

See issue 4671: probably as of version 2.19.33, convert-ly should be
able to do this by itself.  Another possibility is to not use
ly:music-function-extract at all but rather write

#{ \whateveritwas ... #}

here.  That should be fairly convertible.

-- 
David Kastrup

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

Repeat with Alternative on First Time

[Michael Hartl]

Dear Lilypond Experts,

this is my first time posting to this list. I am trying my hand at 
engraving a song with a perhaps unusual, but very simple repeat pattern

and I couldn't find out how to come to the correct result from the manuel.

The melody goes like this:


  
  

It should be set like:

 [1.  ] [2.-3. second-third-time>] 


Right now, I do:
\repeat volta 3 {} \alternative {{time>} {}} 


But, this gives me "1.-2." and "3." instead of "1." and "2.-3." for the 
alternative endings. This looks like it ought to be easy to correct, but 
I can't figure it out.


How can it be done?

Also, \repeat itself is actually wrong, because the verse is not 
repeated before the chorus. Is there any way to use \alternative
without \repeat? A \repeat over the entire song would be acceptable, but 
then again I can't use \alternative in the middle of

\repeat, but only at the end.

Thank you
Mike

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

Re: Repeat with Alternative on First Time

[David Wright]

On Wed 25 Nov 2015 at 13:57:40 (+0100), Michael Hartl wrote:
> Dear Lilypond Experts,

Not me, then.

> this is my first time posting to this list. I am trying my hand at
> engraving a song with a perhaps unusual, but very simple repeat
> pattern
> and I couldn't find out how to come to the correct result from the manuel.
> 
> The melody goes like this:
> 
> 
>   
>   
> 
> It should be set like:
> 
>  [1.  ] [2.-3.  ending second-third-time>] 
> 
> Right now, I do:
> \repeat volta 3 {} \alternative {{ first time>} {}} 
> 
> But, this gives me "1.-2." and "3." instead of "1." and "2.-3." for
> the alternative endings. This looks like it ought to be easy to
> correct, but I can't figure it out.
> 
> How can it be done?

You could look at
http://lists.gnu.org/archive/html/lilypond-user/2015-10/msg00404.html
for hints. You can probably ignore the lines that are concerned with
placing the volta brackets mid-bar which is ill-advised (but was
part of that challenge).

> Also, \repeat itself is actually wrong, because the verse is not
> repeated before the chorus. Is there any way to use \alternative
> without \repeat? A \repeat over the entire song would be acceptable,
> but then again I can't use \alternative in the middle of
> \repeat, but only at the end.

Because it doesn't fit the normal repeat structure, you lose the
ability to unfold the repeat automatically; eg in an associated
midi file, the alternatives will just be played consecutively.

Cheers,
David.

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

Re: Repeat with Alternative on First Time

[Robert Schmaus]

Hi Mike,

this is actually covered in the Notation Reference, more precisely, 
right there:


http://lilypond.org/doc/v2.18/Documentation/notation/long-repeats#manual-repeat-marks

Best,
Robert



Am 25/11/15 um 13:57 schrieb Michael Hartl:

Dear Lilypond Experts,

this is my first time posting to this list. I am trying my hand at
engraving a song with a perhaps unusual, but very simple repeat pattern
and I couldn't find out how to come to the correct result from the manuel.

The melody goes like this:


  
  

It should be set like:

 [1.  ] [2.-3. ] 

Right now, I do:
\repeat volta 3 {} \alternative {{} {}} 

But, this gives me "1.-2." and "3." instead of "1." and "2.-3." for the
alternative endings. This looks like it ought to be easy to correct, but
I can't figure it out.

How can it be done?

Also, \repeat itself is actually wrong, because the verse is not
repeated before the chorus. Is there any way to use \alternative
without \repeat? A \repeat over the entire song would be acceptable, but
then again I can't use \alternative in the middle of
\repeat, but only at the end.

Thank you
Mike

___
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: Repeat with Alternative on First Time

[Robert Schmaus]

Actually, what seems to work (although I'm not positive that this is all 
correct, so check if this causes problems down the road, i.e. in th 
chorus part) is this:


\repeat volta 2 {
  c4 d e f
}
\alternative{
{
	\set Score.repeatCommands = #'((volta #f) (volta "1.") 
begin-repeat)	

g a b c
}
{
\set Score.repeatCommands = #'((volta #f) (volta "2.-3.") end-repeat)
g f e d
}
}

Best, Robert



Am 25/11/15 um 14:41 schrieb Robert Schmaus:

Hi Mike,

this is actually covered in the Notation Reference, more precisely,
right there:

http://lilypond.org/doc/v2.18/Documentation/notation/long-repeats#manual-repeat-marks


Best,
Robert



Am 25/11/15 um 13:57 schrieb Michael Hartl:

Dear Lilypond Experts,

this is my first time posting to this list. I am trying my hand at
engraving a song with a perhaps unusual, but very simple repeat pattern
and I couldn't find out how to come to the correct result from the
manuel.

The melody goes like this:


  
  

It should be set like:

 [1.  ] [2.-3. ] 

Right now, I do:
\repeat volta 3 {} \alternative {{} {}} 

But, this gives me "1.-2." and "3." instead of "1." and "2.-3." for the
alternative endings. This looks like it ought to be easy to correct, but
I can't figure it out.

How can it be done?

Also, \repeat itself is actually wrong, because the verse is not
repeated before the chorus. Is there any way to use \alternative
without \repeat? A \repeat over the entire song would be acceptable, but
then again I can't use \alternative in the middle of
\repeat, but only at the end.

Thank you
Mike

___
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


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

Re: IR issues

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: "Urs Liska" 
Cc: "lilypond-user" 
Sent: Wednesday, November 25, 2015 11:48 AM
Subject: Re: IR issues



Urs Liska  writes:


Am 23.11.2015 um 11:20 schrieb David Kastrup:


At any rate, you can also play with settings height-limit and ratio.


OK, I've now found out how height-limit and ratio play together.
Actually ratio is the setting to deal with the behaviour of curves of
different length.

Interestingly I have to override Slur.height-limit but
Tie.details.height-limit

But looking for another property of Slurs and Ties leads me to another
question:
Is this:
http://lilypond.org/doc/v2.19/Documentation/internals/slur
and
http://lilypond.org/doc/v2.19/Documentation/internals/slur_002dinterface

really the reference for how I can change the appearance of slurs and 
ties?


If that's true I think it's really awful. I know the IR is a *reference*
and not a tutorial but I'm sure that *noone* will be able to look up the
information for tweaks they need anything near efficiently. The majority
of properties is described in a completely inaccessible manner.


The IR is a programmers' reference.  For power users, it's more like a
last resort.  Of course that does not mean that incomprehensible
documentation strings are a feature rather than a problem, but it does
mean that
a) the organization of properties in a user-friendly way is not a
priority: end users should rather get stuff like \shape to work with, or
style files (which we don't really have).
b) reworking this into a consistently friendly resource where each
property description is reasonably understandable on its own is a large
chunk of work.  Some fly-by fixes will not suffice for making a dent in
the overall character of the IR.



Don't agree with that.  It seems to me that if someone looks at some 
doc-strings, finds them incomprehensible and then comes up with a patch that 
makes them better, then we're moving forward, albeit slowly.  I think it 
would be beneficial if Urs could propose a patch that will fix this issue. 
Others can do the same as they come across them.


--
Phil Holmes 



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

Re: Repeat with Alternative on First Time

[David Wright]

On Wed 25 Nov 2015 at 14:41:57 (+0100), Robert Schmaus wrote:
> Hi Mike,
> 
> this is actually covered in the Notation Reference, more precisely,
> right there:
> 
> http://lilypond.org/doc/v2.18/Documentation/notation/long-repeats#manual-repeat-marks

I disagree. What's missing is the notation to cover this bit of the
OP's structure:

 [1. <1st alt> ] [2.-3. <2nd/3rd alts>] 
  

ie indicating where the chorus starts. Unfortunately the solution is a
bit of a hack. IIRC the most flexible way of ameliorating the hack is:

http://lists.gnu.org/archive/html/lilypond-user/2015-10/msg00460.html

Cheers,
David.

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

Re: Repeat with Alternative on First Time

[Pierre Perol-Schneider]

Hi Mike,

See: http://lsr.di.unimi.it/LSR/Item?id=915

Cheers,
~Pierre

2015-11-25 15:25 GMT+01:00 Michael Hartl :

> Hi Robert,
>
> thank you for pointing me to this bit of the manual. Somehow I overlooked
> it even though I scanned
> the page at least twice.
>
> I did it like this now and the result is satisfactory (apart from midi):
> \set Score.repeatCommands = #'((volta "1."))
> ...
> \bar "||"
> \set Score.repeatCommands = #'((volta "2.-3."))
> ...
> \bar "||"
> \set Score.repeatCommands = #'((volta #f))
> \break
> ...chorus...
>
> Yes, it's a bit hackish, but it looks alright.
>
> Thanks to all the others for the suggestions, too!
>
> Best Wishes
> Mike
>
>
> On 2015-11-25 14:41, Robert Schmaus wrote:
>
>> Hi Mike,
>>
>> this is actually covered in the Notation Reference, more precisely, right
>> there:
>>
>>
>> http://lilypond.org/doc/v2.18/Documentation/notation/long-repeats#manual-repeat-marks
>>
>> Best,
>> Robert
>>
>>
>>
>> Am 25/11/15 um 13:57 schrieb Michael Hartl:
>>
>>> Dear Lilypond Experts,
>>>
>>> this is my first time posting to this list. I am trying my hand at
>>> engraving a song with a perhaps unusual, but very simple repeat pattern
>>> and I couldn't find out how to come to the correct result from the
>>> manuel.
>>>
>>> The melody goes like this:
>>>
>>> 
>>>   
>>>   
>>>
>>> It should be set like:
>>>
>>>  [1.  ] [2.-3. >> second-third-time>] 
>>>
>>> Right now, I do:
>>> \repeat volta 3 {} \alternative {{>> time>} {}} 
>>>
>>> But, this gives me "1.-2." and "3." instead of "1." and "2.-3." for the
>>> alternative endings. This looks like it ought to be easy to correct, but
>>> I can't figure it out.
>>>
>>> How can it be done?
>>>
>>> Also, \repeat itself is actually wrong, because the verse is not
>>> repeated before the chorus. Is there any way to use \alternative
>>> without \repeat? A \repeat over the entire song would be acceptable, but
>>> then again I can't use \alternative in the middle of
>>> \repeat, but only at the end.
>>>
>>> Thank you
>>> Mike
>>>
>>> ___
>>> 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
>>
>
>
> ___
> 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: Repeat with Alternative on First Time

[Michael Hartl]

Hi Robert,

thank you for pointing me to this bit of the manual. Somehow I 
overlooked it even though I scanned

the page at least twice.

I did it like this now and the result is satisfactory (apart from midi):
\set Score.repeatCommands = #'((volta "1."))
...
\bar "||"
\set Score.repeatCommands = #'((volta "2.-3."))
...
\bar "||"
\set Score.repeatCommands = #'((volta #f))
\break
...chorus...

Yes, it's a bit hackish, but it looks alright.

Thanks to all the others for the suggestions, too!

Best Wishes
Mike

On 2015-11-25 14:41, Robert Schmaus wrote:

Hi Mike,

this is actually covered in the Notation Reference, more precisely, 
right there:


http://lilypond.org/doc/v2.18/Documentation/notation/long-repeats#manual-repeat-marks 



Best,
Robert



Am 25/11/15 um 13:57 schrieb Michael Hartl:

Dear Lilypond Experts,

this is my first time posting to this list. I am trying my hand at
engraving a song with a perhaps unusual, but very simple repeat pattern
and I couldn't find out how to come to the correct result from the 
manuel.


The melody goes like this:


  
  

It should be set like:

 [1.  ] [2.-3. ] 

Right now, I do:
\repeat volta 3 {} \alternative {{} {}} 

But, this gives me "1.-2." and "3." instead of "1." and "2.-3." for the
alternative endings. This looks like it ought to be easy to correct, but
I can't figure it out.

How can it be done?

Also, \repeat itself is actually wrong, because the verse is not
repeated before the chorus. Is there any way to use \alternative
without \repeat? A \repeat over the entire song would be acceptable, but
then again I can't use \alternative in the middle of
\repeat, but only at the end.

Thank you
Mike

___
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



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

Re: Layout of a (piano) hand indicator

[Robin Bannister]

David Kastrup wrote:


See issue 4671: probably as of version 2.19.33, convert-ly should be
able to do this by itself.  Another possibility is to not use
ly:music-function-extract at all but rather write

#{ \whateveritwas ... #}

here.  That should be fairly convertible.



OK. I had to pay a two dollar streamlining fee though.


thumbBracket = #(define-music-function (spec) (string?)
 (let ((settings thumbBracketSettings)) ;% as Defaults, or user defined
#{ \thumbBracketEx $spec $settings #}))



Cheers,
Robin

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

Re: aligning melisma and non-melisma lyrics across staves in the same system

[David Wright]

On Wed 25 Nov 2015 at 12:01:44 (-0500), Kieren MacMillan wrote:

> I know there is a way to have accidentals “cross-canceled” between staves in 
> the same system.
> (I’ve used it… and it’s wonderful!)

I don't; what is it?

> Would it be similarly possible to have lyrics aligned between staves
> when one or more of the lyrics is melisma-attached (and is thus
> automatically left-aligned, according to the value of
> lyricMelismaAlignment) and one or more lyrics is not (and is thus
> centred, generally)? 

I don't like it myself. But do you mean doing this manually or
automatically? For the former, I just have
ll = \lyricmode { \once \override LyricText.self-alignment-X = #LEFT }
cc = \lyricmode { \once \override LyricText.self-alignment-X = #CENTER }
rr = \lyricmode { \once \override LyricText.self-alignment-X = #RIGHT }
defined and put \ll before such lyrics.

As for automatically, I can think of a couple of wishlist items that
would be far more useful to most people, and are related to this:

1) If there's a lyric extender on a lyric which is being attached to a
non-melisma note, ignore it. This would often save having four sets
of SATB lyrics differing only in each ones placement of extenders.

2) Given one set of lyrics and two or more voices of notes to attach
them to, left-align the lyric and don't ignore the extender (as in (1)
above) whenever any of the notes for that lyric has a melisma, and
extend the extender to the last melisma moment in any of the voices.

Currently I do (2) with NullVoice, but it's quite tedious manually
subdividing notes and adding ties to get the necessary effect.

Cheers,
David.

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