Re: Auto Place text after last beat of a Text Spanner

[Pierre Perol-Schneider]

Hi Dimitris,

I think it was a typo:

ot =
#(define-music-function (mus) (ly:music?)
  #{
\ottava #1
$mus
\ottava #0
<>^\markup \italic "loco"
  #})

Cheers,
Pierre


2016-09-16 1:19 GMT+02:00 dtsmarin :

> UPDATE:
> This worked for me. Thanks again!
>
> ottavaWithLoco =
> #(define-music-function (mus) (ly:music?)
>   #{
> \set Staff.ottavation = #"8va"
> $mus
> \unset Staff.ottavation
> <>^\markup \italic "loco"
>   #})
>
> HTH,
> Dimitris
>
>
>
> --
> View this message in context: http://lilypond.1069038.n5.
> nabble.com/Auto-Place-text-after-last-beat-of-a-Text-
> Spanner-tp194592p194604.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

Re: Beaming, partcombine and pickups

[David Wright]

On Thu 15 Sep 2016 at 17:15:02 (-0600), David F. wrote:
> I have a song in 9/8 time with a pickup of three eighth notes.  I expect 
> Lilypond to beam those three eighth notes together, but it does not when I 
> combine two voices with partcombine.
> 
> Am I doing something wrong?  Is Lilypond doing something wrong?  How might I 
> work around this?

Well, it's only last week that you asked "Is there a way to combine
two voices and print both stems (up and down) when the voices share a
note?  \partcombine does not appear to do this by default."

So now you've demonstrated the danger of doing that: it interferes
with the beaming. Isn't the answer just to decide on your priorities?

\partcombine #'(0 . 9)   will combine the unison notes and allow the
flag to become a beam in the appropriate direction.
Manually beaming either of the parts (or both, of course) will do the
opposite: produce beams above and below.
Which do you want?

There's an additional danger in your second example of course. If the
pickup's pitches happened to be in the reverse order, and if you were
working in 6/8 (both entirely possible in another tune), you would
have generated the beaming for a 3/4 time signature rather than a 6/8
one. (Many hymnbooks lack time signatures.)

I'm not sure it's wise of me to ask what the attraction is of the
American convention of part-combining.

Cheers,
David.

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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 5:17 PM, "Chris Yate"  wrote:

>Oh yeah, these examples are a case in point! The first seems to suggest
>dots should stay within the area of the chord, while the second suggests
>it's ok to have dots extending the chord as long as they're balanced
>vertically.

The first follows her rule that says "If a dot is 2 spaces or more away
from the limit of the chord, trim all the dots to the space occupied by
the chord."

The second has no dot two spaces or more away, so the dots stay, even
though they extend beyond the chord.  Both are exactly consistent with her
words, as I read them.  There is no inconsistency between her examples and
her rules that I can see.

I'm now home and have checked my other references.  Read does not address
cases that would move dots beyond the span of the chord. Neither does Ross.

Powell (Music Engraving Today) is consistent with your examples.  The rule
he gives is "If there are too many notes for the number of spaces, leave
off a dot.  Never put a dot a third away from a note, and never try to put
two dots in one space."

In another place he says "Never put the dot more than a second away from
any note."

Thus, I think your preferences follow Powell's rules.  Now if I can just
figure out how to implement them (but I have some ideasŠ).

Thanks,

Carl


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

Re: Auto Place text after last beat of a Text Spanner

[dtsmarin]

UPDATE:
This worked for me. Thanks again!

ottavaWithLoco =
#(define-music-function (mus) (ly:music?)
  #{
\set Staff.ottavation = #"8va"
$mus
\unset Staff.ottavation
<>^\markup \italic "loco"
  #})

HTH,
Dimitris



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Auto-Place-text-after-last-beat-of-a-Text-Spanner-tp194592p194604.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: Augmentation dot positioning

[Chris Yate]

Oh yeah, these examples are a case in point! The first seems to suggest
dots should stay within the area of the chord, while the second suggests
it's ok to have dots extending the chord as long as they're balanced
vertically.

Fundamentally the only difference between these situations is the size of
the chord. I'm not yet convinced that Gould has a hard and fast rule.

It's probably irrelevant, but a very small sample of my musician friends
suggests that dots shouldn't be placed further away than the next space
above/below the top/bottom of the chord. When I posted a picture of the
five-note tone cluster with five dots, the overall reaction was "WTF?!
Yuck!". IMO that should tell us all we need to know...

But for the scope of this software, being able to easily get the result
*you* want is the important thing.

On 15 Sep 2016 23:43, "Carl Sorensen"  wrote:

>
>
> On 9/15/16 4:15 PM, "Chris Yate"  wrote:
>
> >
> >Please note I'm working without her examples,  but I disagree about
> >[Lilypond's interpretation of] Gould's rules, because they appear to be
> >in contradiction with **every piece of published music I've ever seen**.
> >Given just her text, I think she has possibly not worded things as
> >clearly as possible. And if it is correct to have five dots on a chord
> >spanning a ninth == five spaces, then why is it incorrect to have three
> >dots for a chord spanning three spaces?
> >The place that her rules stop making sense is this inconsistency:
> >1. It's ok to have a dot a full two staff positions away from the top or
> >bottom of the chord.
> >2. BUT... if there's a dot that according to the rules turns up to be two
> >spaces away, don't place ANY notes outside the range of spaces occupied
> >by the chord *.
> >* spaces occupied by the chord includes the half space occupied by part
> >of a notehead on a line.
>
> But this "inconsistency" that you find, is exactly illustrated in her
> examples.  She shows *precisely* the behavior you find inconsistent as the
> recommended behavior. See Gould2.png.  Gould is silent on whether the
> spaces occupied by the chord includes the half-space or not, and none of
> her examples include a note that would use the half-space.  So I don't
> disagree with you.
>
> >I think what she actually meant, and basing this also on guides like the
> >ABRSM theory books, is
> >
> >- every note needs a dot, where possible
> >- notes on a line need their dot moving up or down to the nearest space
> >- sometimes the dot needs to shift away from its parent, and that's ok
> >within the compass of the chord
>
> In your example 14, with a dots limit of 3, the dot from the E moves to
> the F space, and the dot from the F moves to the A space (within the
> compass of the chord), and you consider the dot on the A space to be
> unnecessary.  So my interpretation of your personal preference is that
> you'd prefer to never have a dot moved more than one staff position away
> from its "home".
>
> Gould would put the dot in the A space, according to the written rules.
> You accept it, but believe it's unnecessary.  If it's unnecessary, I think
> we should leave it out, because it's just clutter.  I'm reading that if
> you had your preferred style, it would be left out.  And I think LilyPond
> should have some way to support your preferred style.
>
> >- dots two or more staff _positions_ (not staff _spaces_ as written) away
> >from the top or bottom of the chord look strange, so exclude those.
>
> Gould specifically shows dot patterns with dots two staff positions away
> from a note in a space.  I included them previously, and include them
> again here as gould1.png.
>
> Note that in gould2.png, the dots that would be only two staff positions
> (one space) away from the top and bottom of the chord *are* excluded, not
> just the one that is four positions (two spaces) away.
>
> I'm going to send you (by separate email) a scan of Gould's section on
> dotted notes.  I'd be happy to have you show me how I've misunderstood her
> rules (if in fact I have).  But I'm quite sure that I have them right
> (with the possible exception of the spaces occupied by the chord including
> the half-spaces of notes on the line).
>
> >
> >Pragmatically though, I strongly believe it's a mistake for Lilypond's
> >defaults to go against the grain of what most readers of music expect and
> >have learnt to expect, even if the holy grail appears to say it's "right".
>
> Counterexamples from high-quality hand-engraved music are certainly
> welcome.   Contrary rules from other notation experts (e.g. Ross, Read,
> Stone) are also welcome.  I agree that we should do what's right.
> Sometimes the challenge is deciding what's right.
>
> I will check Read and Ross tonight.  I don't remember if I still have
> Stone or not.  If I do, I'll check it as well.
>
> Thanks,
>
> Carl
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org

Beaming, partcombine and pickups

[David F.]

I have a song in 9/8 time with a pickup of three eighth notes.  I expect 
Lilypond to beam those three eighth notes together, but it does not when I 
combine two voices with partcombine.

Am I doing something wrong?  Is Lilypond doing something wrong?  How might I 
work around this?

Thanks!
David



BeamsPartcombinePickup.ly
Description: Binary data


BeamsPartcombinePickup.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 4:15 PM, "Chris Yate"  wrote:

>
>Please note I'm working without her examples,  but I disagree about
>[Lilypond's interpretation of] Gould's rules, because they appear to be
>in contradiction with **every piece of published music I've ever seen**.
>Given just her text, I think she has possibly not worded things as
>clearly as possible. And if it is correct to have five dots on a chord
>spanning a ninth == five spaces, then why is it incorrect to have three
>dots for a chord spanning three spaces?
>The place that her rules stop making sense is this inconsistency:
>1. It's ok to have a dot a full two staff positions away from the top or
>bottom of the chord.
>2. BUT... if there's a dot that according to the rules turns up to be two
>spaces away, don't place ANY notes outside the range of spaces occupied
>by the chord *.
>* spaces occupied by the chord includes the half space occupied by part
>of a notehead on a line.

But this "inconsistency" that you find, is exactly illustrated in her
examples.  She shows *precisely* the behavior you find inconsistent as the
recommended behavior. See Gould2.png.  Gould is silent on whether the
spaces occupied by the chord includes the half-space or not, and none of
her examples include a note that would use the half-space.  So I don't
disagree with you.

>I think what she actually meant, and basing this also on guides like the
>ABRSM theory books, is
>
>- every note needs a dot, where possible
>- notes on a line need their dot moving up or down to the nearest space
>- sometimes the dot needs to shift away from its parent, and that's ok
>within the compass of the chord

In your example 14, with a dots limit of 3, the dot from the E moves to
the F space, and the dot from the F moves to the A space (within the
compass of the chord), and you consider the dot on the A space to be
unnecessary.  So my interpretation of your personal preference is that
you'd prefer to never have a dot moved more than one staff position away
from its "home".

Gould would put the dot in the A space, according to the written rules.
You accept it, but believe it's unnecessary.  If it's unnecessary, I think
we should leave it out, because it's just clutter.  I'm reading that if
you had your preferred style, it would be left out.  And I think LilyPond
should have some way to support your preferred style.

>- dots two or more staff _positions_ (not staff _spaces_ as written) away
>from the top or bottom of the chord look strange, so exclude those.

Gould specifically shows dot patterns with dots two staff positions away
from a note in a space.  I included them previously, and include them
again here as gould1.png.

Note that in gould2.png, the dots that would be only two staff positions
(one space) away from the top and bottom of the chord *are* excluded, not
just the one that is four positions (two spaces) away.

I'm going to send you (by separate email) a scan of Gould's section on
dotted notes.  I'd be happy to have you show me how I've misunderstood her
rules (if in fact I have).  But I'm quite sure that I have them right
(with the possible exception of the spaces occupied by the chord including
the half-spaces of notes on the line).

>
>Pragmatically though, I strongly believe it's a mistake for Lilypond's
>defaults to go against the grain of what most readers of music expect and
>have learnt to expect, even if the holy grail appears to say it's "right".

Counterexamples from high-quality hand-engraved music are certainly
welcome.   Contrary rules from other notation experts (e.g. Ross, Read,
Stone) are also welcome.  I agree that we should do what's right.
Sometimes the challenge is deciding what's right.

I will check Read and Ross tonight.  I don't remember if I still have
Stone or not.  If I do, I'll check it as well.

Thanks,

Carl

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

Re: Auto Place text after last beat of a Text Spanner

[Simon Albrecht]

On 15.09.2016 22:13, dtsmarin wrote:

Hi everyone!

Is it possible in Lilypond to create a function that detects the last
note\beat


Writing LilyPond code does influence habits…


  of a text spanner and then places a markup on the following beat?

e.g. \spanner { %music  } r <- here the function should place automatically
a markup ...


Easy – use an empty chord:
(I may assume you’re using development versions?)

\version "2.19.47"
ottavaWithLoco =
#(define-music-function (mus) (ly:music?)
  #{
\set Staff.ottavation = 1
$mus
\set Staff.ottavation = 0
<>^\markup \italic "loco"
  #})

HTH, Simon

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

Re: Augmentation dot positioning

[Paul]

On 09/15/2016 12:41 PM, Chris Yate wrote:

I think the trouble with Gould's rules is that they're inconsistent, 
or could at least be interpreted in such a way.  She says to use dots 
only on the spaces occupied by the chord, and yet says you MAY need to 
put a dot a space or more away from the chord.


On 09/15/2016 09:36 AM, Chris Yate wrote:

the key is the last bit of Gould's text as quoted by Brian above:

"When a dot is forced to be two or more stave-spaces from the chord, 
its function becomes less relevant. In such cases,//use only as many 
dots as cover the number of stave-spaces taken up by the chord."




Hi Chris,  As I read this quote, Gould's recommendation to "use only as 
many dots as cover the number of stave-spaces taken up by the chord" 
only applies "when a dot is forced to be two or more stave-spaces from 
the chord" because she limits her recommendation to "in such cases".


Maybe such a strict reading resolves what you are seeing as an 
inconsistency, at least as far as the logic of this quote goes.


(All of that said, I don't know why her recommendation for such cases is 
not just to "omit any dots that would be two or more stave-spaces from 
the chord" instead... but I claim no expertise here.)


Anyway, I agree that providing a way to adjust the output as desired 
would be great, and it seems like Carl is on top of it.


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

Re: Initial clef change in piano score

[Simon Albrecht]

On 15.09.2016 22:25, Malte Meyn wrote:

Am 15.09.2016 um 21:46 schrieb Simon Albrecht:

if in a piano score the right hand begins in bass clef, it is customary
to write a treble clef first and change to bass clef after the time
signature, presumably to draw more attention. Is there any more elegant
way than this kind of fake in LilyPond?


http://lsr.di.unimi.it/LSR/Item?id=792
http://lsr.di.unimi.it/LSR/Item?id=956


Thanks, that’s good. I prefer the former.

Best, Simon

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

Re: Augmentation dot positioning

[Chris Yate]

On 15 Sep 2016 22:45, "Carl Sorensen"  wrote:
>
>
> On 9/15/16 10:41 AM, "Chris Yate"  wrote:>
> >
> >I think the trouble with Gould's rules is that they're inconsistent, or
> >could at least be interpreted in such a way.  She says to use dots only
> >on the spaces occupied by the chord, and yet says you MAY need to put a
> >dot a space or more away from the chord.
>
> No, let me summarize Gould's rules.
>
> Rule 1: Every notehead in a chord must take a duration dot.
>
> Rule 2: Move dots away from a note head on a line by moving it either up
> or down (she has some guidelines for how to do this, but I'm skipping them
> right now)
>
> Rule 3: Every dot needs to have a staff space to itself.  This implies
> (although it's not explicitly stated, but it is shown) that you may need
> to move dots farther than one staff space away from the note head.
>
> Rule 4: Center the dots on the chord.  This fixes problems that may show
> up by applying rule 3.
>
> Rule 5: If one of the remaining dots is two or more staff spaces from the
> chord, the dot pattern is bad, so instead of having one dot per note head,
> just have one dot per staff space included in the chord.
>
> Every example she shows is consistent with these rules.  The examples you
> show from Sibelius are not consistent with these rules.  That doesn't make
> them wrong, just inconsistent with Gould.
>
>
> >
> >
> >
> >At the very least, we should be able to decide in our own scores what
> >logic is used for dot placement :-)
>
> Yes.  Perhaps we could make a scheme callback for cleaning up dots.  And
> that could become a property of a DotColumn, and the user would be free to
> implement their own Scheme function for cleaning up the dots.
>
> >
> >
> >Are you editing the code in dot-column.cc. or is there some Scheme code
> >for this too?
>
> Just editing code in dot-column.cc.  No Scheme code anywhere that I can
> see.
>
> So what rules do you use to decide when a dot is necessary below the
> bottom note of a chord, above the top of a chord, or in the middle of a
> chord with an interval larger than a third?
>
> Looking at your statements in Dots.ly, I would infer the following rules:
>
>
> 1. Put dots next to note heads on staff spaces.
> 2. Put dots in the space above note heads on staff lines.  If the space is
> already taken, and the space below the note head is available, place the
> dot in the space below the note head.  If the space is already taken, and
> the space below the note head is taken as well, omit the dot.
>
>
> I think those two rules provide the dots that you have considered to be
> necessary in Dots.ly, without any of the dots you consider unnecessary.

Please note I'm working without her examples,  but I disagree about
[Lilypond's interpretation of] Gould's rules, because they appear to be in
contradiction with **every piece of published music I've ever seen**.

Given just her text, I think she has possibly not worded things as clearly
as possible. And if it is correct to have five dots on a chord spanning a
ninth == five spaces, then why is it incorrect to have three dots for a
chord spanning three spaces?

The place that her rules stop making sense is this inconsistency:

1. It's ok to have a dot a full two staff positions away from the top or
bottom of the chord.

2. BUT... if there's a dot that according to the rules turns up to be two
spaces away, don't place ANY notes outside the range of spaces occupied by
the chord *.

* spaces occupied by the chord includes the half space occupied by part of
a notehead on a line.

I think what she actually meant, and basing this also on guides like the
ABRSM theory books, is

- every note needs a dot, where possible
- notes on a line need their dot moving up or down to the nearest space
- sometimes the dot needs to shift away from its parent, and that's ok
within the compass of the chord
- dots two or more staff _positions_ (not staff _spaces_ as written) away
from the top or bottom of the chord look strange, so exclude those.

Pragmatically though, I strongly believe it's a mistake for Lilypond's
defaults to go against the grain of what most readers of music expect and
have learnt to expect, even if the holy grail appears to say it's "right".

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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 10:41 AM, "Chris Yate"  wrote:

>On Thu, 15 Sep 2016 at 17:33 Carl Sorensen  wrote:
>
>
>
>I note that sib1.png is exactly the same chord as in the Gould scan.  And
>it has two less dots than Gould shows.  So it's not consistent with Gould.
>
>
>
>
>I'm not quite sure what she's showing in that example you scanned, but I
>thought it was about centering the dots.

It is about centering the dots.  But it is also exactly the same chord you
use in sib1.png.  And it has 5 dots, not three dots.

>
> 
>I think the trouble with Gould's rules is that they're inconsistent, or
>could at least be interpreted in such a way.  She says to use dots only
>on the spaces occupied by the chord, and yet says you MAY need to put a
>dot a space or more away from the chord.

No, let me summarize Gould's rules.

Rule 1: Every notehead in a chord must take a duration dot.

Rule 2: Move dots away from a note head on a line by moving it either up
or down (she has some guidelines for how to do this, but I'm skipping them
right now)

Rule 3: Every dot needs to have a staff space to itself.  This implies
(although it's not explicitly stated, but it is shown) that you may need
to move dots farther than one staff space away from the note head.

Rule 4: Center the dots on the chord.  This fixes problems that may show
up by applying rule 3.

Rule 5: If one of the remaining dots is two or more staff spaces from the
chord, the dot pattern is bad, so instead of having one dot per note head,
just have one dot per staff space included in the chord.

Every example she shows is consistent with these rules.  The examples you
show from Sibelius are not consistent with these rules.  That doesn't make
them wrong, just inconsistent with Gould.


> 
> 
>
>At the very least, we should be able to decide in our own scores what
>logic is used for dot placement :-)

Yes.  Perhaps we could make a scheme callback for cleaning up dots.  And
that could become a property of a DotColumn, and the user would be free to
implement their own Scheme function for cleaning up the dots.

>
>
>Are you editing the code in dot-column.cc. or is there some Scheme code
>for this too?

Just editing code in dot-column.cc.  No Scheme code anywhere that I can
see.

So what rules do you use to decide when a dot is necessary below the
bottom note of a chord, above the top of a chord, or in the middle of a
chord with an interval larger than a third?

Looking at your statements in Dots.ly, I would infer the following rules:


1. Put dots next to note heads on staff spaces.
2. Put dots in the space above note heads on staff lines.  If the space is
already taken, and the space below the note head is available, place the
dot in the space below the note head.  If the space is already taken, and
the space below the note head is taken as well, omit the dot.


I think those two rules provide the dots that you have considered to be
necessary in Dots.ly, without any of the dots you consider unnecessary.

Thanks,

Carl


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

Re: Initial clef change in piano score

[Malte Meyn]

Am 15.09.2016 um 21:46 schrieb Simon Albrecht:

if in a piano score the right hand begins in bass clef, it is customary
to write a treble clef first and change to bass clef after the time
signature, presumably to draw more attention. Is there any more elegant
way than this kind of fake in LilyPond?


http://lsr.di.unimi.it/LSR/Item?id=792
http://lsr.di.unimi.it/LSR/Item?id=956

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

Initial clef change in piano score

[Simon Albrecht]

Hello,

if in a piano score the right hand begins in bass clef, it is customary 
to write a treble clef first and change to bass clef after the time 
signature, presumably to draw more attention. Is there any more elegant 
way than this kind of fake in LilyPond?


\version "2.19.47"
{
  \clef treble
  s1*1/100
  \clef bass
  1*99/100
}

Best, Simon

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

Re: Dynamics inside a chord?

[Robert Schmaus]

Not sure if that's also acceptable, but what *does* work is use of 
simultaneous voices:


\version "2.19.44"
\new Voice <<
  { a }
  { b\p }
>>



Am 14/09/16 um 14:49 schrieb David Kastrup:

Menu Jacques  writes:


Hello folks,

Just for a try:

\version "2.19.44"

\relative {  }

runs fine without any message, but also without displaying the \p mark:


Not supported.



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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 8:01 AM, "Chris Yate"  wrote:

>On Thu, 15 Sep 2016 at 14:36 Chris Yate  wrote:
>
>
>> According to Gould, I believe that dots limit 3 is the correct setting.
>
>
>
>
>
>OK. On reflection, perhaps I can see your reasoning, although I disagree
>that the current situation reliably produces the notation one would
>expect. And it's insufficiently controllable.

I believe I agree that it's insufficiently controllable.

>
>
>In any case, I might argue "chord-dots-limit" isn't unambiguously
>explained
>
>
>". Limits the column of dots on each chord to the height of the chord
>plus chord-dots-limit staff-positions."

I would change the wording to say something like "The maximum distance
between the extreme dot on a dot column and the closest note on a chord
must be less than or equal to chord-dots-limit staff positions."

>
>
>In situation 1 in my test cases, the height of the chord is 4
>staff-positions... or is it 2 and a half staff-spaces?

In situation 1, the dot in the A space is one staff-space (two staff
positions) above the top of the chord; the dot in the B space is one-half
staff space (one staff position) below the bottom of the chord.

> 
>
>
>Should I want in example 2, to have dots on the D, F, A spaces and not on
>B, then chord-dots-limit=1 might be interpreted to suppress the dot
>that's 2 staff positions away from the chord (on B space) and place one 1
>staff position _above_ the chord, on
> A.  The dotsUp and dotsDown settings don't appear to have any effect
>here.

I see your point here.  It seems that we ought to be able to set
chords-dots-limit to 2, and then get the dots on the D, F and A instead of
B, D, and F.  And perhaps we have no property that will allow this to
happen.

Thanks,

Carl



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

Re: Augmentation dot positioning

[Chris Yate]

On Thu, 15 Sep 2016 at 17:33 Carl Sorensen  wrote:

>
> I note that sib1.png is exactly the same chord as in the Gould scan.  And
> it has two less dots than Gould shows.  So it's not consistent with Gould.
>

I'm not quite sure what she's showing in that example you scanned, but I
thought it was about centering the dots.

If the trim rule for Gould were "trim to the chord spaces if the dot
> spaces are two or more staff spaces larger than the chord spaces", then
> we'd get the Sibelius output.
>

If you could check what she shows for the 9th-spanned cluster chord (which
Brian mentioned above) -- Brian said she shows only five dots there. So
perhaps she's not self-consistent.


> The current logic doesn't reflect Gould's rules at all, as it only refers
> to the number of staff positions taken by the chord, not the number of
> staff spaces taken by the chord.  And Gould clearly considers staff spaces
> to be the important metric in her rules.
>

I think the trouble with Gould's rules is that they're inconsistent, or
could at least be interpreted in such a way.  She says to use dots only on
the spaces occupied by the chord, and yet says you MAY need to put a dot a
space or more away from the chord.


> So the challenge is to figure out a way to implement Gould's rules with
> some adjustable parameter that allow us to get Sibelius's rules.


At the very least, we should be able to decide in our own scores what logic
is used for dot placement :-)

Are you editing the code in dot-column.cc. or is there some Scheme code for
this too?

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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 10:11 AM, "Chris Yate"  wrote:

>For the sake of argument, here's what Sibelius does in similar
>circumstances, and which I think is right, and actually within the spirit
>of Gould's coments.

I note that sib1.png is exactly the same chord as in the Gould scan.  And
it has two less dots than Gould shows.  So it's not consistent with Gould.

If the trim rule for Gould were "trim to the chord spaces if the dot
spaces are two or more staff spaces larger than the chord spaces", then
we'd get the Sibelius output.

The current logic doesn't reflect Gould's rules at all, as it only refers
to the number of staff positions taken by the chord, not the number of
staff spaces taken by the chord.  And Gould clearly considers staff spaces
to be the important metric in her rules.

So the challenge is to figure out a way to implement Gould's rules with
some adjustable parameter that allow us to get Sibelius's rules.

I'll have to think about it a bit.  My current change improved some
things, but made others worse.

But I'm sure it's doable.

Thanks,

Carl


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

Re: Augmentation dot positioning

[Chris Yate]

For the sake of argument, here's what Sibelius does in similar
circumstances, and which I think is right, and actually within the spirit
of Gould's coments.

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

Re: conditional when-property function not working as intended

[David Kastrup]

Kieren MacMillan  writes:

> Hi all,
>
> Solved my own problem (I think?): the modified version (below) appears to 
> work as expected.
>
> On a related topic: I [clearly] don’t understand when “layout props”
> is necessary, and when it’s not.

It's necessary for functions taking "layout props" arguments?  Where
would that cause reason for doubt?

-- 
David Kastrup

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

Re: Augmentation dot positioning

[Chris Yate]

On Thu, 15 Sep 2016 at 16:37 Carl Sorensen  wrote:That
certainly is strange.  I wonder why it drops to four dots instead of

> 5, given that there are 5 notes in the cluster.  And the G space dot would
> only be two staff positions away from the E.
>
> I'm looking into the code now.  I'll see if I can figure out what's going
> on.
>
> Thanks,
>
> Carl
>

There appears to be a bias towards placing dots beneath the chord in
certain conditions.

Apparently there's an example in Gould of chords spanning a ninth, such as:

A)
\new Staff {
 \relative c' { 2. }
}
and
B)
\new Staff {
  \relative c' { 2. }
}

for A, dots limit 0 or 1 gives a sensible result with five dots, as does 4
or 5 with seven -- depending on your preference.

for B,  we need dots limit 3 to get six evenly spaced dots. Any higher than
4 and theres unnecessary dots.

Hopefully you'll find something :)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: conditional when-property function not working as intended

[David Kastrup]

Kieren MacMillan  writes:

> Hello all,
>
> In the snippet included below, I’m hoping the second line of the 
> scoreTitleMarkup will take no vertical space. If you comment out that line, 
> you’ll see that it *does* take no space, but when it’s included, so is the 
> 25mm spacing that is [I thought] conditional on the presence of a ‘testB’ 
> property in the property.
>
> Where is my code going wrong?
> More precisely, how can I make it work as intended?  =)
>
> Thanks,
> Kieren.
>
>   SNIPPET BEGINS
> \version "2.19.46"
>
> #(define-markup-command (when-property layout props symbol markp) (symbol? 
> markup?)
>   (if (chain-assoc-get layout props symbol markp)
>   (interpret-markup layout props markp)
>   empty-stencil))

 -- Function: ly:chain-assoc-get key achain default-value
  strict-checking
 Return value for KEY from a list of alists ACHAIN.  If no entry is
 found, return DEFAULT-VALUE or ‘#f’ if DEFAULT-VALUE is not
 specified.  [...]

DEFAULT-VALUE is specified as markp, and a markup is never #f.  So your
condition is always true when the specified KEY cannot be found.

-- 
David Kastrup

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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 8:35 AM, "Chris Yate"  wrote:
>
>Thanks -- but that example is about balancing the dots around a chord,
>which I believe we're not disagreed about.  (This scanned example is
>related her statement about not placing the dots in one direction).

I believe the first chord \relative c'{ 4.} is exactly analogous
to your case 2 -- four note cluster, space at the bottom.  And the bottom
dot is one staff space below the bottom note of the chord.

>
>
>And yet: 
>
>\relative c' { 2. }
>does not produce the output she suggests for this chord. I need
>chord-dots-limit = 4 for that.

That certainly is strange.  I wonder why it drops to four dots instead of
5, given that there are 5 notes in the cluster.  And the G space dot would
only be two staff positions away from the E.

I'm looking into the code now.  I'll see if I can figure out what's going
on.

Thanks,

Carl


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

Re: conditional when-property function not working as intended

[Kieren MacMillan]

Hi all,

Solved my own problem (I think?): the modified version (below) appears to work 
as expected.

On a related topic: I [clearly] don’t understand when “layout props” is 
necessary, and when it’s not.
Is this explained in the docs somewhere?

Thanks,
Kieren.

  SNIPPET BEGINS
\version "2.19.46"

#(define-markup-command (when-property layout props symbol markp) (symbol? 
markup?)
  (if (chain-assoc-get symbol props)
  (interpret-markup layout props markp)
  empty-stencil))

#(define-markup-command (mm-feed layout props amount) (number?)
 (let ((o-s (ly:output-def-lookup layout 'output-scale)))
   (ly:make-stencil "" '(0 . 0) (cons 0 (abs (/ amount o-s))

#(define-markup-command (put-mm layout props dir amount arg)
 (ly:dir? number? markup?) (interpret-markup layout props
   (markup #:put-adjacent Y dir arg #:mm-feed amount)))

\header {
  testA = "True!"
  testC = "True!"
}

\paper {
  scoreTitleMarkup = \markup \center-column {
\when-property #'header:testA { \put-mm #UP #25 \fromproperty 
#'header:testA }
\when-property #'header:testB { \put-mm #UP #25 \fromproperty 
#'header:testB }
\when-property #'header:testC { \put-mm #UP #25 \fromproperty 
#'header:testC }
  }
}

\score {
  c'4
}
  SNIPPET 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

conditional when-property function not working as intended

[Kieren MacMillan]

Hello all,

In the snippet included below, I’m hoping the second line of the 
scoreTitleMarkup will take no vertical space. If you comment out that line, 
you’ll see that it *does* take no space, but when it’s included, so is the 25mm 
spacing that is [I thought] conditional on the presence of a ‘testB’ property 
in the property.

Where is my code going wrong?
More precisely, how can I make it work as intended?  =)

Thanks,
Kieren.

  SNIPPET BEGINS
\version "2.19.46"

#(define-markup-command (when-property layout props symbol markp) (symbol? 
markup?)
  (if (chain-assoc-get layout props symbol markp)
  (interpret-markup layout props markp)
  empty-stencil))

#(define-markup-command (mm-feed layout props amount) (number?)
 (let ((o-s (ly:output-def-lookup layout 'output-scale)))
   (ly:make-stencil "" '(0 . 0) (cons 0 (abs (/ amount o-s))

#(define-markup-command (put-mm layout props dir amount arg)
 (ly:dir? number? markup?) (interpret-markup layout props
   (markup #:put-adjacent Y dir arg #:mm-feed amount)))

\header {
  testA = "True!"
  testC = "True!"
}

\paper {
  scoreTitleMarkup = \markup \center-column {
\when-property #'header:testA { \put-mm #UP #25 \fromproperty 
#'header:testA }
\when-property #'header:testB { \put-mm #UP #25 \fromproperty 
#'header:testB }
\when-property #'header:testC { \put-mm #UP #25 \fromproperty 
#'header:testC }
  }
}

\score {
  c'4
}
  SNIPPET 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: Ties between words in lyrics

[David Wright]

On Wed 14 Sep 2016 at 18:49:03 (-0700), James Evensen wrote:
> When I said "tie," I meant that general family of expressive marks as I
> wasn't sure how to refer to them in the context of lyrics.

Well I've always called them ties if only because the character
itself is called an undertie (Unicode 0x203F), plus the fact that
they're always horizontal.

> In fact, while
> I would like the use of any type of curve, the dotted slur is the notation
> I want to use.

I can't understand the logic of making it dotted. To me, a dotted slur
indicates that sometimes it's required, sometimes not. The reason
might be strophic lyrics (as in the ding-dong example I attached
earlier) or multiple languages where the underlay, perhaps even the
note lengths, differ.

Because a lyric tie joins two particular words, none of that
variability applies, which is why I wouldn't dot it. If I felt
it was rather editorial to insert it, I'd add [].

> It sounds though that support for this kind of notation with lyrics isn't
> here yet.  I'm inserting "n.b." as markup where the choir isn't supposed to
> breathe at the moment, but if this ever gets added, I'd be most interested.
> 
> On Wed, Sep 14, 2016 at 10:37 AM, Kieren MacMillan 
>  wrote:
> 
> > > In choral music, I've noticed that the composer will sometimes use this
> > notation to indicate that the singer is not to breathe in-between two
> > particular words.
> >
> > In my experience, the more standard/accepted way is to have a dotted slur
> > between the notes, with the lyric-slur reserved for true elisions. In fact,
> > I’ve *never* seen what you’re talking about, despite having sung in and
> > composed for choirs for thirty years. Do you have references/scans that you
> > can share?

Your emphatic *never* made me worry that Willcocks and OUP were
perhaps the only people who did this (and I have loads of OUP choral
music), but then it occurred to me that if you rub shoulders only with
urtext publishers: Peters, Breitkopf & Härtel, Bärenreiter and the
like, you might never see such practical markings as occur in what one
could call "performance editions", designed for mass markets and
amateur singers. Copies that have things like breath marks,
apostrophised words, and cautionary accidentals that good singers don't need.

So I glanced at a few other publishers' works on my shelves and came across:

Novello "The Novello book of carols":
Several in the two versions of "Noël Nouvelet".
One in Riley's "Our Lady's Lullaby".

Shorter House "Sing evensong":
Earis's "God grant us grace" (overriding the punctuation).

Hymnbooks where the verses are written underneath the score
are stuffed full of "carry-overs" at the line breaks.
Then I remembered that some English-style hymnbooks transcribe
plainsong hymns with the lyrics between the tune and an organ
accompaniment. Here are a few:

Norwich Press "Hymns A Revised (1950)":
"Now, my tongue", v2, ...condescending‿ To be born...
"O Lord Jesus, I adore thee", v3, ...whatsoever‿ Will...
"Thee we adore, O hidden Saviour", v3, ...may know‿ The hope...
The way they're printed, it looks as if, like LP, they're
challenged in this area (the gap after the ‿ ).

Let me know if these references are too obscure and you require more scans.

Cheers,
David.

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

Re: Augmentation dot positioning

[Chris Yate]

On Thu, 15 Sep 2016 at 15:22 Carl Sorensen  wrote:

>
>
> On 9/15/16 7:36 AM, "Chris Yate"  wrote:
>
> >Carl, the key is the last bit of Gould's text as quoted by Brian above:
> >"When a dot is forced to be two or more stave-spaces from the chord, its
> >function becomes less relevant. In such cases, use only as many dots as
> >cover the number of stave-spaces taken up by the chord."
> >In my 30-odd years experience of reading music I don't think I've ever
> >seen augmentation dots extending even a full space away from a chord
> >(apart from moving a half-step above or below a line-note).
>
> Please see attached scan from Gould.
>
> Thanks,
>
> Carl


Thanks -- but that example is about balancing the dots around a chord,
which I believe we're not disagreed about.  (This scanned example is
related her statement about not placing the dots in one direction).

And yet:
\relative c' { 2. }
does not produce the output she suggests for this chord. I need
chord-dots-limit = 4 for that.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 7:36 AM, "Chris Yate"  wrote:

>Carl, the key is the last bit of Gould's text as quoted by Brian above:
>"When a dot is forced to be two or more stave-spaces from the chord, its
>function becomes less relevant. In such cases, use only as many dots as
>cover the number of stave-spaces taken up by the chord."
>In my 30-odd years experience of reading music I don't think I've ever
>seen augmentation dots extending even a full space away from a chord
>(apart from moving a half-step above or below a line-note).

Please see attached scan from Gould.

Thanks,

Carl

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

Re: Augmentation dot positioning

[Chris Yate]

On Thu, 15 Sep 2016 at 14:36 Chris Yate  wrote:

> > According to Gould, I believe that dots limit 3 is the correct setting.
>

OK. On reflection, perhaps I can see your reasoning, although I disagree
that the current situation reliably produces the notation one would expect.
And it's insufficiently controllable.

In any case, I might argue "chord-dots-limit" isn't unambiguously explained

". Limits the column of dots on each chord to the height of the chord plus
chord-dots-limit staff-positions."

In situation 1 in my test cases, the height of the chord is 4
staff-positions... or is it 2 and a half staff-spaces?

Should I want in example 2, to have dots on the D, F, A spaces and not on
B, then chord-dots-limit=1 might be interpreted to suppress the dot that's
2 staff positions away from the chord (on B space) and place one 1 staff
position _above_ the chord, on A.  The dotsUp and dotsDown settings don't
appear to have any effect here.

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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/13/16 11:53 AM, "Chris Yate"  wrote:

>
>Thanks Werner. That's potentially a useful workaround. But the default
>behaviour is obviously broken. There's no way I should see a dot placed
>on the space above or below a note on a space -- obviously notes on a
>line are a different matter.  As far as I can tell the default should be
>never to place the dot more than one staff position away from the top or
>bottom note of a chord.

Gould's rule disagree with your assertion.  Gould specifically shows good
examples with dots both above and below a note on a space. She also shows
an error where a dot one staff space above the chord is removed (I'll try
to get scans today).

The only trimming Gould does (which LilyPond may not do, I guess) is that
if the full set of dots would result in a dot that is two or more staff
spaces away from the upper or lower note of the chord, the dots are
trimmed to cover the staff spaces taken up by the chord.

Thanks,

Carl


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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/14/16 9:05 AM, "Chris Yate"  wrote:
>
>
>
>Attached with some extra cases I'd forgotten about (the inverted versions
>of the final 6.

According to Gould, I believe that dots limit 3 is the correct setting.

Case 1: Gould says that the dot in the A space is correct.  The only dots
she removes are dots that are 2 staff spaces or more away from the chord
(p. 56); the A space is only one staff space away.

Case 2: Similarly, the B space dot is correct according to Gould.

Case 9: Just as in case 2, the B space dot is correct.

Case 10: The C space dot is correct according to Gould -- one staff space
above chord.

Case 12: See cases 2 and 9; B space dot is one staff space below chord

Case 13: I am unsure about the G dot -- it's one and a half staff spaces
below the chord, so by Gould's strict rule, it should be there, I guess.
But I prefer it gone.

Case 14: I'm not sure why you consider the A space dot unnecessary.
According to Gould's rules, it should be there.

Case 15: Same as case 14.

Case 16: As in cases 2 and 9, Gould suggests the B space dot belongs.

Case 17: Same as 16

Case 18: Same as 16

Case 19: Same as 16

Case 20: Gould's rules say A space dot is correct.

Case 21: Same as 20

Case 23: Same as 16

Case 24: Gould's rules say G space dot is correct.

Case 25: Gould's rules say B space dot is correct.

In short, dots limit 3 never fails according to Chris's rules, and appears
to me to be exactly correct with respect to Gould's rules.  So I have a
hard time seeing what the issue is.

Thanks,

Carl





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

Re: Augmentation dot positioning

[Chris Yate]

On 15 Sep 2016 14:27, "Carl Sorensen"  wrote:
>
>
>
> On 9/14/16 9:05 AM, "Chris Yate"  wrote:
> >
> >
> >
> >Attached with some extra cases I'd forgotten about (the inverted versions
> >of the final 6.
>
> According to Gould, I believe that dots limit 3 is the correct setting.
>
> Case 1: Gould says that the dot in the A space is correct.  The only dots
> she removes are dots that are 2 staff spaces or more away from the chord
> (p. 56); the A space is only one staff space away.
>
> Case 2: Similarly, the B space dot is correct according to Gould.
>
> Case 9: Just as in case 2, the B space dot is correct.
>
> Case 10: The C space dot is correct according to Gould -- one staff space
> above chord.
>
> Case 12: See cases 2 and 9; B space dot is one staff space below chord
>
> Case 13: I am unsure about the G dot -- it's one and a half staff spaces
> below the chord, so by Gould's strict rule, it should be there, I guess.
> But I prefer it gone.
>
> Case 14: I'm not sure why you consider the A space dot unnecessary.
> According to Gould's rules, it should be there.
>
> Case 15: Same as case 14.
>
> Case 16: As in cases 2 and 9, Gould suggests the B space dot belongs.
>
> Case 17: Same as 16
>
> Case 18: Same as 16
>
> Case 19: Same as 16
>
> Case 20: Gould's rules say A space dot is correct.
>
> Case 21: Same as 20
>
> Case 23: Same as 16
>
> Case 24: Gould's rules say G space dot is correct.
>
> Case 25: Gould's rules say B space dot is correct.
>
> In short, dots limit 3 never fails according to Chris's rules, and appears
> to me to be exactly correct with respect to Gould's rules.  So I have a
> hard time seeing what the issue is.
>
> Thanks,
>
> Carl

Carl, the key is the last bit of Gould's text as quoted by Brian above:

"When a dot is forced to be two or more stave-spaces from the chord, its
function becomes less relevant. In such cases,* use only as many dots as
cover the number of stave-spaces taken up by the chord*."

In my 30-odd years experience of reading music I don't think I've ever seen
augmentation dots extending even a full space away from a chord (apart from
moving a half-step above or below a line-note).

On 15 Sep 2016 14:27, "Carl Sorensen"  wrote:



On 9/14/16 9:05 AM, "Chris Yate"  wrote:
>
>
>
>Attached with some extra cases I'd forgotten about (the inverted versions
>of the final 6.

According to Gould, I believe that dots limit 3 is the correct setting.

Case 1: Gould says that the dot in the A space is correct.  The only dots
she removes are dots that are 2 staff spaces or more away from the chord
(p. 56); the A space is only one staff space away.

Case 2: Similarly, the B space dot is correct according to Gould.

Case 9: Just as in case 2, the B space dot is correct.

Case 10: The C space dot is correct according to Gould -- one staff space
above chord.

Case 12: See cases 2 and 9; B space dot is one staff space below chord

Case 13: I am unsure about the G dot -- it's one and a half staff spaces
below the chord, so by Gould's strict rule, it should be there, I guess.
But I prefer it gone.

Case 14: I'm not sure why you consider the A space dot unnecessary.
According to Gould's rules, it should be there.

Case 15: Same as case 14.

Case 16: As in cases 2 and 9, Gould suggests the B space dot belongs.

Case 17: Same as 16

Case 18: Same as 16

Case 19: Same as 16

Case 20: Gould's rules say A space dot is correct.

Case 21: Same as 20

Case 23: Same as 16

Case 24: Gould's rules say G space dot is correct.

Case 25: Gould's rules say B space dot is correct.

In short, dots limit 3 never fails according to Chris's rules, and appears
to me to be exactly correct with respect to Gould's rules.  So I have a
hard time seeing what the issue is.

Thanks,

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

Re: calculation of the total duration of a score

[Marc Hohl]

Am 14.09.2016 um 14:24 schrieb Marc Hohl:
[...]

I thought of writing the duration to a external file to be read from
within the markup call in the score to be printed, but did not follow
this route any further yet.


Update: a simple test file shows that this works.

I can

- compute the total duration of a file designed for
  midi output only by means of your engraver
- write the duration to a file and
- read that string while processing the "print-only" file.

Merging that stuff together with some Makefile should be 
straightforward, I hope ;-)


And it has the advantage that some MIDI-related changes do not appear in 
the printed score, but the duration will be updated accordingly.


Cheers,

Marc


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