Re: doc addition: IR v2.20.0, 3.1.9 Arpeggio, positions

[James]

Hello Owain

On 26/08/2020 02:47, Owain Evans wrote:

Hi Bug-Lily,

In IR v2.20.0
3.1.9 Arpeggio, positions (pair of numbers),
http://lilypond.org/doc/v2.20/Documentation/internals/arpeggio

Says (left . right). Should read (bottom . top).
Please change to read:

Pair of staff coordinates (bottom . top), where both bottom and top are in 
staff-space units of the current staff. For slurs, this value is (left-vertical 
. right-vertical) and selects which slur candidate to use; if extreme positions 
are requested, the closest one is taken.

"The for slurs part" I've change so it makes sense, but unsure if
"(left-vertical . right-vertical)" too verbose or correct naming convention.

An example of it so it's clear it's (bottom . top) not (left . right)
\version "2.20.0"
{
   \override Staff.Arpeggio.positions = #'(-4 . 4)
   \arpeggio
}
Please could it be corrected.
Many thanks,

Owain Evans


Thanks for taking the time.

https://gitlab.com/lilypond/lilypond/-/issues/6029

James


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

Re: Doc bug in Snippets HTML: "indepently" should be "independently"

[Thomas Morley]

Am Mi., 24. Juni 2020 um 22:05 Uhr schrieb Kenneth Wolcott
:
>
> Doc bug in Snippets HTML: "indepently" should be "independently" in
> the snippet titled "Changing the number of augmentation dots per note"
> in the  "Rhythms" section.
>
> Ken Wolcott

Hi Ken,

thanks for your report.
It's a doc-tagged LSR-snippet, thus I've fixed it inside LSR
http://lsr.di.unimi.it/LSR/Item?id=800

Will appear corrected in our docs after next lsr-import.

Cheers,
  Harm

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

Re: Doc typo

[Pierre Perol-Schneider]

Thank you David.

Le ven. 5 avr. 2019 à 23:16, David Kastrup  a écrit :

> Pierre Perol-Schneider  writes:
>
> >> Le ven. 5 avr. 2019 à 17:33, David Kastrup  a écrit:
> >>
> >>> Pierre Perol-Schneider  writes:
> >>>
> >>> > Hi Bug Squad,
> >>> >
> >>> > In LM 2.18, A.10.3 & LM 2.19, A.11.3 (graphic), above "\oval arg"
> >>> > It shows:
> >>> > "[...] Use thickness, x-padding, x-padding and [...]"
> >>> > Instead of:
> >>> > "[...] Use thickness, x-padding, y-padding and [...]"
> >>>
> >>> That's not LM but NR.  Pushed a fix.
> >
> > Oops, sorry, "LM" was for LilyPond Manual.
>
> "Learning Manual" "Notation Reference"
>
> > Anyway, no push from here possible, that's why I asked the squad.
>
> "pushed", not "push".  Short for "I have taken the liberty and pushed a
> fix".
>
> --
> David Kastrup
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Doc typo

[David Kastrup]

Pierre Perol-Schneider  writes:

>> Le ven. 5 avr. 2019 à 17:33, David Kastrup  a écrit:
>>
>>> Pierre Perol-Schneider  writes:
>>>
>>> > Hi Bug Squad,
>>> >
>>> > In LM 2.18, A.10.3 & LM 2.19, A.11.3 (graphic), above "\oval arg"
>>> > It shows:
>>> > "[...] Use thickness, x-padding, x-padding and [...]"
>>> > Instead of:
>>> > "[...] Use thickness, x-padding, y-padding and [...]"
>>>
>>> That's not LM but NR.  Pushed a fix.
>
> Oops, sorry, "LM" was for LilyPond Manual.

"Learning Manual" "Notation Reference"

> Anyway, no push from here possible, that's why I asked the squad.

"pushed", not "push".  Short for "I have taken the liberty and pushed a
fix".

-- 
David Kastrup

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

Re: Doc typo

[Pierre Perol-Schneider]

Oops, sorry, "LM" was for LilyPond Manual.
Anyway, no push from here possible, that's why I asked the squad.

Le ven. 5 avr. 2019 à 17:33, David Kastrup  a écrit :

> Pierre Perol-Schneider  writes:
>
> > Hi Bug Squad,
> >
> > In LM 2.18, A.10.3 & LM 2.19, A.11.3 (graphic), above "\oval arg"
> > It shows:
> > "[...] Use thickness, x-padding, x-padding and [...]"
> > Instead of:
> > "[...] Use thickness, x-padding, y-padding and [...]"
>
> That's not LM but NR.  Pushed a fix.
>
> --
> David Kastrup
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Doc typo

[David Kastrup]

Pierre Perol-Schneider  writes:

> Hi Bug Squad,
>
> In LM 2.18, A.10.3 & LM 2.19, A.11.3 (graphic), above "\oval arg"
> It shows:
> "[...] Use thickness, x-padding, x-padding and [...]"
> Instead of:
> "[...] Use thickness, x-padding, y-padding and [...]"

That's not LM but NR.  Pushed a fix.

-- 
David Kastrup

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

Re: Doc: NR 4.2.2 layout-set-staff-size warning

[Palmer Ralph]

On Mon, Jan 14, 2019 at 11:48 AM Federico Bruni  wrote:
>
> Hi
>
> In the Notation Reference, chapter 4.2.2, there's this warning:
>
> layout-set-staff-size does not change the distance between the staff
> lines.
>
> What does it mean with "distance between the staff lines"?
> Isn't it the staff height? (as the distance between the staff lines is
> equal)
>

Hi, Federico - This has been entered as issue #5462. Thanks for the
report, and thanks (from me) for Frescobaldi!
Ralph

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

Re: Doc-snippet "Two \partcombine pairs on one staff" broken

[Thomas Morley]

Am So., 30. Dez. 2018 um 12:00 Uhr schrieb Thomas Morley
:
>
> Am So., 30. Dez. 2018 um 11:06 Uhr schrieb Thomas Morley
> :
> >
> > Hi,
> >
> > out of 
> > https://lists.gnu.org/archive/html/lilypond-devel/2018-12/msg00178.html
> >
> > The doc-tagged LSR-snippet "Two \partcombine pairs on one staff"
> > http://lsr.di.unimi.it/LSR/Item?id=958
> > is obviously inspired by
> > https://sourceforge.net/p/testlilyissues/issues/1321/?page=1=25#a054
> >
> > While it works with 2.18.2 as described, without error/warning, it does not 
> > with 2.19.82 and recent master.
> > http://lilypond.org/doc/v2.19/Documentation/snippets/simultaneous-notes#simultaneous-notes-two-_005cpartcombine-pairs-on-one-staff
> > Lots of warnings and the pdf is not as wished.
> >
> > Not sure how to fix.
> > Thoughts?
> >
> >
> > Cheers,
> >   Harm
>
> Attached a possible fix. Works with 2.18., 2.19.82 and (after
> convert-ly, i.e. partcombine->partCombine) with recent master.
> If no objections, I'll change the LSR-snippet. It will then be
> available in our docs after next LSR-import.


Done.

Cheers,
  Harm

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

Re: Doc-snippet "Two \partcombine pairs on one staff" broken

[Thomas Morley]

Am So., 30. Dez. 2018 um 11:06 Uhr schrieb Thomas Morley
:
>
> Hi,
>
> out of https://lists.gnu.org/archive/html/lilypond-devel/2018-12/msg00178.html
>
> The doc-tagged LSR-snippet "Two \partcombine pairs on one staff"
> http://lsr.di.unimi.it/LSR/Item?id=958
> is obviously inspired by
> https://sourceforge.net/p/testlilyissues/issues/1321/?page=1=25#a054
>
> While it works with 2.18.2 as described, without error/warning, it does not 
> with 2.19.82 and recent master.
> http://lilypond.org/doc/v2.19/Documentation/snippets/simultaneous-notes#simultaneous-notes-two-_005cpartcombine-pairs-on-one-staff
> Lots of warnings and the pdf is not as wished.
>
> Not sure how to fix.
> Thoughts?
>
>
> Cheers,
>   Harm

Attached a possible fix. Works with 2.18., 2.19.82 and (after
convert-ly, i.e. partcombine->partCombine) with recent master.
If no objections, I'll change the LSR-snippet. It will then be
available in our docs after next LSR-import.


Cheers,
  Harm
\layout {
  \context {
\Staff
\accepts "VoiceBox"
  }
  \context {
\name "VoiceBox"
\type "Engraver_group"
\defaultchild "Voice"
\accepts "Voice"
\accepts "NullVoice"
  }
}

partcombineUplsr =
#(define-music-function (p l partOne partTwo)
  (ly:music? ly:music?)
"Take the music in @var{partOne} and @var{partTwo} and return
a @code{VoiceBox} named @q{Up} containing @code{Voice}s
that contain @var{partOne} and @var{partTwo} merged into one
voice where feasible.  This variant sets the default voicing
in the output to use upward stems."
#{
  \new VoiceBox = "Up" <<
\context Voice = "one" { \voiceOne }
\context Voice = "two" { \voiceThree }
\context Voice = "shared" { \voiceOne }
\context Voice = "solo" { \voiceOne }
\context NullVoice = "null" {}
\partcombine #partOne #partTwo
  >>
#})

partcombineDownlsr = #
(define-music-function (p l partOne partTwo)
  (ly:music? ly:music?)
"Take the music in @var{partOne} and @var{partTwo} and return
a @code{VoiceBox} named @q{Down} containing @code{Voice}s
that contain @var{partOne} and @var{partTwo} merged into one
voice where feasible.  This variant sets the default voicing
in the output to use downward stems."
#{
  \new VoiceBox = "Down" <<
\set VoiceBox.soloText = #"Solo III"
\set VoiceBox.soloIIText = #"Solo IV"
\context Voice ="one" { \voiceFour }
\context Voice ="two" { \voiceTwo }
\context Voice ="shared" { \voiceFour }
\context Voice ="solo" { \voiceFour }
\context NullVoice = "null" {}
\partcombine #partOne #partTwo 
  >>
#})

soprano = { d'4 | cis'  b  e'  d'8 cis' | cis'2 b }
alto = { fis4 | e8 fis gis ais b4 b | b ais fis2 }
tenor = { a8 b | cis' dis' e'4 b8 cis' d'4 | gis cis' dis'2 }
bass = { fis8 gis | a4 gis g fis | eis fis b,2 }

\new Staff <<
  \key b\minor
  \clef alto
  \partial 4
  \transpose b b'
  \partcombineUplsr \soprano \alto
  \partcombineDownlsr \tenor \bass
>>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Doc: typo in keyboards.itely

[David Kastrup]

Federico Bruni  writes:

> $ git grep -n tremelo
> Documentation/notation/keyboards.itely:644:@item A
> @notation{bisbigliando} is written as a tremelo @ref{Tremolo
>
> tremelo > tremolo
>
> Can anybody push a fix?

Pushed to staging.

-- 
David Kastrup

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

Re: Doc 2.4.2: Indicating harmonics and dampened notes

[Pierre Perol-Schneider]

Federico, Harm, Thank you.

Le dim. 26 août 2018 à 12:03, Federico Bruni  a écrit :

>
>
> Il giorno dom 26 ago 2018 alle 11:43, Thomas Morley
>  ha scritto:
> >
> > Agreed. Also, why not delete some of the superfluous brackets in the
> > markup? Only keeping the surrounding ones for better viewable
> > structure. I.e.
> > \markup { \italic \fontsize #-2 "harm. 12" }
> >
> > Could you provide a patch?
> >
>
> Pierre, if you want to send a patch, here's the issue:
> https://sourceforge.net/p/testlilyissues/issues/5404/
>
> Thanks
> Federico
>
>
>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Doc 2.4.2: Indicating harmonics and dampened notes

[Federico Bruni]

Il giorno dom 26 ago 2018 alle 11:43, Thomas Morley 
 ha scritto:


Agreed. Also, why not delete some of the superfluous brackets in the
markup? Only keeping the surrounding ones for better viewable
structure. I.e.
\markup { \italic \fontsize #-2 "harm. 12" }

Could you provide a patch?



Pierre, if you want to send a patch, here's the issue:
https://sourceforge.net/p/testlilyissues/issues/5404/

Thanks
Federico




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

Re: Doc 2.4.2: Indicating harmonics and dampened notes

[Federico Bruni]

Il giorno dom 26 ago 2018 alle 11:14, Pierre Perol-Schneider 
<"pierre.schneider.paris"@gmail.com> ha scritto:

Hi Bug Squad,
See:
http://lilypond.org/doc/v2.18/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes
And:
http://lilypond.org/doc/v2.19/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes

1. I don't understand the reason to put the NoteHead defs at a Staff 
level.


I guess there isn't any reason, since Note_heads_engraver is part of 
the Voice context.


2. Maybe a whole note is not the best example to show the 
'harmonic-mixed

result.



Why? Because the diamond shape is more clear when the head is all black?


How about changing this snieppet:

\relative c' {
  \clef "treble_8"
  \override Staff.NoteHead.style = #'harmonic-mixed
  d^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 1
}

To:

\relative c' {
  \clef "treble_8"
  \override NoteHead.style = #'harmonic-mixed
  d8^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 4
}

Cheers,
Pierre
___



I agree. I will add an issue to the tracker.




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

Re: Doc 2.4.2: Indicating harmonics and dampened notes

[Thomas Morley]

2018-08-26 11:14 GMT+02:00 Pierre Perol-Schneider
:
> Hi Bug Squad,
> See:
> http://lilypond.org/doc/v2.18/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes
> And:
> http://lilypond.org/doc/v2.19/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes
>
> 1. I don't understand the reason to put the NoteHead defs at a Staff level.

Can't see a specific reason here. So I'd vote for deleting "Staff".

> 2. Maybe a whole note is not the best example to show the 'harmonic-mixed
> result.
>
> How about changing this snieppet:
>
> \relative c' {
>   \clef "treble_8"
>   \override Staff.NoteHead.style = #'harmonic-mixed
>   d^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 1
> }
>
> To:
>
> \relative c' {
>   \clef "treble_8"
>   \override NoteHead.style = #'harmonic-mixed
>   d8^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 4
> }
>
> Cheers,
> Pierre


Agreed. Also, why not delete some of the superfluous brackets in the
markup? Only keeping the surrounding ones for better viewable
structure. I.e.
\markup { \italic \fontsize #-2 "harm. 12" }

Could you provide a patch?

Cheers,
  Harm

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

Re: Doc: 2.19 changes cuts off varC clef

[Ophir Lifshitz]

Just a thought – could there be any other glyphs that have the same problem
and is it worth searching for them/adding systematic tests?

On Sun, Feb 25, 2018 at 11:55 AM, Werner LEMBERG  wrote:

> >> The metrics are fine, but the bboxes aren't.
> >
> > https://sourceforge.net/p/testlilyissues/issues/5278/  has been created
>
> Thanks!
>
>
> Werner
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Doc: 2.19 changes cuts off varC clef

[Werner LEMBERG]

>> The metrics are fine, but the bboxes aren't.
> 
> https://sourceforge.net/p/testlilyissues/issues/5278/  has been created

Thanks!


Werner

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

Re: Doc: 2.19 changes cuts off varC clef

[James Lowe]

Hello

On Sat, 24 Feb 2018 17:32:35 +0100 (CET), Werner LEMBERG  wrote:

> > This is a problem of bounding boxes.
> 
> Well...
> 
> > All the graphics files are being automatically cropped according to
> > the characters' bounding boxes and as all the varC clefs don't have
> > their proper heights and depths in Metafont, the "balls" will be cut
> > off.
> 
> ... we have to differentiate between the metrics used in lilypond
> (this is what the lilypond tables in the fonts contain) and the
> bounding boxes used for cropping.  The boxes you display in the image
> are the metrics used by lilypond.
> 
> > We should adapt the new clefs' bounding boxes to their actual size,
> > shouldn't we?
> 
> The metrics are fine, but the bboxes aren't.
> 
> 
> Werner


https://sourceforge.net/p/testlilyissues/issues/5278/  has been created

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

Re: Doc: 2.19 changes cuts off varC clef

[Joram]

Hi James,

> I'm not seeing it

But your picture shows it.

All the varC-clefs have round "dots". In your picture, the lower two
(tenorvarC and baritonevarC) have the lower "dot" inside the staff. All
others are cropped and flat - unlike the glyph itself.

Best,
Joram

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

Re: Doc: 2.19 changes cuts off varC clef

[Werner LEMBERG]

> This is a problem of bounding boxes.

Well...

> All the graphics files are being automatically cropped according to
> the characters' bounding boxes and as all the varC clefs don't have
> their proper heights and depths in Metafont, the "balls" will be cut
> off.

... we have to differentiate between the metrics used in lilypond
(this is what the lilypond tables in the fonts contain) and the
bounding boxes used for cropping.  The boxes you display in the image
are the metrics used by lilypond.

> We should adapt the new clefs' bounding boxes to their actual size,
> shouldn't we?

The metrics are fine, but the bboxes aren't.


Werner

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

Re: Doc: 2.19 changes cuts off varC clef

[Torsten Hämmerle]

Hi all,

This is a problem of bounding boxes.
All the graphics files are being automatically cropped according to the
characters' bounding boxes and as all the varC clefs don't have their proper
heights and depths in Metafont, the "balls" will be cut off.

tenorvarC is saved by the treble clef contained, but all the alto varC clefs
seem to have taken over the original C clefs' depth and height, totally
ignoring the balls outside that make them higher and deeper.

In this graphics I've marked the bounding boxes of clefs.tenorG and
clefs.varC in red:
clef-bounding-boxes.png
  
As soon as one of the varC clefs sticks out into the upper or lower margin,
everything that stands out from the bounding box will be cut off.

We should adapt the new clefs' bounding boxes to their actual size,
shouldn't we?

All the best,
Torsten





--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

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

Re: Doc: 2.19 changes cuts off varC clef

[James Lowe]

On Sat, 24 Feb 2018 15:14:37 + (GMT), "James Lowe"  
wrote:

> Hello Malte
> 
> On Sat, 24 Feb 2018 09:02:55 +0100, Malte Meyn  wrote:
> 
> > Hi list,
> > 
> > the four varC clefs at 
> > http://lilypond.org/doc/v2.19/Documentation/changes/ are cut off at the 
> > top (all) and bottom (varC/altovarC).

It also occurs here

http://lilypond.org/doc/v2.19/Documentation/notation/clef-styles

So I wonder if this is something to do with lilypond-book output from within 
TexInfo (when using @multitable with @tab constructs)?

Which both the changes.tely and notation-appendices.itely both use - I added 
those clefs in both those files.

James


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

Re: Doc: 2.19 changes cuts off varC clef

[James Lowe]

Hello

On Sat, 24 Feb 2018 16:19:44 +0100, Noeck  wrote:

> Hi James,
> 
> > I'm not seeing it
> 
> But your picture shows it.
> 
> All the varC-clefs have round "dots". In your picture, the lower two
> (tenorvarC and baritonevarC) have the lower "dot" inside the staff. All
> others are cropped and flat - unlike the glyph itself.

Well that wasn't quite how Malte described it

--snip--
are cut off at the 
top (all) and bottom (varC/altovarC).
--snip--

So I assumed he meant that the LilyPond-book created image was 'cut off' at the 
top and bottom of the 'staff' - I know we have some comments about this 
somewhere in the Tracker for PDF outputs/lilypond-book cropping (IIRC). 
Although all I could find was this

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

Anyway thanks for the clearer description. Yes I notice it now.

James

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

Re: Doc: 2.19 changes cuts off varC clef

[Noeck]

Hi James,

> I'm not seeing it

But your picture shows it.

All the varC-clefs have round "dots". In your picture, the lower two
(tenorvarC and baritonevarC) have the lower "dot" inside the staff. All
others are cropped and flat - unlike the glyph itself.

Best,
Joram

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

Re: Doc: 2.19 changes cuts off varC clef

[James Lowe]

Hello Malte

On Sat, 24 Feb 2018 09:02:55 +0100, Malte Meyn  wrote:

> Hi list,
> 
> the four varC clefs at 
> http://lilypond.org/doc/v2.19/Documentation/changes/ are cut off at the 
> top (all) and bottom (varC/altovarC).
> 
> Cheers,
> Malte

I'm not seeing it

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

Re: DOC: Correcting spelling of Harmonia Sacra in NR 1.1.4 Shape note heads

[Carl Sorensen]

On 9/30/17 4:46 PM, "David Kastrup"  wrote:

>Karlin High  writes:
>
>> This is a nitpick. The places in the documentation that reference the
>> "Harmonia Sacra" songbook by Joseph Funk have the spelling Harmonica
>> Sacra. Harmonia does not have a "c" here. A few references are below.
>> There are enough of them that a Google search for "Joseph Funk
>> Harmonica Sacra" gets auto-corrected.
>>
>> http://harmoniasacra.org/index.html
>> http://gameo.org/index.php?title=Harmonia_Sacra
>> https://www.amazon.com/Harmonia-Sacra-Joseph-Funk/dp/1932676155
>>
>> The attached patch has proposed corrections. Translated docs would be
>> affected; I do not know the process for that. Possible actions:
>>
>> * Forget it. Anyone who would be bothered by this is probably beyond
>>help.
>> * Fix directly in git like other typos
>> * Go through review and tracker like other patches
>
>I'd use option 2 here (of course, push to staging rather than master)
>after carefully reading the diff and making sure that no chapter/node
>names are affected (which would constitute a structural change and thus
>should be checked doing "make doc" before possibly inconveniencing
>others by a broken staging, either by checking yourself or creating an
>issue after all).
>
>We have had a fair share of "this could not possibly break compilation"
>kind of changes breaking compilation.
>
>Also any possibility for contention is worth a review.  This here seems
>solid enough to me.

I agree with David.

Thanks,

Carl


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

Re: DOC: Correcting spelling of Harmonia Sacra in NR 1.1.4 Shape note heads

[James Lowe]

Hello,

On Sat, 30 Sep 2017 17:14:02 -0500, Karlin High  wrote:

> This is a nitpick. The places in the documentation that reference the
> "Harmonia Sacra" songbook by Joseph Funk have the spelling Harmonica
> Sacra. Harmonia does not have a "c" here. A few references are below.
> There are enough of them that a Google search for "Joseph Funk
> Harmonica Sacra" gets auto-corrected.
> 
> http://harmoniasacra.org/index.html
> http://gameo.org/index.php?title=Harmonia_Sacra
> https://www.amazon.com/Harmonia-Sacra-Joseph-Funk/dp/1932676155
> 
> The attached patch has proposed corrections. Translated docs would be
> affected; I do not know the process for that. Possible actions:
> 
> * Forget it. Anyone who would be bothered by this is probably beyond help.
> * Fix directly in git like other typos
> * Go through review and tracker like other patches
> -- 
> Karlin High
> Missouri, USA

If in doubt ' * Go through review and tracker like other patches'.

Thanks.

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

has now been created for this.

James


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

Re: DOC: Correcting spelling of Harmonia Sacra in NR 1.1.4 Shape note heads

[David Kastrup]

Karlin High  writes:

> This is a nitpick. The places in the documentation that reference the
> "Harmonia Sacra" songbook by Joseph Funk have the spelling Harmonica
> Sacra. Harmonia does not have a "c" here. A few references are below.
> There are enough of them that a Google search for "Joseph Funk
> Harmonica Sacra" gets auto-corrected.
>
> http://harmoniasacra.org/index.html
> http://gameo.org/index.php?title=Harmonia_Sacra
> https://www.amazon.com/Harmonia-Sacra-Joseph-Funk/dp/1932676155
>
> The attached patch has proposed corrections. Translated docs would be
> affected; I do not know the process for that. Possible actions:
>
> * Forget it. Anyone who would be bothered by this is probably beyond help.
> * Fix directly in git like other typos
> * Go through review and tracker like other patches

I'd use option 2 here (of course, push to staging rather than master)
after carefully reading the diff and making sure that no chapter/node
names are affected (which would constitute a structural change and thus
should be checked doing "make doc" before possibly inconveniencing
others by a broken staging, either by checking yourself or creating an
issue after all).

We have had a fair share of "this could not possibly break compilation"
kind of changes breaking compilation.

Also any possibility for contention is worth a review.  This here seems
solid enough to me.

-- 
David Kastrup

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

Re: DOC: Typo in CG 2.2 Where to get lily-git, "auxiliar" not "auxillar"

[Werner LEMBERG]

> lily-git is part of the LilyPond source code and is located in
> ‘$LILYPOND_GIT/scripts/auxillar/lily-git.tcl’.
> 
> But since it's command text, I tripped over it. I remember reading
> that the main LilyPond contributors have a process to fix typos
> directly, without the review cycle? I'll leave it for that, unless
> instructed otherwise.

Fixed in git, thanks.


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

Re: doc clarification

[James Lowe]

Hello Martin,

On 29/07/16 21:32, catalaco - wrote:

The last paragraph of 1.2.2 LilyPond 
variables 
in Extending LilyPond is 
very hard to understand.
The whole thing might need to be rewritten but I don't understand enough to do 
that. All I can do is offer suggestions for rephrasing, although I might be 
misinterpreting as I'm not fully understanding what I'm reading!

Original text
---
The usual way to refer to Lilypond variables, LilyPond Scheme 
syntax,
 is to call them using a backslash, i.e., \twentyFour.
Since this creates a copy of the value for most of LilyPond’s internal types, 
in particular music expressions, music functions don’t usually create copies of 
material they change. For this reason, music expressions given with # should 
usually not contain material that is not either created from scratch or 
explicitly copied rather than directly referenced.
---


Rephrased
---
Lilypond variables are usually called using a backslash, e.g. \twentyFour (see 
LilyPond Scheme 
syntax),
 which creates a copy of the value. For that reason music functions in LilyPond don't 
usually create copies of material they change. Because of this, scheme music 
expressions written with the # syntax should not directly reference material. They 
should only be used for material created from scratch or explicitly copied.
---

Greetings,
Martin

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

Thanks, ticket created:

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

Regards


--
--

James


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

Re: DOC: Essay, 1.4 Building software

[Simon Albrecht]

On 22.07.2016 15:18, Pierre Perol-Schneider wrote:

It should be written :

{ 4 }


Without the {}, actually. They form a sequential music expression, and 
that step comes only later.



and not:

<>


I agree that it should be corrected. While it works (in an explicitly 
instantiated voice), I don’t think it’s good to showcase this syntax for 
writing a chord.



Examples that follow should also be corrected.


Only so much as to make it consistent: The steps would then be:
1) a single note
2) a chord
3) wrapping both sequentially
4) adding another music expression simultaneously.

Best, Simon

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

Re: DOC: Essay, 1.4 Building software

[Pierre Perol-Schneider]

My Dear David,

At the time I started this thread I was 100% sure that you would answer
something like this. ;)
Well, let's try to see former version :
http://lilypond.org/doc/v2.14/Documentation/essay/building-software, v2.14
says: "f4"
compare to
http://lilypond.org/doc/v2.19/Documentation/essay/building-software, v2.19
says: "f'4"
Why's that?...


2016-07-22 16:28 GMT+02:00 David Kastrup :

> Pierre Perol-Schneider  writes:
>
> > Hi James,
> >
> > Sorry for the misunderstanding.
> > Have you tried the snippet ? Have you seen the result ?
> >
> > It should be written :
> >
> > { 4 }
> >
> > and not:
> >
> > <>
> >
> > Examples that follow should also be corrected.
>
> Well, "corrected" is a hard word: they work as written and intended.
> The main question I see here is how we should treat "Essay": as an
> authored essay that we only keep compilable, or as something where we
> actually want to keep the _content_ tracking best _current_ practices.
>
> Is it an Urtext or do we not just keep it playable on current
> instruments but rather let it make best use of the state of art?
>
> Bach has written keyboard works where keeping in spirit with the score
> has required contortions and approximations on contemporary instruments
> that became considerably more playable over time.  As opposed to
> historic LilyPond, historic players did not have the luxury of flatly
> stating "syntax error" or "colliding notecolumns cannot be resolved", so
> the historic essay had to make do with historic LilyPond rather than a
> hypothetical idealization.
>
> Should we ask the authors?  Or should we at least change that stuff
> where one would say, as a current-day user of LilyPond, "ew, what?"?
>
> --
> David Kastrup
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: DOC: Essay, 1.4 Building software

[Pierre Perol-Schneider]

But of course.
Sorry for my poor english : \relative c' { \new Voice { <> } }
shows ok (of course) but <> does not.
This essay is really nice, and I want to use it for a presentation. But I
found this particular part unclear.

Cheers,
Pierre


2016-07-22 17:56 GMT+02:00 David Kastrup :

> "Phil Holmes"  writes:
>
> > "Pierre Perol-Schneider"  wrote in
> > message
> > news:caphotuwtxrmr97w5m2ajkt4sudvqdbd93tqudk0vfuogxh0...@mail.gmail.com.
> ..
> >>I clearly understand what you mean.
> >> Thing is that <> does not show what's on the picture (actually
> >> the link says: \relative c' { \new Voice { <> } } )
>
> It shows exactly what is on the picture.  Have you tried it?
>
> > I think very early versions of LilyPond used << notes >> for chords,
> > not < notes >.  The earliest manual I can find online (1.6) has the
> > latter notation, but it may be that the essay uses the early notation?
>
> I don't think so.  From what I gather, the original syntax would have
> used  for simultaneous music (which gets assembled into a
> chord anyway), then added the chord syntax <>4, then finally
> interchanged <<...>> and <...> in their meaning.
>
> However, <> still remains a valid way to enter music that will
> print as a chord (even though it will internally be represented as a
> SimultanousMusic expression rather than an EventChord, this does not
> affect typesetting).
>
> So the essay is correct here.  It may still look awkward given the
> current alternatives.
>
> --
> David Kastrup
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: DOC: Essay, 1.4 Building software

[Phil Holmes]

"Pierre Perol-Schneider"  wrote in message 
news:caphotuwtxrmr97w5m2ajkt4sudvqdbd93tqudk0vfuogxh0...@mail.gmail.com...

I clearly understand what you mean.
Thing is that <> does not show what's on the picture (actually
the link says: \relative c' { \new Voice { <> } } )
So I think it is not clear. Maybe this line should simply be deleted and
the next example should be:
\relative { f' <> } (or simply { << g'2 \\ { f'4 <>
} >> } face to what the 'Music representation' starts with).

Cheers,
Pierre

2016-07-22 15:40 GMT+02:00 James :


Pierre,


On 22/07/16 14:18, Pierre Perol-Schneider wrote:


Hi James,

Sorry for the misunderstanding.
Have you tried the snippet ? Have you seen the result ?



No but the online help is built using LilyPond (these are not static
images). So the result should be the same as what is shown in that link.



It should be written :

{ 4 }

and not:

<>

Examples that follow should also be corrected.



Are you sure?


http://lilypond.org/doc/v2.19/Documentation/notation/single-voice#simultaneous-expressions

James



I think very early versions of LilyPond used << notes >> for chords, not < 
notes >.  The earliest manual I can find online (1.6) has the latter 
notation, but it may be that the essay uses the early notation?


--
Phil Holmes



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

Re: DOC: Essay, 1.4 Building software

[Pierre Perol-Schneider]

I clearly understand what you mean.
Thing is that <> does not show what's on the picture (actually
the link says: \relative c' { \new Voice { <> } } )
So I think it is not clear. Maybe this line should simply be deleted and
the next example should be:
\relative { f' <> } (or simply { << g'2 \\ { f'4 <>
} >> } face to what the 'Music representation' starts with).

Cheers,
Pierre

2016-07-22 15:40 GMT+02:00 James :

> Pierre,
>
>
> On 22/07/16 14:18, Pierre Perol-Schneider wrote:
>
>> Hi James,
>>
>> Sorry for the misunderstanding.
>> Have you tried the snippet ? Have you seen the result ?
>>
>
> No but the online help is built using LilyPond (these are not static
> images). So the result should be the same as what is shown in that link.
>
>
>> It should be written :
>>
>> { 4 }
>>
>> and not:
>>
>> <>
>>
>> Examples that follow should also be corrected.
>>
>
> Are you sure?
>
>
> http://lilypond.org/doc/v2.19/Documentation/notation/single-voice#simultaneous-expressions
>
> James
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: DOC: Essay, 1.4 Building software

[James]

Pierre,


On 22/07/16 14:18, Pierre Perol-Schneider wrote:

Hi James,

Sorry for the misunderstanding.
Have you tried the snippet ? Have you seen the result ?


No but the online help is built using LilyPond (these are not static 
images). So the result should be the same as what is shown in that link.




It should be written :

{ 4 }

and not:

<>

Examples that follow should also be corrected.


Are you sure?

http://lilypond.org/doc/v2.19/Documentation/notation/single-voice#simultaneous-expressions

James

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

Re: DOC: Essay, 1.4 Building software

[Pierre Perol-Schneider]

Hi James,

Sorry for the misunderstanding.
Have you tried the snippet ? Have you seen the result ?

It should be written :

{ 4 }

and not:

<>

Examples that follow should also be corrected.

Cheers,
Pierre

2016-07-22 14:00 GMT+02:00 James :

> Pierre,
>
>
>
> On 22/07/16 12:46, Pierre Perol-Schneider wrote:
>
>> I'm not top posting.
>>>
>> Hi Bug Squad,
>>
>> See:
>>
>> http://lilypond.org/doc/v2.19/Documentation/essay/building-software.html#music-representation
>>
>> I think that this part, especially the chords ('Simultaneous notes'),
>> should be re-written, e.g.:
>>
>>
>> \version "2.19"
>>
>> <>
>>
>> Cheers,
>>
>> Pierre
>> ___
>> bug-lilypond mailing list
>> bug-lilypond@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>
>>
>> I don't understand your request.
>
> It already says
>
> <>
>
>
>
> Am I misunderstanding the request here or are you asking it to be
> re-written to something else? If so we will need some suggestions
>
> James
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Doc: harmonics for fretted strings

[David Kastrup]

Federico Bruni  writes:

> Hi folks
>
> I have a few questions about harmonics:
>
> 1. \harmonic _must_ be placed inside a chord even for single notes?
> Why? Is it still true?
> In NR 2.3.1 Harmonics>Artificial harmonics there's a warning:
>
> """
> \harmonic must be placed inside a chord construct even if there is
> only a single note. Normally \harmonicsOn would be used in this
> situation.
> """
>
> It does not explain why. I cannot see any difference:
>
> \version "2.19.43"
> {
>  d'8\harmonic 
>  d'2\harmonic 
> }

It's basically still uncleaned debris after issue 2240 (which rendered a
whole lot of warnings and issues moot).  The last stable version where
the warning applies is 2.14.

-- 
David Kastrup

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

Re: Doc: Missing NR documentation for customizing the behavior of articulations in MIDI

[Heikki Tauriainen]

On Saturday, 2016-07-09 at 12:38 +0100, James Lowe wrote:
> 
> The changes.tely commit is here
> 
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=d92
> 22eec25ca8143e7e84a5af61aaa98acec5e6a
> 
> and, I suspect that Devon Schudy (the author of the edit) was
> reflecting 
> his changes he made in this commit:
> 
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=a42
> a4f9c507f42456b3ac361788397881b86b1a0
> 
> which does contain 'midi-extra-velocity' in the diffs (I am not 
> programmer BTW), so I expect this is what the changes.tely reflects
> here.

Thanks, I knew about the origin of these changes (this was actually one
of the side issues that I had noticed during the review of your clean-
up work of the MIDI documentation last year).


> I guess Devon, his good self, would know the answer to this.

Yes, I agree that the author would probably be the most qualified
person to answer questions about the feature, however I'm not sure
whether he's currently active in LilyPond development.

Since I've not very familiar with this feature myself, I only decided
to (finally, cleaning up my list of unreported issues...) report this
issue about missing documentation to just have it in the public record.

Thanks,
-- 
Heikki Tauriainen


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

Re: Doc: Missing NR documentation for customizing the behavior of articulations in MIDI

[James Lowe]

Hiekki,

replying via email than the tracker Ralph created (in case this is just 
noise I am adding).


On 05/07/16 15:42, Heikki Tauriainen wrote:

Hi,

The post-2.18 changes to the default handling of articulations in MIDI
(without using articulate.ly) are currently mentioned only near the
bottom of the Changes document. The options available for customizing
the behavior deserve (in my opinion) a place in the NR so that the
documentation remains discoverable and does not get lost when the
Changes document is eventually replaced with a new version.

I have also the following questions about the current information in
the Changes document to which I don't know the answers myself.

* Are the names of the new properties (midiLength and
   midiExtraVelocity) which control the behavior of articulations
   correct in the Changes document?  Searching the files in the source
   tree for either of these strings produces no hits outside the
   Changes document; the definitions of the articulations in
   ly/script-init.ly (mentioned in the Changes document as a source for
   examples) use the names midi-length and midi-extra-velocity instead.
   The naming of the properties should be made consistent between the
   implementation and the documentation.


The changes.tely commit is here

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=d9222eec25ca8143e7e84a5af61aaa98acec5e6a

and, I suspect that Devon Schudy (the author of the edit) was reflecting 
his changes he made in this commit:


http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=a42a4f9c507f42456b3ac361788397881b86b1a0

which does contain 'midi-extra-velocity' in the diffs (I am not 
programmer BTW), so I expect this is what the changes.tely reflects here.




* In the Changes document it is stated that "[the] behavior is
   customizable through [...] properties of ArticulationEvent".  I'm
   wondering whether this is supposed to mean that the properties can be
   controlled from within LilyPond input using \override and \revert,
   \set, or some other syntax - if so, an example about this syntax
   would be very useful.  The only way that I've found to work to
   customize the behavior is to use the make-articulation function (as
   in ly/script-init.ly), which will change the behavior of all notes
   with a given articulation.  However, adjusting, for example, the
   "extra velocity" of just single articulated notes could be
   interesting, for example, to add variety to the MIDI output.  (This
   can of course be simulated by defining new articulations and using
   them, but I'm wondering whether this could be achieved by
   temporarily adjusting the properties of the default articulations.)


I guess Devon, his good self, would know the answer to this.


--
--

James


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

Re: Doc: Missing NR documentation for customizing the behavior of articulations in MIDI

[Palmer Ralph]

On Tue, Jul 5, 2016 at 10:42 AM, Heikki Tauriainen 
wrote:

> Hi,
>
> The post-2.18 changes to the default handling of articulations in MIDI
> (without using articulate.ly) are currently mentioned only near the
> bottom of the Changes document. The options available for customizing
> the behavior deserve (in my opinion) a place in the NR so that the
> documentation remains discoverable and does not get lost when the
> Changes document is eventually replaced with a new version.
>
> I have also the following questions about the current information in
> the Changes document to which I don't know the answers myself.
>

Greetings, Heikki Tauriainen -

Thanks for your email. The problems have been submitted as Issue #4922 :
https://sourceforge.net/p/testlilyissues/issues/4922/

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

Re: Doc: HTML table cells are misleadingly associated: should be top-aligned

[Federico Bruni]

Il giorno mer 16 mar 2016 alle 12:48, Federico Bruni 
 ha scritto:
Anyway, I can try and make a patch as soon as I have some time (very 
few spare time recently).


added here:
https://sourceforge.net/p/testlilyissues/issues/4804/

I haven't used the new git-cl with Allura yet, let's see how it works...


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

Re: Doc: HTML table cells are misleadingly associated: should be top-aligned

[Federico Bruni]

Il giorno mar 15 mar 2016 alle 4:12, Mark D. Blackwell 
 ha scritto:

 I prefer the center-align.
 I think that, as long as each definition begins with a capital (it 
should be

 "A Scheme type predicate...") and there's some padding between each
 definition, it should be readable.

 See attached example. What do you think?


I'm puzzled by your attached example. It doesn't seem to be an example
of center-alignment with padding beginning with a capital. Instead,
the word "Two" lines up vertically with the start of the second set of
"Lorem ipsum" text. This alignment is exactly what I originally meant
would be better. :)


You are probably seeing that example at full width.. Try to resize the 
browser window to half screen and you'll see that in my first example, 
as in the attached screenshot, the "Two" is not lined up vertically to 
the second set of lorem ipsum; it is centered.


Find attached a second example where there's a real top alignment, as 
defined by this CSS rule:


table td {
 vertical-align: top;
}



As to your words about your preference, I agree that adding some
padding between each definition would mostly solve the readability
problem. Yet (still) I feel it's less aesthetically pleasing than
top-alignment. And from readers, it calls for more visual "seek"
effort. BTW, on that page of the PDF version of the manual, I observe
the "cells" already are top-aligned (or the equivalent).


This is true. There's also more padding than in HTML.
I agree that it's more readable.


Lastly I
should mention that in general such padding would (at least slightly)
increase the size of an HTML manual, thus making any given browser
window hold slightly less information.


If a small padding improves the readability, this is good and I don't 
mind about the HTML manuals being slightly longer. Who cares for this?


Anyway, I can try and make a patch as soon as I have some time (very 
few spare time recently).



   One   Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
 eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
 minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip
 ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
 voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur
 sint occaecat cupidatat non proident, sunt in culpa qui officia
 deserunt mollit anim id est laborum.
   Two   Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
 eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
 minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip
 ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
 voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur
 sint occaecat cupidatat non proident, sunt in culpa qui officia
 deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet,
 consectetur adipisicing elit, sed do eiusmod tempor incididunt ut
 labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud
 exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
 Duis aute irure dolor in reprehenderit in voluptate velit esse cillum
 dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non
 proident, sunt in culpa qui officia deserunt mollit anim id est
 laborum.
   Three Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
 eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
 minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip
 ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
 voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur
 sint occaecat cupidatat non proident, sunt in culpa qui officia
 deserunt mollit anim id est laborum.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Doc: HTML table cells are misleadingly associated: should be top-aligned

[Federico Bruni]

Il giorno sab 12 mar 2016 alle 21:57, Mark D. Blackwell 
 ha scritto:

In section 2.2.1 of the Extending LilyPond manual (just for example):

http://www.lilypond.org/doc/v2.19/Documentation/extending/scheme-function-definitions

we see this table row:

typeN?  a Scheme type predicate...

However, the (Firefox) browser (for one) starts displaying the cell "a
Scheme type predicate..." at least five text lines higher than the
cell "typeN?".

The browser starts displaying "a Scheme type predicate..." much more
closely to "argN" (from the previous row). In fact, it's merely a
single line lower than "argN".

This mis-association of table cells makes reading the tables more
difficult. Plus, it seems unaesthetic.

The CSS stylesheet (for the HTML versions of all the documentation)
IMO should be changed so it top-aligns all table cells.



I prefer the center-align.
I think that, as long as each definition begins with a capital (it 
should be "A Scheme type predicate...") and there's some padding 
between each definition, it should be readable.


See attached example. What do you think?


   One Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
   eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
   minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip
   ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
   voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur
   sint occaecat cupidatat non proident, sunt in culpa qui officia
   deserunt mollit anim id est laborum.
   Two Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
   eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
   minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip
   ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
   voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur
   sint occaecat cupidatat non proident, sunt in culpa qui officia
   deserunt mollit anim id est laborum.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Doc: Extending: "sole ‘real’ argument" should be simply "argument"

[James Lowe]

On 12/03/16 19:57, Mark D. Blackwell wrote:

The Extending LilyPond manual, in section 1.3.4:

http://www.lilypond.org/doc/v2.19/Documentation/extending/adding-articulation-to-notes-_0028example_0029

currently states:

"Now we transform the add-accent function into a music function (a
matter of some syntactic sugar and a declaration of the type of its
sole ‘real’ argument).

 addAccent = #(define-music-function (note-event)
  (ly:music?)"

Now, the two words, "sole ‘real’" are mysterious and confusing, since
"note-event" is the only argument.

Formerly, those words referred to the fact that (in version 2.18) the
supplied arguments "parser" and "location" conveyed no information.
Compare version 2.18:

"Now we transform the add-accent function into a music function (a
matter of some syntactic sugar and a declaration of the type of its
sole ‘real’ argument).

 addAccent = #(define-music-function (parser location note-event)
  (ly:music?)"

So the present text should be changed to:

"Now we transform the add-accent function into a music function (a
matter of some syntactic sugar and a declaration of the type of its
argument).

 addAccent = #(define-music-function (note-event)
  (ly:music?)"



Thank you Mark.

This has been added as

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

--
James

---


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

Re: Doc: CG 2.1 LilyDev minor corrections

[James Lowe]

Greg,

On 21/12/15 18:15, Greg wrote:
> I have made some minor corrections to the Contributors' Guide – 2.1
> LilyDev. A patch file is attached.
>
> This is my first patch so please let me know if there is anything else I
> should do.
>
> Thanks,
> Greg.
>
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Thank you.

Ticket created at:
https://sourceforge.net/rest/p/testlilyissues/issues/4705/

and the patch has now been put into the test/review process.

I'll include you on the Rietveld ticket (referenced in the issue but
owned by myself) so you can see if anyone has any corrections or
questions. If there are any corrections, you can send me the corrected
patch and I'll continue to manage it for you.

-- 
James

---

B8F4 5395 CBE2 ED37 7513 B075 FF32 5682 A84B D8BE

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

Re: Doc addition

[Pierre Perol-Schneider]

 I'm not top posting.
Oops, sorry for 'not top posting'...
See original question on the french list:
http://lilypond-french-users.1298960.n2.nabble.com/diagramme-d-accords-td7583120.html

Cheers,
Pierre

2015-06-08 11:43 GMT+02:00 Pierre Perol-Schneider 
pierre.schneider.pa...@gmail.com:

 Hi Squad,

 In LM 3.1.47 FretBoard (
 http://lilypond.org/doc/v2.19/Documentation/internals/fretboard)
 I think it would be a good idea to add 'size' ; e.g. after 'stencil' or at
 last:

 size (number):
 The size, compared to the ‘normal’ size. 1 is style-sheet’s normal size,
 0.8 is smaller, +0.1 is bigger. Negative numbers are not allowed.

 Cheers,
 Pierre



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

Re: Doc addition

[Federico Bruni]

Thanks Pierre, added:
https://code.google.com/p/lilypond/issues/detail?id=4438

Internals Reference is automatically generated and properties are 
listed alphabetically. I don't know why size is missing. This might be 
the case for other objects as well.


Il giorno lun 8 giu 2015 alle 11:48, Pierre Perol-Schneider 
pierre.schneider.pa...@gmail.com ha scritto:

 I'm not top posting.

Oops, sorry for 'not top posting'...
See original question on the french list:
http://lilypond-french-users.1298960.n2.nabble.com/diagramme-d-accords-td7583120.html

Cheers,
Pierre

2015-06-08 11:43 GMT+02:00 Pierre Perol-Schneider 
pierre.schneider.pa...@gmail.com:


 Hi Squad,

 In LM 3.1.47 FretBoard (
 http://lilypond.org/doc/v2.19/Documentation/internals/fretboard)
 I think it would be a good idea to add 'size' ; e.g. after 
'stencil' or at

 last:

 size (number):
 The size, compared to the ‘normal’ size. 1 is style-sheet’s 
normal size,

 0.8 is smaller, +0.1 is bigger. Negative numbers are not allowed.

 Cheers,
 Pierre




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

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

Re: Doc: footer help message for translated manuals

[Francisco Vila]

2014-11-01 10:32 GMT+01:00 Federico Bruni fedel...@gmail.com:
 Considering the frequent reports sent in this list about errors in the
 german documentation and then forwarded to the translation list, what about
 adding a link to the translation list in the doc footer?

 Currently the footer is:
 We welcome your aid; please help us by reporting errors to our bug list.

 It can be changed to:
 We welcome your aid; please report errors in the english documentation to
 our bug list and errors in any other language to our translation list.

 The footer is defined in python/auxiliar/postprocess_html.py

I agree, please go ahead if nobody oppoes.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: Doc: footer help message for translated manuals

[Federico Bruni]

Il giorno sab 1 nov 2014 alle 11:03, Francisco Vila 
paconet@gmail.com ha scritto:

I agree, please go ahead if nobody oppoes.


I prefer leaving this to someone else, also because in the coming weeks 
I want to finalize a translation pending since may (sigh) and I don't 
want to mess up with branches

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

Re: Doc: Grobs without printed output on their own

[Simon Albrecht]

Am 27.09.2014 um 17:31 schrieb James:
Just curious why it matters, or what is gained if a grob is documented 
whether it 'prints' ouput or not, if the actual behaviour of what the 
grob does is documented (i.e. in the IR). James 
It’s just for easier understanding. In an earlier user list thread, 
someone had difficulties to understand the function of 
DynamicLineSpanner and I thought it would help to clarify this basic 
difference. Nothing more.


Yours, Simon

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

Re: Doc: Grobs without printed output on their own

[James]

On 07/09/14 15:18, Simon Albrecht wrote:
 Hello,
 
 as suggested by James, I come up with a suggestion on how to clarify the
 meaning of DynamicLineSpanner and similar.
 
 1. In
 http://lilypond.org/doc/v2.19/Documentation/learning/objects-and-interfaces,
 insert the following after the fourth paragraph:
 “What’s more, there are ‘abstract’ grobs which don’t print anything of
 their own, but rather collect, position and manage other grobs. Common
 examples for this are DynamicLineSpanner, BreakAlignment, NoteColumn,
 VerticalAxisGroup, NonMusicalPaperColumn and similar. We’ll see how some
 of these are used later.”

This has been added as

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

Thanks


 
 Other than that, I have no striking ideas on where to add information,
 especially in the NR. A table in the A.x attachment part wouldn’t be the
 right thing.
 And subdividing IR 3.1 into ‘printing grobs’ and ‘abstract grobs’ would
 require major redesign, which is probably unnecessary.
 So, just another idea of mine. I hope you don’t mind if I continue to
 post some thoughts which come to my mind. I know they are eccentrical
 and far from implementation reality sometimes and do not intend but to
 propose them to your judgement :-)


Just curious why it matters, or what is gained if a grob is documented
whether it 'prints' ouput or not, if the actual behaviour of what the
grob does is documented (i.e. in the IR).

James

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

Re: doc modification

[James]

On 26/06/14 00:33, David Nalesnik wrote:

On Wed, Jun 25, 2014 at 3:02 PM, Pierre Perol-Schneider 
pierre.schneider.pa...@gmail.com wrote:


Hi,

This thread :

http://lilypond.1069038.n5.nabble.com/Positioning-spanner-at-different-height-after-line-break-td163618.html

made me think that maybe it would be good to find another example for this
part :

http://www.lilypond.org/doc/v2.18/Documentation/extending/difficult-tweaks.html

since it's now easy to tweak with the \alterBroken command.



Perhaps with a nested property (which \alterBroken won't handle)?

It's worth noting that the example in the NR changes 'extra-offset through
'after-line-breaking.  The example can be adapted to work directly as an
override of 'extra-offset (which is what \alterBroken does essentially):

#(define (my-callback grob)

   (let* (

;; have we been split?

(orig (ly:grob-original grob))

;; if yes, get the split pieces (our siblings)

(siblings (if (ly:grob? orig)

  (ly:spanner-broken-into orig)

  '(

 (if (and (= (length siblings) 2)

  (eq? (car (last-pair siblings)) grob))

 '(-2 . 5


\relative c'' {

   \override Tie.extra-offset = #my-callback

   c1 ~ \break

   c2 ~ c

}


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

Hello,

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

I think David N and I got sidetracked about a display issue of the 
existing tweak using lilypond, lilypond-book and how the doc images are 
created.


So if David N, you can think of a better example using '.. a nested 
property' (whatever that is :) ) then I feel free to make a patch or 
update the tracker and I can make a patch.


James



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

Re: doc modification

[David Nalesnik]

Hi James,


On Thu, Jun 26, 2014 at 4:14 PM, James pkx1...@gmail.com wrote:

[...]



 What I have found is that if you use lilypond-book (which is what the
 documentation uses) I don't get the expected output but with lilypond in a
 *.ly file I do.

 If you are unfamiliar with how doc works in that sense, create a file
 called foo.tely and it has the content of

 --snip--

 \input texinfo @node Top
 @top


 @lilypond[ragged-right,quote]

 #(define (my-callback grob)

   (let* (

;; have we been split?

(orig (ly:grob-original grob))

;; if yes, get the split pieces (our siblings)

(siblings (if (ly:grob? orig)

  (ly:spanner-broken-into orig)

  '(

 (if (and (= (length siblings) 2)

  (eq? (car (last-pair siblings)) grob))

 '(-2 . 5


 \relative c'' {

   \override Tie.extra-offset = #my-callback

   c1 ~ \break

   c2 ~ c

 }
 @end lilypond


 @bye

 --snip--

 Then run

 lilypond-book --pdf foo.tely  texi2pdf foo.texi  evince foo.pdf

 I use this to check and create simple examples, snippets and the like.


I get the same result as you do when I run the above code.  However, the
moved tie also disappears when I substitute the code of the original doc
example in the template you give.

I don't know much about lilypond-book, but I assume this happens because
each line is treated individually, then linked together to form the whole.
 'extra-offset doesn't affect a system's dimensions, which is what
determines the image size.  That vertical offset moves the tie out of the
system and into oblivion.

This is pretty clear from the attached image.  I used the example in the
documentation, changing the pair to '(2 . 2.8).  The tie is cut off at the
system's extent.

I don't know enough about how the documentation examples are processed to
understand why this doesn't happen there too.

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

Re: doc modification

[James]

On 26/06/14 00:33, David Nalesnik wrote:
 On Wed, Jun 25, 2014 at 3:02 PM, Pierre Perol-Schneider 
 pierre.schneider.pa...@gmail.com wrote:

 Hi,

 This thread :

 http://lilypond.1069038.n5.nabble.com/Positioning-spanner-at-different-height-after-line-break-td163618.html

 made me think that maybe it would be good to find another example for this
 part :

 http://www.lilypond.org/doc/v2.18/Documentation/extending/difficult-tweaks.html

 since it's now easy to tweak with the \alterBroken command.


 Perhaps with a nested property (which \alterBroken won't handle)?

 It's worth noting that the example in the NR changes 'extra-offset through
 'after-line-breaking.  The example can be adapted to work directly as an
 override of 'extra-offset (which is what \alterBroken does essentially):

 #(define (my-callback grob)

   (let* (

;; have we been split?

(orig (ly:grob-original grob))

;; if yes, get the split pieces (our siblings)

(siblings (if (ly:grob? orig)

  (ly:spanner-broken-into orig)

  '(

 (if (and (= (length siblings) 2)

  (eq? (car (last-pair siblings)) grob))

 '(-2 . 5


 \relative c'' {

   \override Tie.extra-offset = #my-callback

   c1 ~ \break

   c2 ~ c

 }


 --David
 ___
 bug-lilypond mailing list
 bug-lilypond@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
However I am not seeing the tie carried over as the original example -
see attached

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

Re: [DOC] 1.3.1 Expressive marks attached to notes, has v.2.16 format

[James]

Pierre,

On 11/06/14 15:39, Pierre Perol-Schneider wrote:
 Hi Editors,

 Following pargarph (in* Creating a delayed turn*) :
 http://lilypond.org/doc/v2.18/Documentation/notation/expressive-marks-attached-to-notes.html#articulations-and-ornamentations

 uses the v2.16 script.

 Cheers,
 Pierre
 ___
 bug-lilypond mailing list
 bug-lilypond@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
Can you be a bit more specific as I don't understand what you are stating?

James

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

Re: doc modification

[James]

On 25/06/14 21:02, Pierre Perol-Schneider wrote:
 Hi,

 This thread :
 http://lilypond.1069038.n5.nabble.com/Positioning-spanner-at-different-height-after-line-break-td163618.html

 made me think that maybe it would be good to find another example for this
 part :
 http://www.lilypond.org/doc/v2.18/Documentation/extending/difficult-tweaks.html

 since it's now easy to tweak with the \alterBroken command.

 Cheers,
 Pierre
 ___
 bug-lilypond mailing list
 bug-lilypond@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
http://code.google.com/p/lilypond/issues/detail?id=3969

James

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

Re: [DOC] 1.3.1 Expressive marks attached to notes, has v.2.16 format

[Pierre Perol-Schneider]

Hi James,
Sorry, I should have written syntax instead of format

2014-06-26 9:27 GMT+02:00 James pkx1...@gmail.com:


 Can you be a bit more specific as I don't understand what you are stating?


'Creating a delayed turn'
...
\once \override AccidentalSuggestion #'outside-staff-priority = ##f
\once \override AccidentalSuggestion #'avoid-slur = #'inside
\once \override AccidentalSuggestion #'font-size = #-3
\once \override AccidentalSuggestion #'script-priority = #-1
...

should be :
...
\once \override AccidentalSuggestion.outside-staff-priority = ##f
\once \override AccidentalSuggestion.avoid-slur = #'inside
\once \override AccidentalSuggestion.font-size = #-3
\once \override AccidentalSuggestion.script-priority = #-1
...

or even :
...
\once \override AccidentalSuggestion.font-size = -3
\once \override AccidentalSuggestion.script-priority = -1
...

Cheers,

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

Re: [DOC] 1.3.1 Expressive marks attached to notes, has v.2.16 format

[James]

On 26/06/14 08:39, Pierre Perol-Schneider wrote:
 Sorry, I should have written syntax instead of format

 2014-06-26 9:27 GMT+02:00 James pkx1...@gmail.com
 mailto:pkx1...@gmail.com:
  

 Can you be a bit more specific as I don't understand what you are
 stating?

  
 'Creating a delayed turn'
 ...
 \once \override AccidentalSuggestion #'outside-staff-priority = ##f
 \once \override AccidentalSuggestion #'avoid-slur = #'inside
 \once \override AccidentalSuggestion #'font-size = #-3
 \once \override AccidentalSuggestion #'script-priority = #-1
 ...

 should be :
 ...
 \once \override AccidentalSuggestion.outside-staff-priority = ##f
 \once \override AccidentalSuggestion.avoid-slur = #'inside
 \once \override AccidentalSuggestion.font-size = #-3
 \once \override AccidentalSuggestion.script-priority = #-1
 ...

 or even :
 ...
 \once \override AccidentalSuggestion.font-size = -3
 \once \override AccidentalSuggestion.script-priority = -1
 ...

 Cheers,

 Pierre
Thanks

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

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

Re: [DOC] 1.3.1 Expressive marks attached to notes, has v.2.16 format

[Simon Albrecht]

So sorry, wrong list…

Am 26.06.2014 12:53, schrieb Simon Albrecht:


Am 26.06.2014 09:39, schrieb Pierre Perol-Schneider:


\once \override AccidentalSuggestion #'outside-staff-priority = ##f
\once \override AccidentalSuggestion #'avoid-slur = #'inside
\once \override AccidentalSuggestion #'font-size = #-3
\once \override AccidentalSuggestion #'script-priority = #-1
...

should be :
...
\once \override AccidentalSuggestion.outside-staff-priority = ##f
\once \override AccidentalSuggestion.avoid-slur = #'inside
\once \override AccidentalSuggestion.font-size = #-3
\once \override AccidentalSuggestion.script-priority = #-1
...

or even :
...
\once \override AccidentalSuggestion.font-size = -3
\once \override AccidentalSuggestion.script-priority = -1
Attention: this only works with non-negative numbers as the - is 
parsed as a post event identifier, not as a minus. So it’s still 
necessary to spell out the hash sign for negative numbers.

Else you’re certainly right.

Best, Simon

(I added this as a comment in the issue tracker, also)

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



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

Re: [DOC] 1.3.1 Expressive marks attached to notes, has v.2.16 format

[Simon Albrecht]

Am 26.06.2014 13:33, schrieb David Kastrup:

And he's right with that as well...  Have you actually tried it?

My mistake again. Sorry for being pert and not checking first. I wasn’t 
aware that your parser improvements had gone so far…


Best regards,
Simon

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

Re: doc modification

[David Nalesnik]

James,


On Thu, Jun 26, 2014 at 2:23 AM, James pkx1...@gmail.com wrote:

 On 26/06/14 00:33, David Nalesnik wrote:
  On Wed, Jun 25, 2014 at 3:02 PM, Pierre Perol-Schneider 
  pierre.schneider.pa...@gmail.com wrote:
 
  Hi,
 
  This thread :
 
 
 http://lilypond.1069038.n5.nabble.com/Positioning-spanner-at-different-height-after-line-break-td163618.html
 
  made me think that maybe it would be good to find another example for
 this
  part :
 
 
 http://www.lilypond.org/doc/v2.18/Documentation/extending/difficult-tweaks.html
 
  since it's now easy to tweak with the \alterBroken command.
 
 
  Perhaps with a nested property (which \alterBroken won't handle)?
 
  It's worth noting that the example in the NR changes 'extra-offset
 through
  'after-line-breaking.  The example can be adapted to work directly as an
  override of 'extra-offset (which is what \alterBroken does essentially):


[code]


 However I am not seeing the tie carried over as the original example -
 see attached


Not sure why.  Attached is my result, where the tie is there  (Win7,
64-bit).

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

Re: doc modification

[David Nalesnik]

On Thu, Jun 26, 2014 at 7:49 AM, David Nalesnik

 Not sure why.  Attached is my result, where the tie is there  (Win7,
 64-bit).


In any case, the altered code is equivalent to

 \alterBroken extra-offset #'((0 . 0) (-2 . 5)) Tie

so I can't understand why it wouldn't work as expected.

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

Re: [DOC] 1.3.1 Expressive marks attached to notes, has v.2.16 format

[David Kastrup]

Simon Albrecht simon.albre...@mail.de writes:

 Am 26.06.2014 13:33, schrieb David Kastrup:
 And he's right with that as well...  Have you actually tried it?

 My mistake again. Sorry for being pert and not checking first. I
 wasn’t aware that your parser improvements had gone so far…

Version 2.17.26:

commit c7320b8c6dd5ef813602526c340a3e30c2cc91f7
Author: David Kastrup d...@gnu.org
Date:   Sat Aug 31 18:57:09 2013 +0200

Issue 3527: parser.yy: allow scalar to be a negative literal number

This makes the syntax of the value for \override (a hardwired syntax
construct which accepts a scalar) and \tweak (which is a music
function accepting an expression of type scheme? possibly ending up
as a negative number) more comparable.


-- 
David Kastrup

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

Re: [Doc] Minor: link to tuplet section

[James]

On 26/06/14 14:39, Knute Snortum wrote:
 Maybe this section...

 http://www.lilypond.org/doc/v2.18/Documentation/learning/advanced-rhythmic-commands#tuplets

 ...should have a link to this section:

 http://lilypond.org/doc/v2.18/Documentation/notation/writing-rhythms#tuplets

 Knute Snortum
 (via Gmail)
 ___
 bug-lilypond mailing list
 bug-lilypond@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
http://code.google.com/p/lilypond/issues/detail?id=3971

Thanks

james

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

Re: [Doc] Minor: link to tuplet section

[James]

Knute,

On 26/06/14 14:39, Knute Snortum wrote:
 Maybe this section...

 http://www.lilypond.org/doc/v2.18/Documentation/learning/advanced-rhythmic-commands#tuplets

 ...should have a link to this section:

 http://lilypond.org/doc/v2.18/Documentation/notation/writing-rhythms#tuplets

 Knute Snortum
 (via Gmail)
 ___
 bug-lilypond mailing list
 bug-lilypond@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond

I should have checked before submitting a tracker.

The section IS linked already - see the 'See also' at the end of the
section.

The request therefore is invalid.

Sorry for the noise.

James

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

Re: doc modification

[James]

On 26/06/14 13:57, David Nalesnik wrote:



 On Thu, Jun 26, 2014 at 7:49 AM, David Nalesnik 

 Not sure why.  Attached is my result, where the tie is there
  (Win7, 64-bit).


 In any case, the altered code is equivalent to

  \alterBroken extra-offset #'((0 . 0) (-2 . 5)) Tie

 so I can't understand why it wouldn't work as expected.

 --David

Hmm..

What I have found is that if you use lilypond-book (which is what the
documentation uses) I don't get the expected output but with lilypond in
a *.ly file I do.

If you are unfamiliar with how doc works in that sense, create a file
called foo.tely and it has the content of

--snip--

\input texinfo @node Top
@top


@lilypond[ragged-right,quote]
#(define (my-callback grob)

  (let* (

   ;; have we been split?

   (orig (ly:grob-original grob))

   ;; if yes, get the split pieces (our siblings)

   (siblings (if (ly:grob? orig)

 (ly:spanner-broken-into orig)

 '(

(if (and (= (length siblings) 2)

 (eq? (car (last-pair siblings)) grob))

'(-2 . 5


\relative c'' {

  \override Tie.extra-offset = #my-callback

  c1 ~ \break

  c2 ~ c

}
@end lilypond


@bye

--snip--

Then run

lilypond-book --pdf foo.tely  texi2pdf foo.texi  evince foo.pdf

I use this to check and create simple examples, snippets and the like.

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

Re: doc modification

[David Nalesnik]

On Wed, Jun 25, 2014 at 3:02 PM, Pierre Perol-Schneider 
pierre.schneider.pa...@gmail.com wrote:

 Hi,

 This thread :

 http://lilypond.1069038.n5.nabble.com/Positioning-spanner-at-different-height-after-line-break-td163618.html

 made me think that maybe it would be good to find another example for this
 part :

 http://www.lilypond.org/doc/v2.18/Documentation/extending/difficult-tweaks.html

 since it's now easy to tweak with the \alterBroken command.


Perhaps with a nested property (which \alterBroken won't handle)?

It's worth noting that the example in the NR changes 'extra-offset through
'after-line-breaking.  The example can be adapted to work directly as an
override of 'extra-offset (which is what \alterBroken does essentially):

#(define (my-callback grob)

  (let* (

   ;; have we been split?

   (orig (ly:grob-original grob))

   ;; if yes, get the split pieces (our siblings)

   (siblings (if (ly:grob? orig)

 (ly:spanner-broken-into orig)

 '(

(if (and (= (length siblings) 2)

 (eq? (car (last-pair siblings)) grob))

'(-2 . 5


\relative c'' {

  \override Tie.extra-offset = #my-callback

  c1 ~ \break

  c2 ~ c

}


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

Re: [DOC] 1.3.1 Expressive marks attached to notes, has v.2.16 format

[Pierre Perol-Schneider]

2014-06-11 16:39 GMT+02:00 Pierre Perol-Schneider 
pierre.schneider.pa...@gmail.com:

 Hi Editors,

 Following pargarph (in* Creating a delayed turn*) :

 http://lilypond.org/doc/v2.18/Documentation/notation/expressive-marks-attached-to-notes.html#articulations-and-ornamentations

 uses the v2.16 script.

 Cheers,
 Pierre


See also :
http://lilypond.org/doc/v2.19/Documentation/notation/expressive-marks-attached-to-notes.html#articulations-and-ornamentations

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

Re: Doc Flamenco notation has ugly output

[Phil Holmes]

Pierre Perol-Schneider pierre.schneider.pa...@gmail.com wrote in message 
news:caphotuwxxm89yt3mkzeohr+d1v+v0-badwegw1dq1jksxzr...@mail.gmail.com...

Hi Editors,

Please check here;
http://lilypond.org/doc/v2.18/Documentation/snippets/fretted-strings#fretted-strings-flamenco-notation

See discussion here :
http://lilypond.1069038.n5.nabble.com/LSR-v2-18-quot-Flamenco-notation-quot-update-improvement-td159344.html

See workaround here:
http://lsr.di.unimi.it/LSR/Item?id=409

Cheers,
Pierre


It looks like you've updated the LSR, so this should automatically get 
incorporated in the next update to the docs after an LSR import.


--
Phil Holmes



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

Re: Doc modification

[Pierre Perol-Schneider]

2014-02-22 22:00 GMT+01:00 Federico Bruni fedel...@gmail.com:

 Hi Pierre


Hi Federico,


 first of all, thanks for the great work you are doing to update the LSR


My pleasure !


 2014-02-22 21:28 GMT+01:00 Pierre Perol-Schneider 
 pierre.schneider.pa...@gmail.com:

 Hi Bug Squad,


 I think that you should rather say Hi LSR editors :-)
 because the LSR must be managed in the LSR and not through the standard
 code review.
 I think that this is the right place to discuss these issues, but don't
 expect any action from the Bug Squad. The LSR is not  in our list of duties.


I copy that.



 Nitpick: I'd change the comments here


 % Corrected to avoid collisions

 r8

 f c'-58

 f c'\58

 \override StrokeFinger.add-stem-support = ##t

 f c'-\rightHandFinger #2 8

 }


 this way:

   % No tweak needed
   r8
   f c'-58
   f c'\58
% Corrected to avoid collisions
   \override StrokeFinger.add-stem-support = ##t
   f c'-\rightHandFinger #2 8


Done !

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

Re: Doc modification

[Phil Holmes]

Pierre Perol-Schneider pierre.schneider.pa...@gmail.com wrote in message 
news:caphotuwzos2zvpqc_oinentzgbrpthxipx_btwvmzwa30qn...@mail.gmail.com...

2014-02-22 22:00 GMT+01:00 Federico Bruni fedel...@gmail.com:



Nitpick: I'd change the comments here



% Corrected to avoid collisions

r8

f c'-58

f c'\58

\override StrokeFinger.add-stem-support = ##t

f c'-\rightHandFinger #2 8

}



this way:

  % No tweak needed
  r8
  f c'-58
  f c'\58
   % Corrected to avoid collisions
  \override StrokeFinger.add-stem-support = ##t
  f c'-\rightHandFinger #2 8



Think this is slightly tricky.  The snippet as it stands is relevant to 
users prior to 2.18, and there are likely to be a number.


I think the best solution would be to redo this as 2 snippets: one for 2.16 
and before, which is not included in the docs, and one for 2.18 with only 
the StrokeFinger tip, which is included in the docs.


--
Phil Holmes
Bug Squad 




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

Re: Doc modification

[Phil Holmes]

Pierre Perol-Schneider pierre.schneider.pa...@gmail.com wrote in message 
news:caphotuwyo67qa_9amxba4zsvo_npp_8ca2r2h_8li3pgs8l...@mail.gmail.com...

Hi LSR Editors,
Hi Bug Squad,

in the following snippet :
http://www.lilypond.org/doc/v2.18/Documentation/snippets/expressive-marks#expressive-marks-caesura-_0028_0022railtracks_0022_0029-with-fermata

the v2.18 output does not seem to reach the v2.14 one :
http://lsr.di.unimi.it/LSR/Item?id=170



Do you know whether it's possible to make the snippet work in both 2.14 and 
2.18?


--
Phil Holmes
Bug Squad 




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

Re: Doc modification

[Pierre Perol-Schneider]

2014-02-23 19:12 GMT+01:00 Phil Holmes m...@philholmes.net:


 Do you know whether it's possible to make the snippet work in both 2.14
 and 2.18?


Hum, I'll check.
Since the alignment rules have change between those 2 versions I've no idea
right now.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Doc modification

[Thomas Morley]

2014-02-23 19:21 GMT+01:00 Pierre Perol-Schneider
pierre.schneider.pa...@gmail.com:
 2014-02-23 19:12 GMT+01:00 Phil Holmes m...@philholmes.net:


 Do you know whether it's possible to make the snippet work in both 2.14
 and 2.18?


 Hum, I'll check.
 Since the alignment rules have change between those 2 versions I've no idea
 right now.



It's a bit tricky because of the font-metrics of scripts.caesura.curved
Note the space to the left here:

  \markup \box \musicglyph #scripts.caesura.curved

Though, the following coding gives the same output for 2.14., 2.16. and 2.18.

\relative c'' {
  c2.
  % construct the symbol
  \override BreathingSign #'text =
\markup {
  \override #'(direction . 1)
  \override #'(baseline-skip . 1.6)
  \dir-column {
\translate #'(0.155 . 0)
  \center-align \musicglyph #scripts.caesura.curved
\center-align \musicglyph #scripts.ufermata
}
  }
  \breathe c4
  % set the breathe mark back to normal
  \revert BreathingSign #'text
  c2. \breathe c4
  \bar |.
}

Cheers,
  Harm

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

Re: Doc modification

[Pierre Perol-Schneider]

2014-02-23 22:00 GMT+01:00 Thomas Morley thomasmorle...@gmail.com:


 Though, the following coding gives the same output for 2.14., 2.16. and
 2.18.


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

Re: Doc addition

[Phil Holmes]

Pierre Perol-Schneider pierre.schneider.pa...@gmail.com wrote in message 
news:caphotuuunghjzxy-h-vekv5tvjfyjqpbbdtqieyy5homzck...@mail.gmail.com...

Hi Squad

please be so kind to add :
http://lilypond.org/doc/v2.18/Documentation/snippets/staff-notation#staff-notation-time-signature-in-parentheses:

and :
http://lilypond.org/doc/v2.18/Documentation/snippets/staff-notation#staff-notation-time-signature-in-parentheses-_002d-method-3

into the Rhythms section :
http://lilypond.org/doc/v2.18/Documentation/snippets/rhythms

Cheers,
Pierre


Done for all three of the methods, although they won't actually appear in 
the documentation until there's an LSR import and a rebuild of LilyPond.


--
Phil Holmes
Bug Squad 




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

Re: Doc addition

[Pierre Perol-Schneider]

2014-02-22 15:37 GMT+01:00 Phil Holmes m...@philholmes.net:


 Done for all three of the methods, although they won't actually appear in
 the documentation until there's an LSR import and a rebuild of LilyPond.


Thank you Phil

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

Re: Doc modification

[Federico Bruni]

Hi Pierre

first of all, thanks for the great work you are doing to update the LSR

2014-02-22 21:28 GMT+01:00 Pierre Perol-Schneider 
pierre.schneider.pa...@gmail.com:

 Hi Bug Squad,


I think that you should rather say Hi LSR editors :-)
because the LSR must be managed in the LSR and not through the standard
code review.
I think that this is the right place to discuss these issues, but don't
expect any action from the Bug Squad. The LSR is not  in our list of duties.

Please be so kind to find a more relevant description for this snippet
 Avoiding collisions with chord fingerings :

 http://www.lilypond.org/doc/v2.18/Documentation/snippets/chords#chords-avoiding-collisions-with-chord-fingerings

 since v2.18 actually does string numbers and left hand fingering
 automatically avoiding beams and stems when applied to the individual notes
 of chords.


I'd change just a few words:
Fingerings and string numbers applied to individual notes will
automatically avoid beams and stems, but this is not true by default for
right hand fingerings applied to the individual notes of chords. The
following example shows how this default behavior can be overridden.


 Hereunder is the code I'll save for this snippet :

 \relative c' {

 \set fingeringOrientations = #'(up)

 \set stringNumberOrientations = #'(up)

 \set strokeFingerOrientations = #'(up)

 % Default behavior

 r8

 f c'-58

 f c'\58

 f c'-\rightHandFinger #2 8


Nitpick: I'd change the comments here


 % Corrected to avoid collisions

 r8

 f c'-58

 f c'\58

 \override StrokeFinger.add-stem-support = ##t

 f c'-\rightHandFinger #2 8

 }


this way:

  % No tweak needed
  r8
  f c'-58
  f c'\58
   % Corrected to avoid collisions
  \override StrokeFinger.add-stem-support = ##t
  f c'-\rightHandFinger #2 8
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Doc modif. v2.18

[Phil Holmes]

Pierre Perol-Schneider pierre.schneider.pa...@gmail.com wrote in message 
news:caphotuxqa53q9whujtejo_la+kf4-cr4cpdhx7tkktfoxnd...@mail.gmail.com...

Hi Squad,

In Contributor’s Guide, 5.3.4 LilyPond formatting (#Tweaks)

please change example for v2.18 syntax :

 Tweaks should, if possible, also occur on their own line.

not:  \override TextScript.padding = #3 c1^hi
but instead:  \override TextScript.padding = #3
 c1^hi

see :
http://www.lilypond.org/doc/v2.18/Documentation/contributor/lilypond-formatting

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



Will do.

--
Phil Holmes



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

Re: Doc modif. v2.18

[Phil Holmes]

Phil Holmes m...@philholmes.net wrote in message news:...
Pierre Perol-Schneider pierre.schneider.pa...@gmail.com wrote in 
message 
news:caphotuxqa53q9whujtejo_la+kf4-cr4cpdhx7tkktfoxnd...@mail.gmail.com...

Hi Squad,

In Contributor’s Guide, 5.3.4 LilyPond formatting (#Tweaks)

please change example for v2.18 syntax :

 Tweaks should, if possible, also occur on their own line.

not:  \override TextScript.padding = #3 c1^hi
but instead:  \override TextScript.padding = #3
 c1^hi

see :
http://www.lilypond.org/doc/v2.18/Documentation/contributor/lilypond-formatting

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



Will do.


Pushed to staging as 71d606dc85fa296f93289527fc6ce466f6d86ea9

--
Phil Holmes



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

Re: Doc snippet broken: Broken Crescendo Hairpin

[Phil Holmes]

Urs Liska lilyli...@googlemail.com wrote in message 
news:loom.20130826t174548-...@post.gmane.org...

The following snippet is broken:

http://lilypond.org/doc/v2.17/Documentation/snippets/expressive-
marks#expressive-marks-broken-crescendo-hairpin

I checked with 2.17.25 and 2.17.18. Both are broken, but I don't know when 
it

has been introduced.

When compiling the snippet with Frescobaldi I can see that the whiteout
rectangle is printed below the hairpin.

Urs


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

--
Phil Holmes
Bug Squad 




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

Re: Doc: warning about tracks and MIDI files

[David Kastrup]

Federico Bruni fedel...@gmail.com writes:

 I've read this message:
 http://lists.gnu.org/archive/html/lilypond-user/2013-08/msg00148.html

 and I've realized something I've missed since I started using LilyPond 4
 years ago: LilyPond creates a MIDI track for each staff in a score, which
 means that a typical score configuration for tablature (Staff + TabStaff)
 should be set to remove the Staff_performer in TabStaff:

 \new TabStaff = Guitar tabs \with {
   \remove Staff_performer
 }

 If you don't remove it, the track will be doubled, so the file size will be
 double as well as the music (which may results in unattended consequences,
 like having acoustic and nylon guitar playing at the same time)

Should we remove it by default and add it back when using
\TabFullNotation?  It's perhaps a bit heavy-handed but would cover most
use cases.

-- 
David Kastrup


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

Re: Doc: warning about tracks and MIDI files

[Federico Bruni]

2013/8/8 David Kastrup d...@gnu.org

 Federico Bruni fedel...@gmail.com writes:

  I've read this message:
  http://lists.gnu.org/archive/html/lilypond-user/2013-08/msg00148.html
 
  and I've realized something I've missed since I started using LilyPond 4
  years ago: LilyPond creates a MIDI track for each staff in a score, which
  means that a typical score configuration for tablature (Staff + TabStaff)
  should be set to remove the Staff_performer in TabStaff:
 
  \new TabStaff = Guitar tabs \with {
\remove Staff_performer
  }
 
  If you don't remove it, the track will be doubled, so the file size will
 be
  double as well as the music (which may results in unattended
 consequences,
  like having acoustic and nylon guitar playing at the same time)

 Should we remove it by default and add it back when using
 \TabFullNotation?  It's perhaps a bit heavy-handed but would cover most
 use cases.


it sounds sensible and easier for new users

just a doubt: if someone creates a TabStaff only (without \tabFullNotation)
and try to produce a MIDI, what would happen? a MIDi file with no sound?
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Doc: warning about tracks and MIDI files

[David Kastrup]

Federico Bruni fedel...@gmail.com writes:

 2013/8/8 David Kastrup d...@gnu.org

 Federico Bruni fedel...@gmail.com writes:

  I've read this message:
  http://lists.gnu.org/archive/html/lilypond-user/2013-08/msg00148.html
 
  and I've realized something I've missed since I started using
  LilyPond 4 years ago: LilyPond creates a MIDI track for each staff
  in a score, which means that a typical score configuration for
  tablature (Staff + TabStaff) should be set to remove the
  Staff_performer in TabStaff:
 
  \new TabStaff = Guitar tabs \with {
\remove Staff_performer
  }
 
  If you don't remove it, the track will be doubled, so the file size
  will be double as well as the music (which may results in
  unattended consequences, like having acoustic and nylon guitar
  playing at the same time)

 Should we remove it by default and add it back when using
 \TabFullNotation?  It's perhaps a bit heavy-handed but would cover
 most use cases.


 it sounds sensible and easier for new users

 just a doubt: if someone creates a TabStaff only (without
 \tabFullNotation) and try to produce a MIDI, what would happen? a MIDi
 file with no sound?

Exactly.  That's what makes it a bit heavy-handed.

-- 
David Kastrup

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

Re: Doc: NR-4.1.6. automatic saving of line breaking configuration

[Colin Hall]

On Mon, Sep 10, 2012 at 07:57:10PM +0200, Jean-Charles Malahieude wrote:
 Hi all,
 
 The last paragraph of the line breaking section (l. 1460 of
 spacing.itely) (which gets a @c TODO check this) puts me into
 trouble.
 I think it should be deleted (I've already @ignored it in French):

Thanks for the report, Jean-Charles.

I have created an issue tracker for your requested change here:

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

Cheers,
Colin.

-- 

Colin Hall

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

Re: Doc build: circular dependencies dropped?

[Phil Holmes]

Colin Campbell c...@shaw.ca wrote in message 
news:5039625d.8030...@shaw.ca...
I just, for the sake of housekeeping, did a source code update with 
lily-git, nuked my /build, and rebuild ab initio.  The binary build didn't 
seem odd, but the doc produced the following (many similar lines snipped 
for brevity):



make[3]: Circular web.texi - macros.itexi dependency dropped.
make[3]: Circular web.texi - translations.itexi dependency dropped.
make[3]: Circular out-www/notation.texi - notation.tely dependency 
dropped.

make[3]: Circular out-www/usage.texi - usage.tely dependency dropped.
make[3]: Circular out-www/notation.texi - macros.itexi dependency 
dropped.
make[3]: Circular out-www/notation.texi - translations.itexi dependency 
dropped.

make[3]: Circular web.texi - macros.itexi dependency dropped.
make[3]: Circular web.texi - translations.itexi dependency dropped.
/home/colin/lilypond-git/./Documentation/po/GNUmakefile:28: warning: 
overriding commands for target `po-update'
/home/colin/lilypond-git/stepmake/stepmake/podir-targets.make:14: 
warning: ignoring old commands for target `po-update'

Mirroring...
Processing HTML pages for offline target...


AFAICS, the resulting image is current and correct, so if there is a 
problem, lilypoond seems to manage anyway.


Cheers,
Colin



It's been doing that for a while but it's not something I understand.  I 
think John M or Julien would need to fix it.  Suggest you add it to the 
tracker.


--
Phil Holmes
Bug Squad 




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

Re: Doc build: circular dependencies dropped?

[Phil Holmes]

Phil Holmes m...@philholmes.net wrote in message 
news:k1crgp$em$1...@ger.gmane.org...



It's been doing that for a while but it's not something I understand.  I 
think John M or Julien would need to fix it.  Suggest you add it to the 
tracker.


--
Phil Holmes
Bug Squad


I've just checked, and for a while means as long as I've been able to 
build docs.  Before I cut most of the clutter out, the first occurrence was 
at line 161,991 of the make output, so it's _possible_ it was being missed.


:-)

--
Phil Holmes
Bug Squad 




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

Re: Doc build: circular dependencies dropped?

[Colin Campbell]

On 12-08-26 03:50 AM, Phil Holmes wrote:
Colin Campbell c...@shaw.ca wrote in message 
news:5039625d.8030...@shaw.ca...
I just, for the sake of housekeeping, did a source code update with 
lily-git, nuked my /build, and rebuild ab initio.  The binary build 
didn't seem odd, but the doc produced the following (many similar 
lines snipped for brevity):



make[3]: Circular web.texi - macros.itexi dependency dropped.
make[3]: Circular web.texi - translations.itexi dependency dropped.
make[3]: Circular out-www/notation.texi - notation.tely dependency 
dropped.

make[3]: Circular out-www/usage.texi - usage.tely dependency dropped.
make[3]: Circular out-www/notation.texi - macros.itexi dependency 
dropped.
make[3]: Circular out-www/notation.texi - translations.itexi 
dependency dropped.

make[3]: Circular web.texi - macros.itexi dependency dropped.
make[3]: Circular web.texi - translations.itexi dependency dropped.
/home/colin/lilypond-git/./Documentation/po/GNUmakefile:28: warning: 
overriding commands for target `po-update'
/home/colin/lilypond-git/stepmake/stepmake/podir-targets.make:14: 
warning: ignoring old commands for target `po-update'

Mirroring...
Processing HTML pages for offline target...


AFAICS, the resulting image is current and correct, so if there is a 
problem, lilypoond seems to manage anyway.


Cheers,
Colin



It's been doing that for a while but it's not something I understand.  
I think John M or Julien would need to fix it. Suggest you add it to 
the tracker.




Done, as http://code.google.com/p/lilypond/issues/detail?id=2778


Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )


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

Re: doc enhancement for \headers

[Graham Percival]

On Mon, Jul 09, 2012 at 01:09:50AM +0200, David Kastrup wrote:
 Graham Percival gra...@percival-music.ca writes:
 
  On Thu, Jul 05, 2012 at 11:16:52AM -0700, -Eluze wrote:
  It _is_ attacked from another starting point -- by explaining as
  much as possible with working examples.
 
 If I have twenty relevant variables, I don't want to look for 200 lines
 of prose for finding the right one to use, and not through 400 lines of
 examples.  I am more interested in 20 one-liners.  And possibly a single
 example where each field is set to its own name, so you can look at the
 output and immediately see what goes where.  Non-textual fields are
 somewhat more problematic.  Take a look at the second page in
 URL:ftp://ftp.fu-berlin.de/tex/CTAN/macros/latex/required/tools/layout.pdf.
 Yes, definitely more effort than writing twenty paragraphs of text.

... I'm not certain what you mean by this.  Are you agreeing or
disagreeing with my claim that working examples are easy to
maintain and easy to read?

IMO the second page in that link is an example of great
documentation.  You can clearly see the variables, how the effect
the page creation [1], etc.  Granted, by asking for a full working
example, I'm suggesting that we have a bit of boilerplate code
in there as well, so it wouldn't be _quite_ as clear as the latex
example.  But anybody looking up such details in Notation
shouldn't be confused by the order of \score{} and \paper{}, and
IMO the ease of maintaining a full working example in the docs
makes that trade-off well worth it.

[1] http://xkcd.com/326/

  But what's one language that we all speak?  Regardless of our
  country, any programming mind-set, etc?  well, lilypond, of
  course.
 
 You can bore and confuse in every language including LilyPond.

Sure.  But we're all fluent in ly, and there's now pretty good
understanding of the term Tiny examples, so I expect that it's
much easier to create high-quality ly explanations than
high-quality english explanations.

- Graham

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

Re: doc enhancement for \headers

[Graham Percival]

On Thu, Jul 05, 2012 at 11:16:52AM -0700, -Eluze wrote:
 
 Graham Percival-3 wrote:
  there are 13 variables that can be defined in the \header block and which
  will be used by the default header and footnote engraver:
  
  The problem with such a list is that it's easy to forget to update it… 
 
 certainly, but a documentation is only worthwhile if it shows the actual
 state - I think LilyPond does a great effort to keep documentations
 up-to-date and if there's a problem with it this should be attacked from
 another starting point.

It _is_ attacked from another starting point -- by explaining as
much as possible with working examples.

There's many reasons why people might not work on documentation.
Poor English from non-English speakers?  Hard-core math-logic
programmers intimidated by writing prose?  People fed up with
nitpicking words and grammar in doc reviews?  Those are all valid
reasons to avoid touching the docs.
(they're not _problematic_ reasons, of course -- but if somebody
doesn't want to edit docs and gives one of those reasons, I
wouldn't blame them)

But what's one language that we all speak?  Regardless of our
country, any programming mind-set, etc?  well, lilypond, of
course.  The basic .ly format is the same regardless of language
(that only changes note names, lyrics, and markup text).  Even if
we have any non-musical programmers working on lilypond, they'll
still have a small test case so they can check if their code
works or not.

It's really easy (for some people) to write whole gobs of text to
explain stuff -- and it's easy (for some people) to skim through
whole gobs of text without understanding anything.  But if there's
an .ly example that shows exactly what to do, then it's easier for
people to update that .ly if needed, and it's easier for a lazy
reader (like me) to realize that the answer to their problem
really is in the docs and they just need to slow down and
understand the example.

- Graham

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

Re: doc enhancement for \headers

[Graham Percival]

On Sun, Jul 08, 2012 at 12:04:02AM +0200, Eluze wrote:
 
 Am 07.07.2012 20:33, schrieb Mark Mathias:
 http://code.google.com/p/lilypond/issues/detail?id=2640thanks=2640ts=1341685687
 
 Hope that's what you wanted!
 thanks, Mark

Yes, thanks.

 in fact I was just waiting for possibly more comments and would have
 pushed it soon,

One nitpick: could you add a link to this discussion in the
mailing list archives?  that way somebody can read the whole
thread for more info (such as if somebody sends more info after
you've added it to the tracker).

- Graham

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

Re: doc enhancement for \headers

[Colin Hall]

On Sun, Jul 08, 2012 at 09:59:05PM +0100, Graham Percival wrote:
 
 One nitpick: could you add a link to this discussion in the
 mailing list archives?

Done.

Cheers,
Colin.

-- 

Colin Hall

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

Re: doc enhancement for \headers

[David Kastrup]

Graham Percival gra...@percival-music.ca writes:

 On Thu, Jul 05, 2012 at 11:16:52AM -0700, -Eluze wrote:
 
 Graham Percival-3 wrote:
  there are 13 variables that can be defined in the \header block and which
  will be used by the default header and footnote engraver:
  
  The problem with such a list is that it's easy to forget to update it… 
 
 certainly, but a documentation is only worthwhile if it shows the actual
 state - I think LilyPond does a great effort to keep documentations
 up-to-date and if there's a problem with it this should be attacked from
 another starting point.

 It _is_ attacked from another starting point -- by explaining as
 much as possible with working examples.

If I have twenty relevant variables, I don't want to look for 200 lines
of prose for finding the right one to use, and not through 400 lines of
examples.  I am more interested in 20 one-liners.  And possibly a single
example where each field is set to its own name, so you can look at the
output and immediately see what goes where.  Non-textual fields are
somewhat more problematic.  Take a look at the second page in
URL:ftp://ftp.fu-berlin.de/tex/CTAN/macros/latex/required/tools/layout.pdf.
Yes, definitely more effort than writing twenty paragraphs of text.

 But what's one language that we all speak?  Regardless of our
 country, any programming mind-set, etc?  well, lilypond, of
 course.

You can bore and confuse in every language including LilyPond.

 It's really easy (for some people) to write whole gobs of text to
 explain stuff -- and it's easy (for some people) to skim through whole
 gobs of text without understanding anything.  But if there's an .ly
 example that shows exactly what to do, then it's easier for people to
 update that .ly if needed, and it's easier for a lazy reader (like
 me) to realize that the answer to their problem really is in the docs
 and they just need to slow down and understand the example.

I wish we had more people with the talent or will of creating
documentation one can take in midflight, without slowing down.  That's a
lot of work, and it starts with slowing down and understanding whatever
the creators of functionality put in the docs, and more likely than not,
finding out a few things that they failed to put there.  That's one very
important non-programmer opening that we have that could use a lot more
talent.

-- 
David Kastrup


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

Re: doc enhancement for \headers

[Mark Mathias]

Eluze and Graham,

Since Eluze is a bug squad member and will be on call next Tuesday, perhaps
I should have let this go for him to handle, but I've already gone ahead
and entered this into the issues-tracker as:
http://code.google.com/p/lilypond/issues/detail?id=2640thanks=2640ts=1341685687
 .

Hope that's what you wanted!
Mark

On Thu, Jul 5, 2012 at 11:05 AM, -Eluze elu...@gmail.com wrote:


 is it asking too much to add a full list or table of all the \header
 variables supported by default!? this would save users a lot of time
 searching for an example/snippet where all of them are shown (actually this
 is the 3rd example in

 http://www.lilypond.org/doc/v2.15/Documentation/notation/creating-titles-headers-and-footers#title-blocks-explained
 3.2.1 Creating titles headers and footers . it is not mentioned that all
 variables are listed.

 \header is found 75 times in the NR.

 imo this would make the NR more a reference than a collection of loosely
 connected examples (the examples are still welcome!)

 thanks
 Eluze


 and here is how this could look like:

 +++ (right after Title blocks explained or after the Note)

 there are 13 variables that can be defined in the \header block and which
 will be used by the default header and footnote engraver:

 dedication
 title
 subtitle
 subsubtitle
 instrument*
 poet
 composer
 meter
 arranger
 piece**
 opus**

 tagline
 copyright

 *  the instrument will be repeated on every page.
 ** these are printed in a \score when the paper variable print-all-headers
 is set to ##f (default)

 +++

 this list could be enhanced with the position of each item.
 --
 View this message in context:
 http://old.nabble.com/doc-enhancement-for-%5Cheaders-tp34118295p34118295.html
 Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.com.


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

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

Re: doc enhancement for \headers

[Eluze]

Am 07.07.2012 20:33, schrieb Mark Mathias:

Eluze and Graham,

Since Eluze is a bug squad member and will be on call next Tuesday, perhaps
I should have let this go for him to handle, but I've already gone ahead
and entered this into the issues-tracker as:
http://code.google.com/p/lilypond/issues/detail?id=2640thanks=2640ts=1341685687
  .

Hope that's what you wanted!
Mark


thanks, Mark

in fact I was just waiting for possibly more comments and would have 
pushed it soon,


now it's already done - great!

Eluze


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

Re: doc enhancement for \headers

[Graham Percival]

On Thu, Jul 05, 2012 at 08:05:16AM -0700, -Eluze wrote:
 is it asking too much to add a full list or table of all the \header
 variables supported by default!?

Isn't that done in Default layout of book and score title blocks
?  A working example is much more informative than a list or
table.

 this would save users a lot of time
 searching for an example/snippet where all of them are shown (actually this
 is the 3rd example in 
 http://www.lilypond.org/doc/v2.15/Documentation/notation/creating-titles-headers-and-footers#title-blocks-explained
 3.2.1 Creating titles headers and footers . it is not mentioned that all
 variables are listed. 

ok, that's fair.  So a sentence should be added to the top of that
subsection, saying This example demonstrates all \header
variables ?  That sounds like a good idea.

 and here is how this could look like:
 
 +++ (right after Title blocks explained or after the Note)
 
 there are 13 variables that can be defined in the \header block and which
 will be used by the default header and footnote engraver:

The problem with such a list is that it's easy to forget to update
it, and wordy explanations about where items are positioned are
hard to read and write.  The example shows immediately how they're
laid out, what fonts they use, etc.

 instrument*
 piece**
 opus**
 
 *  the instrument will be repeated on every page.
 ** these are printed in a \score when the paper variable print-all-headers
 is set to ##f (default)

Good points!  It would be nice if that example were extended to
use multiple peices (to show off piece and opus), and had multiple
pages (to show instrument).

- Graham

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

Re: doc enhancement for \headers

[-Eluze]

Graham Percival-3 wrote:
 
 On Thu, Jul 05, 2012 at 08:05:16AM -0700, -Eluze wrote:
 is it asking too much to add a full list or table of all the \header
 variables supported by default!?
 
 Isn't that done in Default layout of book and score title blocks
 ?  A working example is much more informative than a list or
 table.
 
yes and no - the list/table gives you an overview and singular items can be
illustrated with examples (first a little bit of theory and then get
practical…)



 this would save users a lot of time
 searching for an example/snippet where all of them are shown (actually
 this
 is the 3rd example in 
 http://www.lilypond.org/doc/v2.15/Documentation/notation/creating-titles-headers-and-footers#title-blocks-explained
 3.2.1 Creating titles headers and footers . it is not mentioned that all
 variables are listed. 
 
 ok, that's fair.  So a sentence should be added to the top of that
 subsection, saying This example demonstrates all \header
 variables ?  That sounds like a good idea.
 

exactly



 and here is how this could look like:
 
 +++ (right after Title blocks explained or after the Note)
 
 there are 13 variables that can be defined in the \header block and which
 will be used by the default header and footnote engraver:
 
 The problem with such a list is that it's easy to forget to update it… 
 

certainly, but a documentation is only worthwhile if it shows the actual
state - I think LilyPond does a great effort to keep documentations
up-to-date and if there's a problem with it this should be attacked from
another starting point.


 instrument*
 piece**
 opus**
 
 *  the instrument will be repeated on every page.
 ** these are printed in a \score when the paper variable
 print-all-headers
 is set to ##f (default)
 
 Good points!  It would be nice if that example were extended to
 use multiple peices (to show off piece and opus), and had multiple
 pages (to show instrument).
 
 

I'll try to enlarge the third example

thanks for your feedback!

Eluze
-- 
View this message in context: 
http://old.nabble.com/doc-enhancement-for-%5Cheaders-tp34118295p34119442.html
Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.com.


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

Re: doc enhancement for \headers

[-Eluze]

-Eluze wrote:
 
 
 I'll try to enlarge the third example
 
 
here my suggestion - I changed the comments a little bit (the instrument is
on the same line as the poet and composer):

Default layout of book and score title blocks

[omit the following lines, because the two \paper variables are not
explained here]

 - The layout and formatting of title blocks are controlled by two \paper
variables;
 - bookTitleMarkup for the main \header title block and scoreTitleMarkup for
individual
 - \header blocks within a \score.

+ This example demonstrates all \header variables.

+  http://old.nabble.com/file/p34119867/headerVariables.ly
headerVariables.ly 

+ *  the instrument will be repeated on every page. 
+ ** only piece and opus are printed in a \score when the paper variable
print-all-headers is set to ##f(default)


maybe the coloring is not needed.

Eluze

nb: I feel like the default example should come first so users know about
what we are speaking…


-- 
View this message in context: 
http://old.nabble.com/doc-enhancement-for-%5Cheaders-tp34118295p34119867.html
Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.com.


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

Re: doc enhancement: on-the-fly specifications

[Marek Klein]

Hello,

2012/6/1 -Eluze elu...@gmail.com


 on-the-fly

 I've spent (to) much time on figuring out how to use on-the-fly efficently.

 in NR

 http://www.lilypond.org/doc/v2.15/Documentation/notation/custom-headers-footers-and-titles#custom-layout-for-headers-and-footers
 there are examples of the use of on-the-fly and its argument but it isn't
 explained in detail.

 specifically it's worth to mention how (and that) several conditions can be
 combined, see below.

 my search for procedures led to the list below.


 now my request:

 after The following example centers page numbers at the bottom of every
 page. First, the default
 settings for oddHeaderMarkup and evenHeaderMarkup are removed by defining
 each as a
 null markup. Then, oddFooterMarkup is redefined with the page number
 centered. Finally,
 evenFooterMarkup is given the same layout by defining it as
 \oddFooterMarkup

 and the example, please add

 -- start --

 several \on-the-fly conditions can be combined, e.g.

  \on-the-fly #first-page \on-the-fly #last-page { \markup … \fromperty
 #'header: }

 determines if the output is a single page.

 here is a list of arguments to be used with \on-the-fly:

 book-first-page
 book-last-page
 first-page
 last-page
 not-first-page
 not-part-first-page
 not-single-page
 part-first-page
 part-last-page
 print-all-headers
 print-page-number-check-first

 -- end --


I have added this as
http://code.google.com/p/lilypond/issues/detail?id=2579

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

Re: Doc-suggestion re lyrics/melismas

[Urs Liska]

Am 25.05.2012 07:43, schrieb David Kastrup:

Colin Hallcolingh...@gmail.com  writes:


On Thu, May 24, 2012 at 12:36:21PM +0200, Urs Liska wrote:

Am 23.05.2012 00:43, schrieb -Eluze:

Urs Liska-3 wrote:

Doc suggestion concerning melisma behaviour.

in

2.1.1 Common notation for vocal music

section

Multiple notes to one syllable


before or after the second example (about slurs) please add something
like:
Note that phrasing slurs don't affect the creation of melismas.


personally I don't think anybody would expect that phrasing slurs affect
melismata…

I agree.

If he had considered the consequences and there were no technical
obstacles.


Well, through the (Slurs) documentation one is somehow led to
believe slurs and phrasing slurs are practically the same and only
separated for nesting purposes.

I agree with this too.


So it would be nice if at this point of the NR it was clearly
pointed out that there _are_ differences for the handling of
melismas.

I've created a documentation tracker here:

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

And I think it's important since it stops making the choice sort of
arbitrary.

Maybe if someone knows more about the real (internal and practical) 
differences, it would be good to add some explanation also in 1.3.2, the 
original place where slurs and phrasing slurs are introduced. (Does this 
need a separate tracker item?)
I have to admit that so far chose quite arbitrarily between the two (if 
I didn't need to nest them). I was only pointed towards the issue when I 
stumbled over three different instances shortly after another:

- different layout at line breaking
- a score someone else entered where they were mixed even much uglier 
(source-wise) than in my own existing scores

- seeing the difference in melismas.

I won't right now make such a suggestion, as I'm not sure about its 
technical content, but here are a few suggestions.


The first mention of phrasing slurs is:

   Simultaneous or overlapping slurs are not permitted, but a phrasing
   slur can overlap a slur. This permits two slurs to be printed at
   once. For details, see Phrasing slurs
   
http://www.lilypond.org/doc/v2.15/Documentation/notation/expressive-marks-as-curves.html#phrasing-slurs.

Now I see that exactly this is what leads the reader to think Phrasings 
slurs are there for syntactical differentiation.


The paragraph introducing the idea of Phrasing slurs being different is:

   Typographically, a phrasing slur behaves almost exactly like a
   normal slur. However, they are treated as different objects; a
   |\slurUp| will have no effect on a phrasing slur.

Although it explicitely states that they are different objects, you can 
still think that this only applies to the syntactical function 
(especially if you already have this in mind: The explanation (with 
\slurUp) only points to this direction.


I think there are two things to add:

 * Mention the actual differences between the objects (maybe with
   visual example, e.g. re line breaking)
 * (optionally) Encourage the user to chose as deliberately as
   possible, maybe telling sth. about conceptual differences.
   (although this isn't possible to do really systematically. How
   should one always decide in a printed model score if there is a Slur
   or Phrasing slur?).

If someone posts a list of differences I can write a doc-suggestion.

Best
Urs


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