Re: Docs: inconsistency about ly:context-pushpop-property

[James]

Hello,

On 19/10/15 03:07, Paul Morris wrote:
>> On Oct 18, 2015, at 4:21 AM, David Kastrup  wrote:
>>
>> It does a "\temporary \override".  Well spotted.
> Thanks for clarifying that and for pointing out the other similar updates 
> that are needed.  Improving the doc strings would definitely help matters.

Issue created

https://sourceforge.net/p/testlilyissues/issues/4639/

James

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

Re: Docs: inconsistency about ly:context-pushpop-property

[Paul Morris]

> On Oct 18, 2015, at 4:21 AM, David Kastrup  wrote:
> 
> It does a "\temporary \override".  Well spotted.

Thanks for clarifying that and for pointing out the other similar updates that 
are needed.  Improving the doc strings would definitely help matters.

-Paul


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

Re: Docs: inconsistency about ly:context-pushpop-property

[David Kastrup]

Paul Morris  writes:

> The docs appear to be inconsistent about ly:context-pushpop-property.
> Does it do a \temporary \override or just an \override ?
>
> -Paul
>
> _
>
> ly:context-pushpop-property
>
> do a \temporary \override or a \revert on a grob property
>
> http://www.lilypond.org/doc/v2.19/Documentation/extending/context-evaluation
>
> _
>
> Function: ly:context-pushpop-property context grob eltprop val
>
> Do a single \override or \revert operation in context. The grob
> definition grob is extended with eltprop (if val is specified) or
> reverted (if unspecified).
>
> http://lilypond.org/doc/v2.19/Documentation/internals/scheme-functions

It does a "\temporary \override".  Well spotted.

We also have the following definitions:

(define-public (make-grob-property-set grob gprop val)
  "Make a @code{Music} expression that sets @var{gprop} to @var{val} in
@var{grob}.  Does a pop first, i.e., this is not an override."
  (make-music 'OverrideProperty
  'symbol grob
  'grob-property gprop
  'grob-value val
  'pop-first #t))

(define-public (make-grob-property-override grob gprop val)
  "Make a @code{Music} expression that overrides @var{gprop} to @var{val}
in @var{grob}."
  (make-music 'OverrideProperty
  'symbol grob
  'grob-property gprop
  'grob-value val))

Which we need to maintain for compatibility, along with
make-voice-props-set and make-voice-props-override and
override-heads-style.

In all of those cases, "override" means "\temporary \override" while
"set" means "\override".

Maybe one should at least fix the documentation strings.  Like
"i.e., this is not a @code{\\temporary \\override}."

and "that temporarily overrides" or "that does a @code{\\temporary
\\override}".

Apart from inventing the actual \temporary command, I merely inherited
this mess.  Before \temporary, there was just "\override" which did the
same as the Scheme functions "*-set" rather than "*-override", namely
always implying pop-first = #t .

-- 
David Kastrup

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

Re: Docs: Line length page and line-width property

[Federico Bruni]

2014-07-01 15:18 GMT+02:00 Paul Morris p...@paulwmorris.com:

 In the Notation Reference, this page[1] is called Line length but the
 property that it covers (among others) is called line-width.  Seems like
 it would be better if the title of the page was Line width for greater
 consistency.

 [1] http://lilypond.org/doc/v2.19/Documentation/notation/line-length


Thanks, added:
https://code.google.com/p/lilypond/issues/detail?id=3982
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Docs: example for line-break-permission and page-break-permission

[James]

Hello,

On 27/02/14 09:06, Trevor Daniels wrote:
 Paul Morris wrote Tuesday, February 25, 2014 7:44 PM

 That means that this statement is potentially misleading:

 Lily sometimes rejects explicit \break and \pageBreak commands. There are
 two commands to override this behavior:
 Well, Lily does sometimes reject explicit breaks, for example when they
 are placed in the middle of an incomplete bar:

   { a4 a8 a4 a \break a a a a a8 \break a4 a a a }

 but the following commands do not override this behaviour.  So in this
 respect the two statements are misleading.  But are there other circumstances 
 where both sentences as written are correct?  I can't think of any.
  
 So I like James' suggestion for a more thorough explanation that would
 remove this ambiguity.
 Indeed.  I think we need a tracker to record this discussion and the
 eventual conclusion.  Bug Squad: could you please set one up?
Finally (!)

http://code.google.com/p/lilypond/issues/detail?id=3960

James


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

Re: Docs: example for line-break-permission and page-break-permission

[Trevor Daniels]

Paul Morris wrote Tuesday, February 25, 2014 7:44 PM

 That means that this statement is potentially misleading:
 
 Lily sometimes rejects explicit \break and \pageBreak commands. There are
 two commands to override this behavior:

Well, Lily does sometimes reject explicit breaks, for example when they
are placed in the middle of an incomplete bar:

  { a4 a8 a4 a \break a a a a a8 \break a4 a a a }

but the following commands do not override this behaviour.  So in this
respect the two statements are misleading.  But are there other circumstances 
where both sentences as written are correct?  I can't think of any.
 
 So I like James' suggestion for a more thorough explanation that would
 remove this ambiguity.

Indeed.  I think we need a tracker to record this discussion and the
eventual conclusion.  Bug Squad: could you please set one up?

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

Re: Docs: example for line-break-permission and page-break-permission

[Trevor Daniels]

James wrote Tuesday, February 25, 2014 5:58 AM

 On 24/02/14 21:18, Paul Morris wrote:
 The example given here:
 http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks
 
 While not addressing your suggestion directly, but being one of the few 
 doc editors I am not sure this part of the Notation Reference has been 
 'touched' for a while - certainly since I started helping (back in 2011) 
 and when we have since had many spacing/break code improvement changes - 
 I seem to recall that we were on 2.12 back then.

Probably not; I've never edited this section AFAIR.
 
 This whole document section doesn't follow standard policy; again, not 
 that that casts any aspersions on your email but just using the term 
 'Lily' instead of LilyPond, and seeing no useful TexInfo references to 
 other, related the parts of the documentation (this is more of a 
 editorial discussion than anything for me).

If you're thinking of working on this page it would be good to tidy it
up a little (as a separate commit of course).

However, I'm not sure that the change proposed by Paul is correct.
I think the current wording is correct.

Try this, and you'll see the long line runs off the right side of the page.
No line break is inserted to prevent it; only the manual ones are actioned.

\paper {
  indent = #0
  ragged-right = ##t
  ragged-bottom = ##t
}

music = \relative c'' { c8 c c c }

\score {
  \new Staff {
\repeat unfold 4 { \music } \break
\repeat unfold 20 { \music } \break
\repeat unfold 4 { \music } \break
  }
  \layout {
\context {
  \Score
  \override NonMusicalPaperColumn.line-break-permission = ##f
  \override NonMusicalPaperColumn.page-break-permission = ##f
}
  }
}

 
 While examples are helpful of course I am wondering if we could better 
 explain some of these functions/commands than having to 'waste' pages of 
 webspace and documentation with literal (and verbatim) \pageBreak examples?
 
 Trevor do you see what I mean?

Yes.  I'd remove the pagebreak from this example (since its effect is not
clear in the docs anyway); use a smaller example showing a line break being
inserted and being suppressed; and simply say page-break-permission
works the same way.  I'd also give the music variable a full bar of notes
rather than half a bar so the repeat counts correspond with the number
of bars in the lines.

I've not really looked at the other examples, but if you want to propose
changes please do it one example at a time.

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

Re: Docs: example for line-break-permission and page-break-permission

[Paul Morris]

Trevor Daniels wrote
 However, I'm not sure that the change proposed by Paul is correct.
 I think the current wording is correct.
 
 Try this, and you'll see the long line runs off the right side of the
 page.
 No line break is inserted to prevent it; only the manual ones are
 actioned.

I tried this and I see what you mean.  Also this for testing pagebreak:

\paper {
  indent = #0
  ragged-right = ##t
  ragged-bottom = ##t
}

music = \relative c'' { c8 c c c c c c c }

\score {
  \new Staff {
\repeat unfold 110 { \music } 
  }
  \layout {
\context {
  \Score
  \override NonMusicalPaperColumn.page-break-permission = ##f
}
  }
}

No auto page breaks were inserted, the music was compressed onto one page,
and I got these:
warning: cannot fit music on page: overflow is 27.591750
warning: compressing music to fit

So I think Trevor is right that this is an accurate statement:

When line-break-permission is overridden to false, Lily will insert line
breaks at explicit \break commands and nowhere else. When
page-break-permission is overridden to false, Lily will insert page breaks
at explicit \pageBreak commands and nowhere else.

(And if that's the case then it convinces me that what I reported in the
other thread is indeed a bug.)

That means that this statement is potentially misleading:

Lily sometimes rejects explicit \break and \pageBreak commands. There are
two commands to override this behavior:

If these commands prevent automatic breaks, then that is different from, and
unrelated to, preventing rejecting explicit breaks.

So I like James' suggestion for a more thorough explanation that would
remove this ambiguity.


Trevor Daniels wrote
 Yes.  I'd remove the pagebreak from this example (since its effect is not
 clear in the docs anyway); use a smaller example showing a line break
 being
 inserted and being suppressed; and simply say page-break-permission
 works the same way.  I'd also give the music variable a full bar of notes
 rather than half a bar so the repeat counts correspond with the number
 of bars in the lines.

This makes sense to me.  Here's a smaller and more focused example:

% default output
\repeat unfold 10 { c'4 c' c' c' } 

% automatic line breaks suppressed
\score {
  \new Staff {
\repeat unfold 10 { c'4 c' c' c' } 
  }
  \layout {
\context {
  \Score
  \override NonMusicalPaperColumn.line-break-permission = ##f
}
  }
}

Maybe a clearer name for these commands would have been:

  automatic-line-breaks = ##f
  automatic-page-breaks = ##f

-Paul





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Docs-example-for-line-break-permission-and-page-break-permission-tp159803p159851.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Docs: example for line-break-permission and page-break-permission

[James]

On 24/02/14 21:18, Paul Morris wrote:

The example given here:
http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks


While not addressing your suggestion directly, but being one of the few 
doc editors I am not sure this part of the Notation Reference has been 
'touched' for a while - certainly since I started helping (back in 2011) 
and when we have since had many spacing/break code improvement changes - 
I seem to recall that we were on 2.12 back then.


This whole document section doesn't follow standard policy; again, not 
that that casts any aspersions on your email but just using the term 
'Lily' instead of LilyPond, and seeing no useful TexInfo references to 
other, related the parts of the documentation (this is more of a 
editorial discussion than anything for me).


While examples are helpful of course I am wondering if we could better 
explain some of these functions/commands than having to 'waste' pages of 
webspace and documentation with literal (and verbatim) \pageBreak examples?


Trevor do you see what I mean?

James

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

Re: docs: #' no longer needed with \tag, \removeWithTag, \keepWithTag

[James]

On 26/12/13 07:51, David Kastrup wrote:

James pkx1...@gmail.com writes:


Anyway, it is useful I think to mention this somehow in the
documenation, but apart from numerals what other characters would
break LP's syntax in this specific regard?

Words are formed by letters and non-ASCII characters, with single
hyphens or underlines allowed inside.

So -wer--g-i-e--l-
splits into - wer -- g-i-e -- l -

Anything outside of the basic ASCII range behaves like a letter.


So if I have this right (sorry to be so dull about this) you said:

\tag #'violin1

but you cannot write

\tag violin1


So could you write

\tag violin-one

or

\tag violin£

or

\tag violin

which as far as I can tell, are non-ASCII characters.

James

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

Re: docs: #' no longer needed with \tag, \removeWithTag, \keepWithTag

[James]

On 26/12/13 10:29, David Kastrup wrote:

James pkx1...@gmail.com writes:


On 26/12/13 07:51, David Kastrup wrote:

James pkx1...@gmail.com writes:


Anyway, it is useful I think to mention this somehow in the
documenation, but apart from numerals what other characters would
break LP's syntax in this specific regard?

Words are formed by letters and non-ASCII characters, with single
hyphens or underlines allowed inside.

So -wer--g-i-e--l-
splits into - wer -- g-i-e -- l -

Anything outside of the basic ASCII range behaves like a letter.


So if I have this right (sorry to be so dull about this) you said:

\tag #'violin1

but you cannot write

\tag violin1


So could you write

\tag violin-one

or

\tag violin£

On my first computer, a veritable Nascom II, I had £ instead of # as
character 35 if I remember correctly.  But you are right: in this time
and day, it should work.


or

\tag violin

which as far as I can tell, are non-ASCII characters.

Yes, all of those should work as labels (or, following \, as the name
part of, uh, a control sequence?).  As would violin-I, violin①, violin②
and a few others.


Thanks, so looking at

http://lilypond.org/doc/v2.17/Documentation/notation/different-editions-from-one-source#using-tags

I wonder if we should now modify the example to use the 'new and 
improved' method of denoting the tag names as well as including the 
exceptions.


James

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

Re: docs: #' no longer needed with \tag, \removeWithTag, \keepWithTag

[James]

On 20/12/13 16:49, Paul Morris wrote:

David Kastrup wrote

One reason that has not been done is that the names of context and grob
properties are under our control.

Tags are under user control.

You can write

\tag #'violin1

but you cannot write

\tag violin1

since violin1 does not obey the syntax for what LilyPond considers a
word.

Ok, I see.  That makes sense.  Thanks for explaining.

If you're only using one or two tags here or there it doesn't make a big
difference.  However, I was just creating some piano music with fingerings
on almost every other note, and tagging each fingering so that I could also
render the music without them.  I found it to be a lot easier to type and
read without the #' when I was entering that many tags.  So I was really
glad that I stumbled upon this new possibility.

FWIW, I do think it would be nice to somehow let users know about this new
syntax, as an option, with a disclaimer about not using numbers, etc.  But
I'm not sure what's the best way to do that.  Maybe it's better to just keep
it as it is for now, especially with 2.18 right around the corner and other
things taking priority.  I'm happy to leave it in the capable hands of the
dev team.


...

On 20/12/13 16:53, David Kastrup wrote:

Paul Morris p...@paulwmorris.com writes:


(Just curious... Is the idea to eventually make \tag violin1 work, and then
update the docs at that point?)

No.  cis1 must remain split into cis and 1, and the look for notenames
is done once a word has been recognized.

Well we could add an @knownissue or @warning - whatever is appropriate. 
@warning puts a box around the text which may not be appropriate but I 
am not sure that the word 'issue' in @knownissue has any implications 
for the user (i.e. it is a problem to be 'fixed').


Anyway, it is useful I think to mention this somehow in the 
documenation, but apart from numerals what other characters would break 
LP's syntax in this specific regard?


James

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

Re: docs: #' no longer needed with \tag, \removeWithTag, \keepWithTag

[David Kastrup]

James pkx1...@gmail.com writes:

 Anyway, it is useful I think to mention this somehow in the
 documenation, but apart from numerals what other characters would
 break LP's syntax in this specific regard?

Words are formed by letters and non-ASCII characters, with single
hyphens or underlines allowed inside.

So -wer--g-i-e--l-
splits into - wer -- g-i-e -- l -

Anything outside of the basic ASCII range behaves like a letter.

-- 
David Kastrup

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

Re: docs: #' no longer needed with \tag, \removeWithTag, \keepWithTag

[Paul Morris]

David Kastrup wrote
 One reason that has not been done is that the names of context and grob
 properties are under our control.
 
 Tags are under user control.
 
 You can write
 
 \tag #'violin1
 
 but you cannot write
 
 \tag violin1
 
 since violin1 does not obey the syntax for what LilyPond considers a
 word.

Ok, I see.  That makes sense.  Thanks for explaining.

If you're only using one or two tags here or there it doesn't make a big
difference.  However, I was just creating some piano music with fingerings
on almost every other note, and tagging each fingering so that I could also
render the music without them.  I found it to be a lot easier to type and
read without the #' when I was entering that many tags.  So I was really
glad that I stumbled upon this new possibility.

FWIW, I do think it would be nice to somehow let users know about this new
syntax, as an option, with a disclaimer about not using numbers, etc.  But
I'm not sure what's the best way to do that.  Maybe it's better to just keep
it as it is for now, especially with 2.18 right around the corner and other
things taking priority.  I'm happy to leave it in the capable hands of the
dev team.

(Just curious... Is the idea to eventually make \tag violin1 work, and then
update the docs at that point?)

Thanks again for the explanation,
-Paul





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/docs-no-longer-needed-with-tag-removeWithTag-keepWithTag-tp156200p156207.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Docs bug: \once prefix

[drippingtone]

 Slightly changing the example in the documentation illustrates this:

 c4 d
 \override NoteHead #'color = #red
 e4 f |
 \once \override NoteHead #'color = #green
 g4 a
 \revert NoteHead #'color
 b c |

 A single note is green, then we continue with red notes until we use \revert 
 to
 get the default color (black).
[...]

 Doesn't it already explain this in the section before (explaining the
 \revert command)?

Yes, the \revert command is properly explained.


My main concern is updating this sentence (after \once we go back to
the current value, not the default value):

 [...] effective only during the current musical moment before the property
 reverts back to its default value.

 It should say something like : reverts back to its current value (this can 
 be
 different from the default if an \override is in effect).


Changing the code example to have an \override in effect (red color)
would explicitly show this: after using \once we go back to (red
color), not to the context's default (black color).
In my opinion this doesn't overly complicate the manual, and might be
more clear.

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

Re: Docs bug: \once prefix

[James]

Hello,

On 1 January 2012 11:14, DrippingTone drippingtone+lilyp...@gmail.com wrote:
 The documentation for the \once prefix (both v2.14 and v2.15) at:
 http://lilypond.org/doc/v2.14/Documentation/learning/tweaking-methods
 says:

 [...] effective only during the current musical moment before the property
 reverts back to its default value.

 It should say something like : reverts back to its current value (this can be
 different from the default if an \override is in effect).

 Slightly changing the example in the documentation illustrates this:

 c4 d
 \override NoteHead #'color = #red
 e4 f |
 \once \override NoteHead #'color = #green
 g4 a
 \revert NoteHead #'color
 b c |

 A single note is green, then we continue with red notes until we use \revert 
 to
 get the default color (black).


 I think the learning manual can fully explain this without becoming overly
 complicated (this is the natural expectation from the English keyword \once).


Doesn't it already explain this in the section before (explaining the
\revert command)?

-- 
--

James

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

Re: Docs bug: \once prefix

[James]

Hello,

On 1 January 2012 12:02,  drippingt...@gmail.com wrote:
 Slightly changing the example in the documentation illustrates this:

 c4 d
 \override NoteHead #'color = #red
 e4 f |
 \once \override NoteHead #'color = #green
 g4 a
 \revert NoteHead #'color
 b c |

 A single note is green, then we continue with red notes until we use 
 \revert to
 get the default color (black).
 [...]

 Doesn't it already explain this in the section before (explaining the
 \revert command)?

 Yes, the \revert command is properly explained.


 My main concern is updating this sentence (after \once we go back to
 the current value, not the default value):

 [...] effective only during the current musical moment before the property
 reverts back to its default value.

 It should say something like : reverts back to its current value (this can 
 be
 different from the default if an \override is in effect).


 Changing the code example to have an \override in effect (red color)
 would explicitly show this: after using \once we go back to (red
 color), not to the context's default (black color).
 In my opinion this doesn't overly complicate the manual, and might be
 more clear.

http://code.google.com/p/lilypond/issues/detail?id=2164thanks=2164

Patch uploaded for review.

Thanks

-- 
--

James

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

Re: Docs: new spacing era

[Jean-Charles Malahieude]

Le 14/11/2010 17:17, Mark Polesky disait :


Jean-Charles Malahieude wrote:

Do you mean that It is the
@code{default-staff-staff-spacing} property of each
staff's @code{VerticalAxisGroup} grob that will be used
when @code{staff-staff-spacing} is defined neither in
@code{StaffGrouper} nor @code{VerticalAxisGroup}?


Yes.  However, there are still some changes coming to this
file.  I probably should have warned the translators.  See
http://codereview.appspot.com/3089042/.  This particular
oddity was a by-product of the renaming convertrule.  It is
addressed in the Rietveld post.  I'll probably make Trevor's
suggestion and then push that patch today.



So, just a collateral victim.
OK. I just have to pull and carry over these adjustments...
I've not jumped deep into this (r)evolution; it was just this double 
instance both staff-staff-spacing and staff-staff-spacing that made 
happen the tilt.



The other big adjustments to spacing.itely will be coming
from some version of this post
http://codereview.appspot.com/2758042/.  But I'm not
finished with that one either.

Sometimes I feel bad for the translators when I make these
huge changes all at once  But it's really a weird (and
neat) feeling to have my words reach people across
languages.  I really appreciate all the work you've done and
are doing!



Too bad for me to have attacked spacing before input... I shall wait 
before opening vocal!



Feel free to let me know if I have any annoying stylistic
idiosyncracies; sometimes I wonder if I overuse the
semi-colon, for example.  (:

- Mark


As long as I make the point, I don't mind. Rephrasing is fully part of 
the translation process!


And many thanks for this brainstorming that, in my very small opinion, 
might help even non English speaking users.


Cheers,
Jean-Charles

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: docs: Stems info in Editorial annotations section?

[Trevor Daniels]

Valentin Villenave wrote Sunday, January 11, 2009 2:44 PM



2008/12/7 Mark Polesky markpole...@yahoo.com:

NR 1.7.1 Editorial annotations: Inside the staff
(strangely) contains the info on stems directions.


It makes sense to me (strangely).


How are stem directions related to editorial annotations?
I think the Stem entry would be better placed either in
1.2 Rhythms or 1.5.2 Simultaneous notes: Multiple voices.


That should be mentioned as a link.

Trevor, thoughts?


Hi Valentin

I'm still catching up with my old in-tray 

I agree.  The direction of the stem has nothing to do with
the rhythm but I'll add Stems to the See also lists in 1.2.1 Durations.

It does have more to do with separating voices, but this is usually
set automatically by other commands.  The _manual_ setting of the
stem direction _is_ an editorial decision, so the current placement
seems right to me.  I'll add a link in the See also list in 1.5.2 
Single-staff

polyphony too, though.

I'll also move the index entry for stem, direction to the top of the
Stem section.


Cheers,
Valentin


Trevor



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: docs: Stems info in Editorial annotations section?

[Valentin Villenave]

2008/12/7 Mark Polesky markpole...@yahoo.com:
 NR 1.7.1 Editorial annotations: Inside the staff
 (strangely) contains the info on stems directions.

It makes sense to me (strangely).

 How are stem directions related to editorial annotations?
 I think the Stem entry would be better placed either in
 1.2 Rhythms or 1.5.2 Simultaneous notes: Multiple voices.

That should be mentioned as a link.

Trevor, thoughts?

Cheers,
Valentin


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: docs

[Graham Percival]

On 4-Sep-05, at 3:49 AM, Han-Wen Nienhuys wrote:


Graham Percival wrote:
I'm accepting suggestions.  This example is created from 
input/test/script-chart.ly ;

the names are done as lyrics.  How can you space out lyrics ?


handling of texts changed since 2.4; I've removed the reference to 
lyrics from the docs of word-space. Try setting SeparationItem 
#'padding.


Thanks!  That works.

Cheers,
- Graham



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: docs

[Han-Wen Nienhuys]

Graham Percival wrote:
I'm accepting suggestions.  This example is created from 
input/test/script-chart.ly ;

the names are done as lyrics.  How can you space out lyrics ?



According to the documentation, you might get the impression that
  \override Score.LyricText  #'word-space = #2
should do the job, but it seems that word-space doesn't affect
the spacing between lyrics syllables. Bug!?


I think so.  input/test/script-chart.ly  also has extra lines after the 
names,

like this;
  \context Lyrics \lyricmode {
accent__
  }
which I assume is also aimed at ensuring some space between words.

In addition, there was plenty of space between words in 2.4.x, so I think
this is a regression.



handling of texts changed since 2.4; I've removed the reference to 
lyrics from the docs of word-space. Try setting SeparationItem #'padding.


--
 Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: docs

[Mats Bengtsson]

Graham Percival wrote:


On 30-Aug-05, at 3:38 AM, Hans de Rijck wrote:

6.5.1 Articulations

In the chart showing all scripts available, can there be some spacing
between the words, they are now almost impossible to decipher, for 
example

the third line reads:
   rheelltoertoeopenstoppedturnreverseturn



I'm accepting suggestions.  This example is created from 
input/test/script-chart.ly ;

the names are done as lyrics.  How can you space out lyrics ?


According to the documentation, you might get the impression that
  \override Score.LyricText  #'word-space = #2
should do the job, but it seems that word-space doesn't affect
the spacing between lyrics syllables. Bug!?



6.5.3 Dynamics

Please add a line how to get dynamics aligned. It's now very implicit.



Please tell me how to.  :)


What I mean is, your example
c\ c\! d\ e\!
leads to a crescendo and a decrescendo that don't align (very ugly!).
If you do a small concession and write:
c\ c\! \ d e\!
they are perfectly aligned. Of course it would be better if you could 
order

lilypond to automatically align dynamics, but we can't have it all.



I'm reluctant to do this, because it has a different musical meaning (ie 
the
decresc starts on the c, not the d).  Currently the manual example 
demonstrates

the way lilypond handles most cresc/decresc.  I think the best way to
handle this is to improve lilypond's cresc handling, as Trevor suggested.


Maybe we should at least describe the current mechanism, namely that
all dynamics (absolute or (de)crescendi) that occur at or begin or end 
at one and the same note  will be vertically aligned.


/Mats


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: docs

[Trevor Bača]

On 8/31/05, Mats Bengtsson [EMAIL PROTECTED] wrote:
 
 
 Graham Percival wrote:
 
snip
  I'm reluctant to do this, because it has a different musical meaning (ie
  the
  decresc starts on the c, not the d).  Currently the manual example
  demonstrates
  the way lilypond handles most cresc/decresc.  I think the best way to
  handle this is to improve lilypond's cresc handling, as Trevor suggested.
 
 Maybe we should at least describe the current mechanism, namely that
 all dynamics (absolute or (de)crescendi) that occur at or begin or end
 at one and the same note  will be vertically aligned.

Agreed. Probably also best to note that the vertical alignment of
hairpins will be starting at left note-edge and ending at right
note-edge (as not everyone may have been around for the thread that
went on about that particular point.)


-- 
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: docs

[Graham Percival]

On 31-Aug-05, at 5:55 AM, Mats Bengtsson wrote:


Graham Percival wrote:
I'm accepting suggestions.  This example is created from 
input/test/script-chart.ly ;

the names are done as lyrics.  How can you space out lyrics ?


According to the documentation, you might get the impression that
  \override Score.LyricText  #'word-space = #2
should do the job, but it seems that word-space doesn't affect
the spacing between lyrics syllables. Bug!?


I think so.  input/test/script-chart.ly  also has extra lines after the 
names,

like this;
  \context Lyrics \lyricmode {
accent__
  }
which I assume is also aimed at ensuring some space between words.

In addition, there was plenty of space between words in 2.4.x, so I 
think

this is a regression.

HTH,
- Graham



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: docs

[Graham Percival]

On 31-Aug-05, at 5:55 AM, Mats Bengtsson wrote:

I'm reluctant to do this, because it has a different musical meaning 
(ie the
decresc starts on the c, not the d).  Currently the manual example 
demonstrates

the way lilypond handles most cresc/decresc.  I think the best way to
handle this is to improve lilypond's cresc handling, as Trevor 
suggested.


Maybe we should at least describe the current mechanism, namely that
all dynamics (absolute or (de)crescendi) that occur at or begin or end 
at one and the same note  will be vertically aligned.


OK, done.  Also with Trevor's suggestion.

Cheers,
- Graham



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond