Re: the custos: understanding how it works

[Leszek Wroński]

Guys (David, Thomas, Jacques),

thank you very much for the responses. I'll read the Contributor's Guide
and see if I can have more specific questions in the future.
And Jacques, no worries! Your example was still useful to me as it helped
me to realise some things ;)

Cheers,

Leszek.

On 22 November 2015 at 18:41, David Kastrup  wrote:

> Leszek Wroński  writes:
>
> > I was delighted to learn that Lilypond allows one to use custodes. I was
> > wondering how they really work, namely, how one can, upon a linebreak,
> > check what the next pitch is.  I have limited Scheme experience.
>
> > source code, and after grepping found two files of interest: custos.cc
> > and custos-engraver.cc . In the latter I found an expression headed by
> >
> > "void
> >  Custos_engraver::acknowledge_note_head (Grob_info info)"
> >
> > (line 83). Could anyone tell me if I'm on the right track?
>
> Sort of.  That's where the Custos_engraver sees graphical objects that
> have been declared to have a note-head-interface pass into the current
> score.
>
> > My problem is that, while I'm willing to learn, I have a very limited
> > experience with C++ and with any object programming whatsoever (having
> > spent much time decades ago with Turbo Pascal 5 :-)).
>
> Well, imagine how frustrating it would be if you were a gee-whiz
> C++ programmer and still couldn't tell the stuff LilyPond does from
> Turbo Pascal 5.  C++ knowledge actually does not buy you all that much
> for reading the source code.
>
> > I'd be very grateful for any pointers regarding what happens during a
> > linebreak (and, in general, how one should learn such things).
>
> I'd take a look at the Contributor's Guide first: there are a few
> sketches of code workings in it.  There is a file ROADMAP in the
> repository that points out what kind of code is grouped into which
> directories.
>
> Other than that, it's mostly reading code and asking back on the list.
>
> --
> David Kastrup
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: missing stem

[Simon Albrecht]

Hello Bogi,

On 23.11.2015 00:50, Bogi Lützen wrote:

Please help me with this little problem.

This is just one of my efforts, but in all of them I miss the stem on the
first g'2:

\version "2.18.0"

{

<<{c''1^~|\stemUp c''2 c''4 c''| c''1}{\stemDown g'2 a' |g' a'4 a'| 
g'1}>>


\bar "|."
}


first: your code example can be made much easier to read if you add some 
spaces and line breaks, and get indenting right (this is done 
automatically by Frescobaldi, a great program for working with LilyPond 
files ):


%%%
{
  <<
{
  c''1^~ |
  \stemUp c''2 c''4 c'' |
  c''1
}
{
  \stemDown g'2 a' |
  g' a'4 a' |
  g'1
}
  >>
  \bar "|."
}
%%%

If you run your snippet, you should get three warnings in the log, one 
of them saying that ‘maybe your input should specify polyphonic voices’. 
And that is the problem here: your code only produces only one ‘voice’ 
(in the LilyPond sense of the word) and you need two of them.
The most basic way to achieve that is inserting \\ between the music 
expressions:


%%%
{
  <<
{
  c''1^~ |
  \stemUp c''2 c''4 c'' |
  c''1
}
\\
{
  \stemDown g'2 a' |
  g' a'4 a' |
  g'1
}
  >>
  \bar "|."
}


This will work in this small example. In any more complex situations, 
you should create voices explicitly with \new Voice, and distinguish 
them by \voiceOne, \voiceTwo etc.


Did you read the Learning Manual 
 already? It gives 
a great, ‘must-read’ introduction into working with LilyPond.


H(ope)T(hat)H(elps),
Simon

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

Re: missing stem

[Kieren MacMillan]

Hi Bogi,

> in all of them I miss the stem on the first g’2:

Perhaps you mean

  SNIPPET BEGINS
\version "2.18.0"

theMusic = {
  <<
{ \voiceOne c''1 ~ | c''2 }
\new Voice { \voiceTwo g'2 a' | g'2 }
  >> \oneVoice 4 q |
  1
  \bar "|."
}

\score {
  \new Staff \theMusic
}
  SNIPPET BEGINS

Note how I use the \voiceOne, \voiceTwo, and \oneVoice commands to take 
advantage of Lilypond’s built-in polyphony mechanisms.

Hope this helps!
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: missing stem

[Andrew Bernard]

Hi Bogi,

You need to use the parallel voices correctly. The two voices need  ‘\\‘ 
between them.

  <<{c''1^~|\stemUp c''2 c''4 c''| c'’1} \\ {\stemDown g'2 a' |g' a'4 a'| g'1}>>

You can also use \new Voice. Have a look in the Notation Reference manual under 
Multiple Voices.

I thought 2.18.2 was the stable version. Any reason to use 2.18.0?

Allow me also to recommend the development releases - in general they are of 
excellent quality and really very stable for most practical purposes.

Andrew




On 23/11/2015, 10:50, "Bogi Lützen" 
 wrote:



This is just one of my efforts, but in all of them I miss the stem on the
first g'2:



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

Re: Gounod - Le Rendez Vous

[Simon Albrecht]

On 22.11.2015 22:41, Alberto Simões wrote:

Hi all,

Final version here:

https://github.com/ambs/music/blob/master/Gounod/LeRendezVous/suite.pdf

Will submit it to IMSLP later to the end of the week, in case anybody 
spots any critical issue.


The last measure of the Introduction actually has only two quarters (the 
half note isn’t dotted), to be complemented by the immediately following 
upbeat for Valse 1.
It seems that you intentionally replaced -! by -. in Valse 1, however 
the original uses them distinctly and I’d stick with that.

The hairpins in Valse 4 should stop at the third beat, I think.
It would probably be better English to begin the Credits sentence with 
‘Thanks to…’.


You’re welcome – and thanks for pointing to this delightful piece :-)

Yours, Simon

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

missing stem

[Bogi Lützen]

Please help me with this little problem.

This is just one of my efforts, but in all of them I miss the stem on the
first g'2:

\version "2.18.0"

{ 

<<{c''1^~|\stemUp c''2 c''4 c''| c''1}{\stemDown g'2 a' |g' a'4 
a'| g'1}>>


\bar "|."
}

yours Bogi Lützen
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: question about overrides within repeats

[Werner LEMBERG]

> Well, System::post_processing ends by creating the stencils of a
> system in reverse order.  That's probably not helping.

A bug?


Werner

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

Re: question about overrides within repeats

[David Nalesnik]

On Sun, Nov 22, 2015 at 4:56 PM, David Kastrup  wrote:

> David Nalesnik  writes:
>
> > The following function gives each TextScript grobs on a line a number
> based
> > on its position within the 'all-elements array.  Each line should be
> > numbered 1-20 in order, but that's clearly not the case.  There's a
> binding
> > of texts which sorts grobs by moment.  Comment that back in and the
> problem
> > disappears.
>
> Well, System::post_processing ends by creating the stencils of a system
> in reverse order.  That's probably not helping.
>
>
>
Which helps to explain why when I've tried to rewrite the measure counter
to increment the count through a closure, I get a backwards count.

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

Re: question about overrides within repeats

[David Kastrup]

David Nalesnik  writes:

> The following function gives each TextScript grobs on a line a number based
> on its position within the 'all-elements array.  Each line should be
> numbered 1-20 in order, but that's clearly not the case.  There's a binding
> of texts which sorts grobs by moment.  Comment that back in and the problem
> disappears.

Well, System::post_processing ends by creating the stencils of a system
in reverse order.  That's probably not helping.

-- 
David Kastrup

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

Re: question about overrides within repeats

[David Nalesnik]

Hi,

On Sun, Nov 22, 2015 at 3:00 PM, David Kastrup  wrote:

> Simon Albrecht  writes:
>
> > On 22.11.2015 21:44, David Kastrup wrote:
> >> Thomas Morley  writes:
> >>
> >>> Though, why it is that arbitrary?
> >>>
> >>> Look at this variation and the attached image:
> >>>
> >>> \version "2.19.29"
> >>> #(define test-nmbrs
> >>>(let ((nmbrs (circular-list 1 2 3 4)))
> >>>  (lambda (grob)
> >>>(let ((n (car nmbrs)))
> >>>  (set! nmbrs (cdr nmbrs))
> >>>  (grob-interpret-markup grob (number->string n))
> >>>
> >>> {
> >>>\repeat unfold 8 {
> >>>  \once \override TextScript.stencil = #test-nmbrs
> >>>  c''4^\markup "foo"
> >>>}
> >>> }
> >> Well, it is exactly 2 variants of 1, 2, 3, 4 each.  I suspect that the
> >> order of grob evaluation at some point when a system is printed depends
> >> on the order of memory addresses.
> >>
> >> Find that point and you'll likely also have the culprit for various
> >> other stuff behaving non-deterministically, like what is drawn on top of
> >> what and other things frequently turning up in "make check".
> >>
>
>
I don't know if this has anything to do with it,  but the grob-array
'all-elements doesn't appear to be consistently sorted by moment.

The following function gives each TextScript grobs on a line a number based
on its position within the 'all-elements array.  Each line should be
numbered 1-20 in order, but that's clearly not the case.  There's a binding
of texts which sorts grobs by moment.  Comment that back in and the problem
disappears.


\version "2.19.30"

#(define (number-me grob)
   (let* ((sys (ly:grob-system grob))
  (all-grobs (ly:grob-array->list (ly:grob-object sys
'all-elements)))
  (texts (filter (lambda (elt) (grob::has-interface elt
'text-script-interface))
 all-grobs))
  ;(texts (sort texts (lambda (x y) (ly:momentstring idx)))
(loop (cdr t) (1+ idx)))

{
  \repeat unfold 10 {
\once\override NoteHead.after-line-breaking = #number-me
\repeat unfold 20 c''4^"foo"
\break
  }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Gounod - Le Rendez Vous

[tisimst]

Alberto,

On Sunday, November 22, 2015, Alberto Simões-2 [via Lilypond] <
ml-node+s1069038n183952...@n5.nabble.com> wrote:

> Hi all,
>
> Final version here:
>
> https://github.com/ambs/music/blob/master/Gounod/LeRendezVous/suite.pdf
>
> Will submit it to IMSLP later to the end of the week, in case anybody
> spots any critical issue. I should say I am quite happy with it, and
> will print it ASAP to play it :)
>
> Thank you, again, for all your help,
> Alberto
>
> ___
> lilypond-user mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/Gounod-Le-Rendez-Vous-tp183419p183952.html
> To start a new topic under User, email ml-node+s1069038n...@n5.nabble.com
> 
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>

I think there was a misunderstanding about the voicing in Valse 2. The
beamed groups should NOT be in \voiceOne. They should be in \oneVoice. That
should clean up the space taken up by their respective slurs, too.

Sorry, there were some other things I need to check against the source
engraving that didn't look quite right (but might be), so I'll take a look
later and get back to you.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Gounod-Le-Rendez-Vous-tp183419p183954.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: the custos: understanding how it works

[Jacques Menu]

Hello Leszek,

Oops, looks like I totally misunderstood the kind of help you were looking for…

Sorry for the noise!

JM

> Le 22 nov. 2015 à 17:37, Jacques Menu  a écrit :
> 
> Hello Leszek,
> 
> Here is an example from this list.
> 
> JM
> 
> 
> 
> \version "2.18.1"
> 
> \layout {
>   indent = 0
>   ragged-right = ##t
>   \context {
> \Staff
> \consists "Custos_engraver"
> %  \override Staff.Custos.stencil = ##f
> %  \override Staff.Custos.style = ##f
>   }
> }
> 
> 
> \relative c' {
>   d1
> 
>   \once\override Staff.Custos.style = #ly:custos::print
>   \break
> 
>   a'1
> 
>   \once\override Staff.Custos.stencil = ##f
>   %\revert Staff.Custos.stencil
>   %\revert Staff.Custos.style
>   \break
> 
>   a'1
> 
>   \break
> 
>   g1
> 
>   \once\override Staff.Custos.style = #ly:custos::print
>   \break
> 
>   f1
> 
>   \break
> 
>   e1
> }
> 
> 
> \relative c' {
>   d1
>   b1
>   % \revert Staff.Custos.stencil
> %  \revert Staff.Custos.style
>   \once\override Staff.Custos.style = #ly:custos::print
> %  \override Staff.Custos.style = #ly:custos::print
>   \break
>   a'1
> %  \override Staff.Custos.stencil = ##f
>   \once\override Staff.Custos.stencil = ##f
>   \break
>   f'1
>   \break
>   d1
>   \once\override Staff.Custos.style = #ly:custos::print
>   \break
>   c1
>   \break
>   b1
> }
> 
> 
>> Le 22 nov. 2015 à 16:41, Leszek Wroński > > a écrit :
>> 
>> I was delighted to learn that Lilypond allows one to use custodes. I was 
>> wondering how they really work, namely, how one can, upon a linebreak, check 
>> what the next pitch is. I have limited Scheme experience. I first tried the 
>> code for the first example from here: 
>> http://www.lilypond.org/doc/v2.19/Documentation/notation/typesetting-mensural-music
>>  
>> 
>>  and enclosed it (that is, the part inside "\score { } ") in "\displayMusic{ 
>> }" . But this, while enlightening in some respects, didn't really tell me 
>> what's going on when the custos is to be displayed. So I downloaded the 
>> source code, and after grepping found two files of interest: custos.cc 
>>  and custos-engraver.cc  . In 
>> the latter I found an expression headed by 
>> 
>> "void
>>  Custos_engraver::acknowledge_note_head (Grob_info info)"
>> 
>> (line 83). Could anyone tell me if I'm on the right track? My problem is 
>> that, while I'm willing to learn, I have a very limited experience with C++ 
>> and with any object programming whatsoever (having spent much time decades 
>> ago with Turbo Pascal 5 :-)). I'd be very grateful for any pointers 
>> regarding what happens during a linebreak (and, in general, how one should 
>> learn such things).
>> 
>> Best regards,
>> 
>> Leszek Wronski.
>> 
>> 
>> ___
>> 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: Gounod - Le Rendez Vous

[Alberto Simões]

Hi all,

Final version here:

https://github.com/ambs/music/blob/master/Gounod/LeRendezVous/suite.pdf

Will submit it to IMSLP later to the end of the week, in case anybody 
spots any critical issue. I should say I am quite happy with it, and 
will print it ASAP to play it :)


Thank you, again, for all your help,
Alberto

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

Re: question about overrides within repeats

[David Kastrup]

Simon Albrecht  writes:

> On 22.11.2015 21:44, David Kastrup wrote:
>> Thomas Morley  writes:
>>
>>> Though, why it is that arbitrary?
>>>
>>> Look at this variation and the attached image:
>>>
>>> \version "2.19.29"
>>> #(define test-nmbrs
>>>(let ((nmbrs (circular-list 1 2 3 4)))
>>>  (lambda (grob)
>>>(let ((n (car nmbrs)))
>>>  (set! nmbrs (cdr nmbrs))
>>>  (grob-interpret-markup grob (number->string n))
>>>
>>> {
>>>\repeat unfold 8 {
>>>  \once \override TextScript.stencil = #test-nmbrs
>>>  c''4^\markup "foo"
>>>}
>>> }
>> Well, it is exactly 2 variants of 1, 2, 3, 4 each.  I suspect that the
>> order of grob evaluation at some point when a system is printed depends
>> on the order of memory addresses.
>>
>> Find that point and you'll likely also have the culprit for various
>> other stuff behaving non-deterministically, like what is drawn on top of
>> what and other things frequently turning up in "make check".
>>
>
> Should I open a tracker issue for that? Defect or Enhancement?

We already have tracker issues for the non-determinacy of make check and
similar.

-- 
David Kastrup

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

Re: question about overrides within repeats

[Simon Albrecht]

On 22.11.2015 21:44, David Kastrup wrote:

Thomas Morley  writes:


Though, why it is that arbitrary?

Look at this variation and the attached image:

\version "2.19.29"
#(define test-nmbrs
   (let ((nmbrs (circular-list 1 2 3 4)))
 (lambda (grob)
   (let ((n (car nmbrs)))
 (set! nmbrs (cdr nmbrs))
 (grob-interpret-markup grob (number->string n))

{
   \repeat unfold 8 {
 \once \override TextScript.stencil = #test-nmbrs
 c''4^\markup "foo"
   }
}

Well, it is exactly 2 variants of 1, 2, 3, 4 each.  I suspect that the
order of grob evaluation at some point when a system is printed depends
on the order of memory addresses.

Find that point and you'll likely also have the culprit for various
other stuff behaving non-deterministically, like what is drawn on top of
what and other things frequently turning up in "make check".



Should I open a tracker issue for that? Defect or Enhancement?

Yours, Simon

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

Re: question about overrides within repeats

[David Kastrup]

Thomas Morley  writes:

> Though, why it is that arbitrary?
>
> Look at this variation and the attached image:
>
> \version "2.19.29"
> #(define test-nmbrs
>   (let ((nmbrs (circular-list 1 2 3 4)))
> (lambda (grob)
>   (let ((n (car nmbrs)))
> (set! nmbrs (cdr nmbrs))
> (grob-interpret-markup grob (number->string n))
>
> {
>   \repeat unfold 8 {
> \once \override TextScript.stencil = #test-nmbrs
> c''4^\markup "foo"
>   }
> }

Well, it is exactly 2 variants of 1, 2, 3, 4 each.  I suspect that the
order of grob evaluation at some point when a system is printed depends
on the order of memory addresses.

Find that point and you'll likely also have the culprit for various
other stuff behaving non-deterministically, like what is drawn on top of
what and other things frequently turning up in "make check".

-- 
David Kastrup

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

Re: question about overrides within repeats

[David Nalesnik]

On Sun, Nov 22, 2015 at 2:18 PM, David Nalesnik 
wrote:

>
>
> On Sun, Nov 22, 2015 at 2:15 PM, Thomas Morley 
> wrote:
>
>> 2015-11-22 20:49 GMT+01:00 David Nalesnik :
>> >
>> >
>> > On Sun, Nov 22, 2015 at 1:21 PM, David Kastrup  wrote:
>> >>
>> >>
>> >> > Is there any way to get the override to be reevaluated with each
>> repeat?
>> >>
>> >> No.  Written in that manner, the override is evaluated at _input_ time.
>> >> If you put it in a variable and use that variable 3 times, the colors
>> >> will be the same each time.  What you want is
>> >>
>> >> #(define test
>> >>(let ((colors (circular-list red green blue yellow darkgreen
>> magenta)))
>> >>  (lambda (grob)
>> >>(let ((color (car colors)))
>> >>  (set! colors (cdr colors))
>> >>  color
>> >>
>> >> and
>> >>
>> >>   \override NoteHead.color = #test
>> >>
>> >> That way you'll get one call per actual _grob_ since then each grob is
>> >> then initialized with the callback, and the callback is replaced by the
>> >> value when the property is first used.
>> >>
>> >
>> > OK, I get it.  I need to override NoteHead.color with a procedure,
>> rather
>> > than the evaluation of the procedure.  (And a grob callback must of
>> course
>> > have a grob argument.  Passing my original as a procedure results in an
>> > error.)
>> >
>> > Thanks so much!
>> >
>> > David
>>
>>
>>
>> Though, why it is that arbitrary?
>>
>> Look at this variation and the attached image:
>>
>> \version "2.19.29"
>> #(define test-nmbrs
>>   (let ((nmbrs (circular-list 1 2 3 4)))
>> (lambda (grob)
>>   (let ((n (car nmbrs)))
>> (set! nmbrs (cdr nmbrs))
>> (grob-interpret-markup grob (number->string n))
>>
>> {
>>   \repeat unfold 8 {
>> \once \override TextScript.stencil = #test-nmbrs
>> c''4^\markup "foo"
>>   }
>> }
>>
>>
>
Could they be processed out of left-to-right order?  Note that you get two
representatives of each number, and with \repeat unfold 80, you get 20 of
each.

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

Re: question about overrides within repeats

[David Nalesnik]

On Sun, Nov 22, 2015 at 2:15 PM, Thomas Morley 
wrote:

> 2015-11-22 20:49 GMT+01:00 David Nalesnik :
> >
> >
> > On Sun, Nov 22, 2015 at 1:21 PM, David Kastrup  wrote:
> >>
> >>
> >> > Is there any way to get the override to be reevaluated with each
> repeat?
> >>
> >> No.  Written in that manner, the override is evaluated at _input_ time.
> >> If you put it in a variable and use that variable 3 times, the colors
> >> will be the same each time.  What you want is
> >>
> >> #(define test
> >>(let ((colors (circular-list red green blue yellow darkgreen
> magenta)))
> >>  (lambda (grob)
> >>(let ((color (car colors)))
> >>  (set! colors (cdr colors))
> >>  color
> >>
> >> and
> >>
> >>   \override NoteHead.color = #test
> >>
> >> That way you'll get one call per actual _grob_ since then each grob is
> >> then initialized with the callback, and the callback is replaced by the
> >> value when the property is first used.
> >>
> >
> > OK, I get it.  I need to override NoteHead.color with a procedure, rather
> > than the evaluation of the procedure.  (And a grob callback must of
> course
> > have a grob argument.  Passing my original as a procedure results in an
> > error.)
> >
> > Thanks so much!
> >
> > David
>
>
>
> Though, why it is that arbitrary?
>
> Look at this variation and the attached image:
>
> \version "2.19.29"
> #(define test-nmbrs
>   (let ((nmbrs (circular-list 1 2 3 4)))
> (lambda (grob)
>   (let ((n (car nmbrs)))
> (set! nmbrs (cdr nmbrs))
> (grob-interpret-markup grob (number->string n))
>
> {
>   \repeat unfold 8 {
> \once \override TextScript.stencil = #test-nmbrs
> c''4^\markup "foo"
>   }
> }
>
>
And \tweak produces bizarre results with the color function.  Try:

{
  \repeat unfold 50 {
\tweak NoteHead.color #test c''4
  }
}

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

Re: question about overrides within repeats

[Thomas Morley]

2015-11-22 20:49 GMT+01:00 David Nalesnik :
>
>
> On Sun, Nov 22, 2015 at 1:21 PM, David Kastrup  wrote:
>>
>>
>> > Is there any way to get the override to be reevaluated with each repeat?
>>
>> No.  Written in that manner, the override is evaluated at _input_ time.
>> If you put it in a variable and use that variable 3 times, the colors
>> will be the same each time.  What you want is
>>
>> #(define test
>>(let ((colors (circular-list red green blue yellow darkgreen magenta)))
>>  (lambda (grob)
>>(let ((color (car colors)))
>>  (set! colors (cdr colors))
>>  color
>>
>> and
>>
>>   \override NoteHead.color = #test
>>
>> That way you'll get one call per actual _grob_ since then each grob is
>> then initialized with the callback, and the callback is replaced by the
>> value when the property is first used.
>>
>
> OK, I get it.  I need to override NoteHead.color with a procedure, rather
> than the evaluation of the procedure.  (And a grob callback must of course
> have a grob argument.  Passing my original as a procedure results in an
> error.)
>
> Thanks so much!
>
> David



Though, why it is that arbitrary?

Look at this variation and the attached image:

\version "2.19.29"
#(define test-nmbrs
  (let ((nmbrs (circular-list 1 2 3 4)))
(lambda (grob)
  (let ((n (car nmbrs)))
(set! nmbrs (cdr nmbrs))
(grob-interpret-markup grob (number->string n))

{
  \repeat unfold 8 {
\once \override TextScript.stencil = #test-nmbrs
c''4^\markup "foo"
  }
}

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

Re: question about overrides within repeats

[David Nalesnik]

On Sun, Nov 22, 2015 at 1:21 PM, David Kastrup  wrote:

>
> > Is there any way to get the override to be reevaluated with each repeat?
>
> No.  Written in that manner, the override is evaluated at _input_ time.
> If you put it in a variable and use that variable 3 times, the colors
> will be the same each time.  What you want is
>
> #(define test
>(let ((colors (circular-list red green blue yellow darkgreen magenta)))
>  (lambda (grob)
>(let ((color (car colors)))
>  (set! colors (cdr colors))
>  color
>
> and
>
>   \override NoteHead.color = #test
>
> That way you'll get one call per actual _grob_ since then each grob is
> then initialized with the callback, and the callback is replaced by the
> value when the property is first used.
>
>
OK, I get it.  I need to override NoteHead.color with a procedure, rather
than the evaluation of the procedure.  (And a grob callback must of course
have a grob argument.  Passing my original as a procedure results in an
error.)

Thanks so much!

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

Re: Gounod - Le Rendez Vous

[Alberto Simões]

On 12/11/15 17:53, Simon Albrecht wrote:

On 12.11.2015 16:52, Alberto Simões wrote:

Hello, Simon!

On 12/11/15 11:21, Simon Albrecht wrote:


Two annotations:
– Sometimes it would be nice to have whiteout for DynamicTextSpanner
against SpanBar; I don’t quite know the best way to do it, though.
Perhaps you could use \markup\whiteout-box on the individual text bits?


I didn't understand it very well. You are saying the text from
crescendo/decrescendo and the -- -- are too close?


No, I meant overlaps as in valse 1, m. 39/40. The following works fine:
In 2.19.32, it will be possible to specify padding in whiteout-box (as
of issue 4504). That will be preferable then, but for now
whiteout-outline is just fine. (try \whiteout-box instead of \whiteout
to test)


Hi, Simon
Dynmics whiteout also fixed, and some other pushed a little to the side 
instead of whiting it out.


Current version at
 https://github.com/ambs/music/blob/master/Gounod/LeRendezVous/suite.pdf

Thank you
Alberto

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

Re: question about overrides within repeats

[David Kastrup]

David Nalesnik  writes:

> Hi,
>
> Given the following function, each time an override of NoteHead.color
> occurs, a new color from the list is used:
>
> \version "2.19.30"
>
> #(define test
>(let ((colors (circular-list red green blue yellow darkgreen magenta)))
>  (lambda ()
>(let ((color (car colors)))
>  (set! colors (cdr colors))
>  color
>
> {
>   \once\override NoteHead.color = #(test)
>   c''4
>   \once\override NoteHead.color = #(test)
>   c''4

> However, when I put the override within a repeat structure, the override
> only seems to happen once:
>
> %% All darkgreen (we left off with yellow above
> {
>   \repeat unfold 10 {
> \once \override NoteHead.color = #(test)
> c''4
>   }
> }
>
> Is there any way to get the override to be reevaluated with each repeat?

No.  Written in that manner, the override is evaluated at _input_ time.
If you put it in a variable and use that variable 3 times, the colors
will be the same each time.  What you want is

#(define test
   (let ((colors (circular-list red green blue yellow darkgreen magenta)))
 (lambda (grob)
   (let ((color (car colors)))
 (set! colors (cdr colors))
 color

and

  \override NoteHead.color = #test

That way you'll get one call per actual _grob_ since then each grob is
then initialized with the callback, and the callback is replaced by the
value when the property is first used.

-- 
David Kastrup

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

question about overrides within repeats

[David Nalesnik]

Hi,

Given the following function, each time an override of NoteHead.color
occurs, a new color from the list is used:

\version "2.19.30"

#(define test
   (let ((colors (circular-list red green blue yellow darkgreen magenta)))
 (lambda ()
   (let ((color (car colors)))
 (set! colors (cdr colors))
 color

{
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
}

However, when I put the override within a repeat structure, the override
only seems to happen once:

%% All darkgreen (we left off with yellow above
{
  \repeat unfold 10 {
\once \override NoteHead.color = #(test)
c''4
  }
}

Is there any way to get the override to be reevaluated with each repeat?

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

Re: Gounod - Le Rendez Vous

[Alberto Simões]

Hey,

On 11/11/15 19:22, tisimst wrote:


This is looking MUCH better (nice work with the extended dynamic lines
;-). I'll look at it in greater detail later, but here's one thing that
I immediately noticed quite a few instances of that you would get dinged
for: You should ALWAYS enclose a tied note within a slurred passage.
Here's what I mean:


OK, regarding slurs/expression marks I think that I am done.
I am aware of other details you all contributed with, but one step at a 
time.


So, if you would like to see the slur/expression marks result, visit
https://github.com/ambs/music/blob/master/Gounod/LeRendezVous/suite.pdf

Best,
Alberto

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

Re: the custos: understanding how it works

[Thomas Morley]

2015-11-22 16:41 GMT+01:00 Leszek Wroński :
> I was delighted to learn that Lilypond allows one to use custodes. I was
> wondering how they really work, namely, how one can, upon a linebreak, check
> what the next pitch is. I have limited Scheme experience. I first tried the
> code for the first example from here:
> http://www.lilypond.org/doc/v2.19/Documentation/notation/typesetting-mensural-music
> and enclosed it (that is, the part inside "\score { } ") in "\displayMusic{
> }" . But this, while enlightening in some respects, didn't really tell me
> what's going on when the custos is to be displayed. So I downloaded the
> source code, and after grepping found two files of interest: custos.cc and
> custos-engraver.cc . In the latter I found an expression headed by
>
> "void
>  Custos_engraver::acknowledge_note_head (Grob_info info)"
>
> (line 83). Could anyone tell me if I'm on the right track? My problem is
> that, while I'm willing to learn, I have a very limited experience with C++
> and with any object programming whatsoever (having spent much time decades
> ago with Turbo Pascal 5 :-)). I'd be very grateful for any pointers
> regarding what happens during a linebreak (and, in general, how one should
> learn such things).
>
> Best regards,
>
> Leszek Wronski.
>

Hi Leszek,

not sure what you want to achieve.

However, the following may be of some help, see comments inline:

\layout {
  \context {
\Staff
\consists "Custos_engraver"
\override Custos.color = #red
\override Custos.style = ##f
%% The following will result in some errors of kind:
%% programming error: No spacing entry from Item to `custos'
%% Although resolveable, ignore them. This override demonstrates that
%% custos is always (apart from first note) created, if forced.
\override Custos.break-visibility = ##(#t #t #t)
%% As a breakable item, it will be printed only at line-end, if the correct
%% value for `break-visibility' is set.
%% Which is the default, see: /scm/define-grobs.scm
  }
}

\relative {
  \repeat unfold 3 {
c'1 d e f
g a b c
  }
}


Cheers,
  Harm

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

Re: the custos: understanding how it works

[David Kastrup]

Leszek Wroński  writes:

> I was delighted to learn that Lilypond allows one to use custodes. I was
> wondering how they really work, namely, how one can, upon a linebreak,
> check what the next pitch is.  I have limited Scheme experience.

> source code, and after grepping found two files of interest: custos.cc
> and custos-engraver.cc . In the latter I found an expression headed by
>
> "void
>  Custos_engraver::acknowledge_note_head (Grob_info info)"
>
> (line 83). Could anyone tell me if I'm on the right track?

Sort of.  That's where the Custos_engraver sees graphical objects that
have been declared to have a note-head-interface pass into the current
score.

> My problem is that, while I'm willing to learn, I have a very limited
> experience with C++ and with any object programming whatsoever (having
> spent much time decades ago with Turbo Pascal 5 :-)).

Well, imagine how frustrating it would be if you were a gee-whiz
C++ programmer and still couldn't tell the stuff LilyPond does from
Turbo Pascal 5.  C++ knowledge actually does not buy you all that much
for reading the source code.

> I'd be very grateful for any pointers regarding what happens during a
> linebreak (and, in general, how one should learn such things).

I'd take a look at the Contributor's Guide first: there are a few
sketches of code workings in it.  There is a file ROADMAP in the
repository that points out what kind of code is grouped into which
directories.

Other than that, it's mostly reading code and asking back on the list.

-- 
David Kastrup

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

Re: the custos: understanding how it works

[Jacques Menu]

Hello Leszek,

Here is an example from this list.

JM



\version "2.18.1"

\layout {
  indent = 0
  ragged-right = ##t
  \context {
\Staff
\consists "Custos_engraver"
%  \override Staff.Custos.stencil = ##f
%  \override Staff.Custos.style = ##f
  }
}


\relative c' {
  d1

  \once\override Staff.Custos.style = #ly:custos::print
  \break

  a'1

  \once\override Staff.Custos.stencil = ##f
  %\revert Staff.Custos.stencil
  %\revert Staff.Custos.style
  \break

  a'1

  \break

  g1

  \once\override Staff.Custos.style = #ly:custos::print
  \break

  f1

  \break

  e1
}


\relative c' {
  d1
  b1
  % \revert Staff.Custos.stencil
%  \revert Staff.Custos.style
  \once\override Staff.Custos.style = #ly:custos::print
%  \override Staff.Custos.style = #ly:custos::print
  \break
  a'1
%  \override Staff.Custos.stencil = ##f
  \once\override Staff.Custos.stencil = ##f
  \break
  f'1
  \break
  d1
  \once\override Staff.Custos.style = #ly:custos::print
  \break
  c1
  \break
  b1
}


> Le 22 nov. 2015 à 16:41, Leszek Wroński  a écrit :
> 
> I was delighted to learn that Lilypond allows one to use custodes. I was 
> wondering how they really work, namely, how one can, upon a linebreak, check 
> what the next pitch is. I have limited Scheme experience. I first tried the 
> code for the first example from here: 
> http://www.lilypond.org/doc/v2.19/Documentation/notation/typesetting-mensural-music
>  
> 
>  and enclosed it (that is, the part inside "\score { } ") in "\displayMusic{ 
> }" . But this, while enlightening in some respects, didn't really tell me 
> what's going on when the custos is to be displayed. So I downloaded the 
> source code, and after grepping found two files of interest: custos.cc and 
> custos-engraver.cc . In the latter I found an expression headed by 
> 
> "void
>  Custos_engraver::acknowledge_note_head (Grob_info info)"
> 
> (line 83). Could anyone tell me if I'm on the right track? My problem is 
> that, while I'm willing to learn, I have a very limited experience with C++ 
> and with any object programming whatsoever (having spent much time decades 
> ago with Turbo Pascal 5 :-)). I'd be very grateful for any pointers regarding 
> what happens during a linebreak (and, in general, how one should learn such 
> things).
> 
> Best regards,
> 
> Leszek Wronski.
> 
> 
> ___
> 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: Gounod - Le Rendez Vous

[Alberto Simões]

Hi

On 22/11/15 13:52, tisimst wrote:

Valse 1 looks great! There's a natural in the LH chord in m. 58 that
shouldn't be there. If so a double check on all accidentals just to be
sauté there aren't others that should or shouldn't be there.


Yep, still fixing slurs, only. I have a couple other fixes in the queue.

But thank you for poking me on it :)

Will be back shortly :)
Alberto

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

Re: Clashing ties & slurs with tieWaitForNote

[Werner LEMBERG]

> Werner, any suggestions for _not_ using a tie in that manner?

For me, a tie lengthens a time value of a given pitch; it has no other
meaning.


Werner

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

the custos: understanding how it works

[Leszek Wroński]

I was delighted to learn that Lilypond allows one to use custodes. I was
wondering how they really work, namely, how one can, upon a linebreak,
check what the next pitch is. I have limited Scheme experience. I first
tried the code for the first example from here:
http://www.lilypond.org/doc/v2.19/Documentation/notation/typesetting-mensural-music
and enclosed it (that is, the part inside "\score { } ") in "\displayMusic{
}" . But this, while enlightening in some respects, didn't really tell me
what's going on when the custos is to be displayed. So I downloaded the
source code, and after grepping found two files of interest: custos.cc and
custos-engraver.cc . In the latter I found an expression headed by

"void
 Custos_engraver::acknowledge_note_head (Grob_info info)"

(line 83). Could anyone tell me if I'm on the right track? My problem is
that, while I'm willing to learn, I have a very limited experience with C++
and with any object programming whatsoever (having spent much time decades
ago with Turbo Pascal 5 :-)). I'd be very grateful for any pointers
regarding what happens during a linebreak (and, in general, how one should
learn such things).

Best regards,

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

Re: Gounod - Le Rendez Vous

[tisimst]

On Sunday, November 22, 2015, Simon Albrecht-2 [via Lilypond] <
ml-node+s1069038n183931...@n5.nabble.com> wrote:

> On 22.11.2015 14:52, tisimst wrote:
> > One other thing I noticed in Valse 2, m. 42-43 - remove staccato from
> > tied end notes. They just don't make sense. I would guess the one in
> > the source engraving (m. 42) is a typo as it is omitted in the next
> > measure.
>
> It is definitely not. There is perfect consistency between the staccato
> dots in mm. 37f. and 41–43: the crotchets are supposed to be cut short.
> The first note in m. 44 already is a quaver, and the slur from the next
> note also suggests playing it short, so there is no necessity for the
> dot here. In general, please be careful about changing notation in such
> situations! If you can’t make any sense from that which the composer
> wrote, that doesn’t mean there is none. The 19th century used a number
> of notational features, which were forgotten during the 20th century,
> such as the distinction between (de)crescendo and hairpins. If we as
> modern editors iron out these, we are in danger of eradicating
> information which contains important hints on the performance practice
> and intent of the music.
>
> Yours, Simon
>
> ___
> lilypond-user mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/lilypond-user


You are right, Simon. Thank you for correcting me. I didn't mean to
arbitrarily dismiss a marking that was unfamiliar to me. I'll be more
careful in the future. In a way, it makes me wonder about deviating from
these original engravings *at all*.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Gounod-Le-Rendez-Vous-tp183419p183933.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: Gounod - Le Rendez Vous

[Simon Albrecht]

On 22.11.2015 14:52, tisimst wrote:
One other thing I noticed in Valse 2, m. 42-43 - remove staccato from 
tied end notes. They just don't make sense. I would guess the one in 
the source engraving (m. 42) is a typo as it is omitted in the next 
measure. 


It is definitely not. There is perfect consistency between the staccato 
dots in mm. 37f. and 41–43: the crotchets are supposed to be cut short. 
The first note in m. 44 already is a quaver, and the slur from the next 
note also suggests playing it short, so there is no necessity for the 
dot here. In general, please be careful about changing notation in such 
situations! If you can’t make any sense from that which the composer 
wrote, that doesn’t mean there is none. The 19th century used a number 
of notational features, which were forgotten during the 20th century, 
such as the distinction between (de)crescendo and hairpins. If we as 
modern editors iron out these, we are in danger of eradicating 
information which contains important hints on the performance practice 
and intent of the music.


Yours, Simon

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

Re: Gounod - Le Rendez Vous

[tisimst]

Alberto,

On Saturday, November 21, 2015, Simon Albrecht-2 [via Lilypond] <
ml-node+s1069038n18391...@n5.nabble.com> wrote:

> On 21.11.2015 20:21, Alberto Simões wrote:
>
> >
> >
> > On 20/11/15 11:30, Alberto Simões wrote:
> >> Hey
> >>
> >> On 20/11/2015 05:49, Abraham Lee wrote:
> >>> That being said, since there appears to be arguments for doing it both
> >>> ways, I'd recommend that you pick one way and be consistent throughout
> >>> the entire work.
> >
> > Can I ask what you like better? [1]
> >
> > Valse 2, measures 3/4 or measures 7/8?
>
> I prefer measures 11/12. Measure 8 should have \oneVoice already, I think.
>

Personally, I like m. 3/4. For me it instantly clarifies what is tied and
what isn't. This is true throughout the entire work. I realize that
containing ties makes parts like Valse 2 m. 33-36 and 38-41 have longer
phrases, so I would at least enclose the tie with the right-side slur. That
seems more true to the phrasing. In m. 45-48, I'd do the same with both
ties, breaking it into two shorter phrases where the tie begins each one.

*NOTE: whichever way you choose to treat the ties/slurs, do it
consistently for the entire work.*

I also agree with Simon that at m. 7 you should already be back to
\oneVoice. That will make the beam group in m. 8 look much better (as well
as the slur). There are other measures that should be done similarly.

There are other times that the two voices have notes of the same duration,
but remain separate voices. This happens multiple times in Valse 2 (m. 7,
21, 23, 31, 55, 57, 71, 73, 81). I see no reason you can't join them
together with \oneVoice even though the original engraving doesn't. I guess
you get to decide on that one.

One other thing I noticed in Valse 2, m. 42-43 - remove staccato from tied
end notes. They just don't make sense. I would guess the one in the source
engraving (m. 42) is a typo as it is omitted in the next measure. Maybe I'm
wrong.

Valse 1 looks great! There's a natural in the LH chord in m. 58 that
shouldn't be there. If so a double check on all accidentals just to be
sauté there aren't others that should or shouldn't be there.

I'd also still consider eliminating the collisions between bar lines and
dynamic text using some kind of whiteout.

Looks like there are more ties and slurs to consider in the Coda section.

That's all for now. Good work! This will be a fine addition to IMSLP.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Gounod-Le-Rendez-Vous-tp183419p183930.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: Clashing ties & slurs with tieWaitForNote

[David Kastrup]

Malte Meyn  writes:

> Am 21.11.2015 um 20:30 schrieb David Kastrup:
>> Urs Liska  writes:
>>
>>> Thanks, that makes things clearer.  This is definitely what I
>>> suggested. The "outer" slur is not a tie but a phrasing slur and the
>>> inner one a slur indicating the bowing.
>>
>> That would not make much sense, really.  Phrasing slurs in violin music
>> are only necessary when you can't avoid changing bow direction, so if
>> they are present, they are much longer.
>>
>> The tied notation makes more sense, indicating that you change from a
>> one-string note to a double-stop and then revert back to the one-string
>> note.
>
> I disagree: In Finlandia this note is definitely *not* tied. Obviously
> Sibelius writes both a “technical” slur (for bow change) and a
> “musical/melodical” slur (not really “phrasing” in musical language
> but in lilypond language).
>
> For a more secure proof have a look at the third bar after rehearsal
> mark L: This cannot be played as double stops.

Well, it can.  But it's quite awkward.  Basically, you have to hold the
bes in first position on the A string and finger the rest on the D
string.  Or, less of a stretch, do the same in fifth position on the D
string and finger the rest on the G string.

And even if one wanted to claim that as the underlying intent, the
eighth rest before the "tied" eighth note at the end would not make any
sense.

So yes, this particular case does not seem to want ties but phrasing
slurs.

-- 
David Kastrup

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

Re: Clashing ties & slurs with tieWaitForNote

[Malte Meyn]

Am 21.11.2015 um 20:30 schrieb David Kastrup:

Urs Liska  writes:


Thanks, that makes things clearer.  This is definitely what I
suggested. The "outer" slur is not a tie but a phrasing slur and the
inner one a slur indicating the bowing.


That would not make much sense, really.  Phrasing slurs in violin music
are only necessary when you can't avoid changing bow direction, so if
they are present, they are much longer.

The tied notation makes more sense, indicating that you change from a
one-string note to a double-stop and then revert back to the one-string
note.


I disagree: In Finlandia this note is definitely *not* tied. Obviously 
Sibelius writes both a “technical” slur (for bow change) and a 
“musical/melodical” slur (not really “phrasing” in musical language but 
in lilypond language).


For a more secure proof have a look at the third bar after rehearsal 
mark L: This cannot be played as double stops.


And the first bar after L is the same in the cello part and not (or 
hardly) playable as double stops on a cello. Also there is no other 
instrument that holds the c …



This kind of "hold a note on one string and touch notes on next
string" phrasing is used in a few movements in the Bach solo partitas as
well.  The notation of Steve was a reasonable rendition for that:
writing this as strictly two voices makes it harder to indicate the
slurring.


The Bach solo partitas are polyphonic. This part of Finlandia is 
definitely not.


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

Re: Strange LilyPond crash

[David Kastrup]

Marc Hohl  writes:

> Am 21.11.2015 um 16:54 schrieb David Kastrup:
>> Marc Hohl  writes:
>>
>>> Am 21.11.2015 um 10:53 schrieb David Kastrup:
 Marc Hohl  writes:
>>> [...]
 Looks like there is some sequential iterator consulted for
 pending_moment that no longer has an iter_ to refer to.

 More likely than not, one of the fixes for addlyrics going off the deep
 end when its associated context dies is involved here.
>>>
>>> I am not sure whether I understand this correctly, but I have replaced
>>> every occurence of \addlyrics with its proper counterpart \new Lyrics
>>> \lyricsto "..."
>>
>> Sorry to have caused extra work, but lyricsto and addlyrics are the same
>> with regard to the context hierarchy.  This would not likely have
>> changed anything.
>
> No problem at all – IIRC, \addlyrics seems to be less robust than
> \lyricsto (at least in some cases), isn't it?

No.  \addlyrics is exactly as robust as the corresponding \lyricsto
construct.  It's just that in more complex \addlyrics situations, the
corresponding \lyricsto construct might end up being a bit of a
surprise.

Which reminds me that I still need to fix the latest such discovered
\addlyrics surprise.  Which turned out to be rather tricky.

-- 
David Kastrup

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

Re: Strange LilyPond crash

[Marc Hohl]

Am 21.11.2015 um 16:54 schrieb David Kastrup:

Marc Hohl  writes:


Am 21.11.2015 um 10:53 schrieb David Kastrup:

Marc Hohl  writes:

[...]

Looks like there is some sequential iterator consulted for
pending_moment that no longer has an iter_ to refer to.

More likely than not, one of the fixes for addlyrics going off the deep
end when its associated context dies is involved here.


I am not sure whether I understand this correctly, but I have replaced
every occurence of \addlyrics with its proper counterpart \new Lyrics
\lyricsto "..."


Sorry to have caused extra work, but lyricsto and addlyrics are the same
with regard to the context hierarchy.  This would not likely have
changed anything.


No problem at all – IIRC, \addlyrics seems to be less robust than 
\lyricsto (at least in some cases), isn't it?


Marc



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

Re: Clashing ties & slurs with tieWaitForNote

[David Kastrup]

Urs Liska  writes:

> Thanks, that makes things clearer.  This is definitely what I
> suggested. The "outer" slur is not a tie but a phrasing slur and the
> inner one a slur indicating the bowing.

That would not make much sense, really.  Phrasing slurs in violin music
are only necessary when you can't avoid changing bow direction, so if
they are present, they are much longer.

The tied notation makes more sense, indicating that you change from a
one-string note to a double-stop and then revert back to the one-string
note.  This kind of "hold a note on one string and touch notes on next
string" phrasing is used in a few movements in the Bach solo partitas as
well.  The notation of Steve was a reasonable rendition for that:
writing this as strictly two voices makes it harder to indicate the
slurring.

Werner, any suggestions for _not_ using a tie in that manner?

-- 
David Kastrup

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

Re: Strange LilyPond crash

[David Kastrup]

Marc Hohl  writes:

> Am 21.11.2015 um 10:53 schrieb David Kastrup:
>> Marc Hohl  writes:
> [...]
>> Looks like there is some sequential iterator consulted for
>> pending_moment that no longer has an iter_ to refer to.
>>
>> More likely than not, one of the fixes for addlyrics going off the deep
>> end when its associated context dies is involved here.
>
> I am not sure whether I understand this correctly, but I have replaced
> every occurence of \addlyrics with its proper counterpart \new Lyrics
> \lyricsto "..."

Sorry to have caused extra work, but lyricsto and addlyrics are the same
with regard to the context hierarchy.  This would not likely have
changed anything.

-- 
David Kastrup

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

Re: sponsorship offer: Lyric fixes (GSoC, etc.)

[David Kastrup]

Kieren MacMillan  writes:

> Agreed. Lilypond is still the best tool out there for my needs. I just
> wish I could do more, and more beautiful, engraving with a smaller
> investment of time and effort. (Isn’t that the eternal quest?)

Well, there is the related quest of making it a smaller investment of
time and effort to teach LilyPond to do more beatiful engraving with a
smaller investment of time and effort...

Ultimately, people have only one life to acquire and perfect skills, and
there is a distribution of skills and interests over the populace.

There is very little overlap between high-profile programmers and
high-profile composers and high-profile musicians.  And there is not all
that much availability of high-profile programmers in any given project
anyway, and one problem with high-profile programmers, probably more so
than high-profile whatever elses anyway, is that you cannot fit all too
many of them into one room before getting irreconcilable differences.

Cough cough.

So it's a good idea to steer projects in a direction where high-profile
skills are only needed one at a time and in moderation, to better match
the statistics of contributors.

I like how Emacs has managed to get less scary to users and programmers
not really scraping the bottom of its barrel.  It still contains a lot
of terrifying depths though.

I keep being annoyed at how complex some stuff is to do with LilyPond.
Even if sometimes the stuff itself is fairly complex by its nature.

If this were better, it would be much easier to load off work for money,
both with regard to typesetting as with improvement tasks.

-- 
David Kastrup

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

Re: guitar scale diagram - change root

[bart deruyter]

Hey,

thank you for the idea's. I thought I had to add an argument to the list,
but I'm not that advanced in using lilypond to implement it myself. With
this kind of solutions my understanding grows bit by bit :-) .

That other thread was very interesting for me indeed.

It works, great!

grtz,

Bart

http://www.bartart3d.be/
On Twitter 
On Identi.ca 
On Google+ 

2015-11-20 15:02 GMT+01:00 Klaus Blum :

> Hi Bart,
>
> yes, that's no problem.
> In the attached file, I've added a parameter "start". It's an integer to
> indicate the tone number to start with, i.e. 1 for the root etc. This might
> be a start.
>
> Recently, there has been another thread that might be interesting for you
> as
> well:
>
> http://lilypond.1069038.n5.nabble.com/Guitar-Fret-Diagram-scale-degree-below-string-td179664.html#a179739
>
> Cheers,
> Klaus
>
> ChangeRoot.ly
> 
>
>
> bart deruyter wrote
> > I'm assembling a list of scales for my students. with scale diagrams.
> I've
> > successfully implementend : http://lsr.di.unimi.it/LSR/Item?id=790 . But
> > now I stumble on another problem.
> >
> > The snippet for the scale diagram assumes that the lowest sounding note
> is
> > the root of the scale. What if it isn't the case?
> > I'd like to change the root to for example the second note in the list,
> or
> > the third, whichever I'd need as root.
> >
> > Can this be achieved by adding something to the snippet?
>
>
>
>
>
> --
> View this message in context:
> http://lilypond.1069038.n5.nabble.com/guitar-scale-diagram-change-root-tp183837p183842.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
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user