Re: Bug on LP web page

2016-12-17 Thread Federico Bruni
Il giorno dom 18 dic 2016 alle 1:58, Colin Campbell  ha 
scritto:

Hi Peter

This was fixed in January, but only the 2.19 version has the correct 
link:

http://lilypond.org/doc/v2.19/Documentation/snippets/index.html

I don't know if we have a proper and easy way to backport it to 2.18



I'm not sure what the bug might be: the "Manuals 
" page of the website, for 2.18.2, 
links directly to the LSR at the correct address. Perhaps the OP just 
needs to flush his cache for the LilyPond website?


Hi Colin

The bug is here:
http://lilypond.org/doc/v2.18/Documentation/snippets/index.html

IIRC in order to update the stable documentation we would need to make 
a new stable release (2.18.3) and such a minor fix does not worth the 
trouble.



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


Re: Half-note stem length Function help

2016-12-17 Thread Carl Williams
For those interested, 

I made some improvements to the solution for this. It now accounts for whether 
the stems are up or down, so as to match what is commonly done in modern 
tablature. 

I intend to make a tablature template incorporating this solution here also, 
http://lists.gnu.org/archive/html/bug-lilypond/2016-12/msg00022.html 
[http://lists.gnu.org/archive/html/bug-lilypond/2016-12/msg00022.html].


\version "2.18.2"

halve-half-stems =
\override Stem.before-line-breaking =
  #(lambda (grob)
    (if (= 1 (ly:grob-property grob 'duration-log))
      (if (= DOWN (ly:grob-property grob 'direction))
        (and
          (ly:grob-set-property! grob 'stem-begin-position
            (- (ly:grob-property grob 'stem-begin-position)
              (/ (ly:grob-property grob 'length) 2)
            )
          )
          (ly:grob-set-property! grob 'length
            (/ (ly:grob-property grob 'length) 2)
          )
        )
        (ly:grob-set-property! grob 'length
          (/ (ly:grob-property grob 'length) 2)
        )
      )
    )
  )


%% EXAMPLES


\new TabStaff \with {
  stringTunings = #ukulele-tuning
  \tabFullNotation
  \stemUp
  \halve-half-stems
}
  \relative c' {
  \partial 2.. a'8 a4 a2 |
  a1 |
  \stemDown
  \partial 2.. g8\4 g4\4 g2\4 |
  g1\4 |
}
\new TabStaff \with {
  stringTunings = #ukulele-tuning
  \tabFullNotation
  \revert Stem.stencil
  \revert Stem.X-extent
  \stemUp
  \halve-half-stems
}
  \relative c' {
  \partial 2.. a'8 a4 a2 |
  a1 |
  \stemDown
  \partial 2.. g8\4 g4\4 g2\4 |
  g1\4 |
}


Cheers, 
Carl

On 16/12/2016 22:14:12, Carl Williams  wrote:
Ok thanks Simon, 
I like that suggestion, I might do that. Haven't started on includes yet, but 
it's good to know. 

Thanks for spotting the reply-all. Didn't cross my mind. 
Carl

On 16/12/2016 20:00:20, Simon Albrecht  wrote:
On 16.12.2016 07:12, Carl Williams wrote:
> One more question, What is the significance of using:?
> 
> \layout {

The setting will apply to all TabVoice contexts – well, I guess that’s
not so relevant. Still, it keeps a ‘presentation’ issue separate from
the ‘content’. Actually, you can then just put the definition as well as
the \layout{} block in a separate file and turn on the functionality
simply by \including the file, without any need to change the music, or
to type the function each time you need it. But of course you can just
do whatever fits your need best :-)

It is standard to keep conversation always on-list: others may be
interested in the information or have more skills and/or time to help
out than I. So always ‘Reply All’, unless there is a compelling reason
to keep any information private.

Best, Simon


test4.2.pdf
Description: Adobe PDF document
\version "2.18.2"

halve-half-stems =
\override Stem.before-line-breaking =
  #(lambda (grob)
(if (= 1 (ly:grob-property grob 'duration-log))
  (if (= DOWN (ly:grob-property grob 'direction))
(and
  (ly:grob-set-property! grob 'stem-begin-position
(- (ly:grob-property grob 'stem-begin-position)
  (/ (ly:grob-property grob 'length) 2)
)
  )
  (ly:grob-set-property! grob 'length
(/ (ly:grob-property grob 'length) 2)
  )
)
(ly:grob-set-property! grob 'length
  (/ (ly:grob-property grob 'length) 2)
)
  )
)
  )

\new TabStaff \with {
  stringTunings = #ukulele-tuning
  \tabFullNotation
  \stemUp
  \halve-half-stems
}
  \relative c' {
  \partial 2.. a'8 a4 a2 |
  a1 |
  \stemDown
  \partial 2.. g8\4 g4\4 g2\4 |
  g1\4 |
}
\new TabStaff \with {
  stringTunings = #ukulele-tuning
  \tabFullNotation
  \revert Stem.stencil
  \revert Stem.X-extent
  \stemUp
  \halve-half-stems
}
  \relative c' {
  \partial 2.. a'8 a4 a2 |
  a1 |
  \stemDown
  \partial 2.. g8\4 g4\4 g2\4 |
  g1\4 |
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Any idea what this error message means?

2016-12-17 Thread David Wright
On Thu 15 Dec 2016 at 20:32:47 (+0100), Jean Brefort wrote:
> Le jeudi 15 décembre 2016 à 19:16 +, Peter Toye a écrit :
> > As far as I can tell, all I did was move a few files into different
> > directories. And I am now getting this message when it tries to
> > convert the PS file to PDF. The PS file is is still on the disk and
> > looks OK. Any idea what it means and how I can get my output back?
> > 
> > Layout output to `All night.ps'...
> > Converting to `./All night.pdf'...
> > warning: `(gs -q -dNOSAFER -dDEVICEWIDTHPOINTS=595.28
> > -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE
> > -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=./All night.pdf
> > -c.setpdfwrite -fAll night.ps)' failed (1)
> > fatal error: failed files: "D:/Peter/Music/Lilypond/Gurney/All
> > night/Gsharpm/All night.ly"
> > 
> > 
> > Regards,
> > 
> > Peter
> > mailto:lilyp...@ptoye.com
> > www.ptoye.com
> > 
> The white space inside the file name might be the issue. On *nix the
> command would fail because of that, white spaces need to be escape.

Debian's 2.18.2 passes this whitespace test just fine, below.
2.19 avoids part of the potential problem by using a nonce PS filename.

At first glance, it looks as if the problem might be caused by the
last line of lilypond/usr/bin/ps2pdfwr which looks like:

exec "$GS_EXECUTABLE" $OPTIONS -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite 
-sstdout=%stderr "-sOutputFile=$outfile" $OPTIONS -c .setpdfwrite -f "$infile"

What does the Windows version have here?


$ lilypond space\ in\ filename.ly
GNU LilyPond 2.18.2
Processing `space in filename.ly'
Parsing...
space in filename.ly:1: warning: no \version statement found, please add

\version "2.18.2"

for future compatibility
Interpreting music...[8][16]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `space in filename.ps'...
Converting to `./space in filename.pdf'...
Success: compilation successfully completed
$ 

Cheers,
David.

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


Re: lSR=197

2016-12-17 Thread MING TSANG
Hi Simon,David & Phil:
It seems that UTF-8_filename.ly is not working on LSR-197.I am using the 
following snippet to hard-code the file information (ie UTF-8_filename.ly) and 
put it in header-copyright. Though, it only displays on first page.  I was 
hopping LSR-197 will provide file information so that I will force it to 
display on all pages.I am looking forward to wait for Guile-V2 in lilypond. 
Hope will compile under Guile v2.Thank you all for 
helping.Immanuel,Ming%\version "2.19.52"
\language "english"
folderD = "c:/"folder = "choir_2016/"fileN = "testing-utf-8_file-name_中文"

\header {  title = "生根建造"  subtitle = "rooting construction"  subsubtitle = 
\markup{\concat{\folderD \folder \fileN}}     copyright = 
\markup{\concat{\folderD \folder \fileN}}}\score {   {c' d' e' f' g' a' b' r4}  
\layout {}}
 %
  From: MING TSANG 
 To: "lilypond-user@gnu.org" ; Simon Albrecht 
 
 Sent: Saturday, December 17, 2016 6:45 PM
 Subject: Re: lSR=197
   
David,Thank you for showing that LSR-197 compiles fine with utf-8 characters on 
Debian.  I think under window 10, this should be the same.Lilypond has no 
problem reading and display (output) utf-8 characters. On window 10 llilypond 
produces utf-8.pdf   utf-8.mid; utf-8 _header (title, subtitle, poet, composer, 
arranger etc) and utf-8 lyrics.  It is only LSR-197 not accepting utf-8 
characters on file-utf-8.ly file name.As mention in this subject LSR-197 on the 
list that  guile-v2 transition is involved.  I can wait till then.In the 
meantime, I will keep using UTS-8-filename just refrain using LSR-197 to 
generate filename.  I am working away using hard-code variables for display as 
drive#/utf-8_folder/utf-8_sub-folder/utf-8_filename.ly on pdf file footer.Thank 
you all for helping.Immanuel,Ming  


  From: David Wright 
 To: Simon Albrecht  
Cc: MING TSANG ; Lilypond-usermailinglist 

 Sent: Saturday, December 17, 2016 5:10 PM
 Subject: Re: lSR=197
  
On Sat 17 Dec 2016 at 18:38:59 (+0100), Simon Albrecht wrote:
> On 17.12.2016 17:41, MING TSANG wrote:
> >Window 10 has no problem use UTF-8  .ly file. after compile
> >through Frecobaldi .pdf and .mid files are created.
> >It seems that internal working of lilypond and its associated
> >programs not handling it. I was wondering there is a work-around?
> 
> Well, you were the one reporting that there _is_ a problem with
> UTF-8 file names on Windows. See
> .
> The deal is very simple: If somebody comes along who needs UTF-8
> file names on Windows, and has the time and skills to look for the
> problem and craft a fix for LilyPond so it can handle them, then the
> problem will be fixed.
> However, the majority of LilyPond users and a greater majority of
> LilyPond developers do not use Windows, and while it would be nice
> to be able to use UTF-8 file names, it’s no dealbreaker if you
> can’t. Additionally, the guile-v2 transition is involved, so it’s
> certainly wise to not wait for a fix and instead adopt using
> ASCII-only file names for LilyPond work.

I have no problem with UTF-8 per se, but only with the more
exotic characters, outline arrows, scissors, five-pointed
star and suchlike (on Debian). I would imagine Chinese
characters would fall in that category.

Cheers,
David.


   

   

testing-utf-8_file-name_中文.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Custom bar line

2016-12-17 Thread Andrew Bernard
Hi Samuel,

LSR 104 I believe.

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


Custom bar line

2016-12-17 Thread Br. Samuel Springuel
How would I define a bar line such that the top is in the middle of the 
top staff space and the bottom in the middle of the bottom staff space 
(i.e. what would be called a divisio minor if I was typesetting 
Gregorian chant, except on a modern 5-line staff).


Also, is there a way to make the tick bar line (i.e. `\bar "'"`) bigger 
(taller) so that it is more visible?

--
✝
Br. Samuel, OSB
St. Anselm’s Abbey
Washington, DC
(R. Padraic Springuel)

PAX ☧ ΧΡΙΣΤΟΣ

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


Re: Bug on LP web page

2016-12-17 Thread Colin Campbell

On 2016-12-17 02:53 AM, Federico Bruni wrote:

Hi Peter

This was fixed in January, but only the 2.19 version has the correct 
link:

http://lilypond.org/doc/v2.19/Documentation/snippets/index.html

I don't know if we have a proper and easy way to backport it to 2.18



I'm not sure what the bug might be: the "Manuals 
" page of the website, for 2.18.2, 
links directly to the LSR at the correct address. Perhaps the OP just 
needs to flush his cache for the LilyPond website?


Cheers,
Colin


--
A closed mouth gathers no feet.
 -Unattributed

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


Re: lSR=197

2016-12-17 Thread MING TSANG
David,Thank you for showing that LSR-197 compiles fine with utf-8 characters on 
Debian.  I think under window 10, this should be the same.Lilypond has no 
problem reading and display (output) utf-8 characters. On window 10 llilypond 
produces utf-8.pdf   utf-8.mid; utf-8 _header (title, subtitle, poet, composer, 
arranger etc) and utf-8 lyrics.  It is only LSR-197 not accepting utf-8 
characters on file-utf-8.ly file name.As mention in this subject LSR-197 on the 
list that  guile-v2 transition is involved.  I can wait till then.In the 
meantime, I will keep using UTS-8-filename just refrain using LSR-197 to 
generate filename.  I am working away using hard-code variables for display as 
drive#/utf-8_folder/utf-8_sub-folder/utf-8_filename.ly on pdf file footer.Thank 
you all for helping.Immanuel,Ming  


  From: David Wright 
 To: Simon Albrecht  
Cc: MING TSANG ; Lilypond-usermailinglist 

 Sent: Saturday, December 17, 2016 5:10 PM
 Subject: Re: lSR=197
   
On Sat 17 Dec 2016 at 18:38:59 (+0100), Simon Albrecht wrote:
> On 17.12.2016 17:41, MING TSANG wrote:
> >Window 10 has no problem use UTF-8  .ly file. after compile
> >through Frecobaldi .pdf and .mid files are created.
> >It seems that internal working of lilypond and its associated
> >programs not handling it. I was wondering there is a work-around?
> 
> Well, you were the one reporting that there _is_ a problem with
> UTF-8 file names on Windows. See
> .
> The deal is very simple: If somebody comes along who needs UTF-8
> file names on Windows, and has the time and skills to look for the
> problem and craft a fix for LilyPond so it can handle them, then the
> problem will be fixed.
> However, the majority of LilyPond users and a greater majority of
> LilyPond developers do not use Windows, and while it would be nice
> to be able to use UTF-8 file names, it’s no dealbreaker if you
> can’t. Additionally, the guile-v2 transition is involved, so it’s
> certainly wise to not wait for a fix and instead adopt using
> ASCII-only file names for LilyPond work.

I have no problem with UTF-8 per se, but only with the more
exotic characters, outline arrows, scissors, five-pointed
star and suchlike (on Debian). I would imagine Chinese
characters would fall in that category.

Cheers,
David.


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


Re: lSR=197

2016-12-17 Thread David Wright
On Sat 17 Dec 2016 at 18:38:59 (+0100), Simon Albrecht wrote:
> On 17.12.2016 17:41, MING TSANG wrote:
> >Window 10 has no problem use UTF-8  .ly file. after compile
> >through Frecobaldi .pdf and .mid files are created.
> >It seems that internal working of lilypond and its associated
> >programs not handling it. I was wondering there is a work-around?
> 
> Well, you were the one reporting that there _is_ a problem with
> UTF-8 file names on Windows. See
> .
> The deal is very simple: If somebody comes along who needs UTF-8
> file names on Windows, and has the time and skills to look for the
> problem and craft a fix for LilyPond so it can handle them, then the
> problem will be fixed.
> However, the majority of LilyPond users and a greater majority of
> LilyPond developers do not use Windows, and while it would be nice
> to be able to use UTF-8 file names, it’s no dealbreaker if you
> can’t. Additionally, the guile-v2 transition is involved, so it’s
> certainly wise to not wait for a fix and instead adopt using
> ASCII-only file names for LilyPond work.

I have no problem with UTF-8 per se, but only with the more
exotic characters, outline arrows, scissors, five-pointed
star and suchlike (on Debian). I would imagine Chinese
characters would fall in that category.

Cheers,
David.


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


Re: lSR=197

2016-12-17 Thread David Wright
On Sat 17 Dec 2016 at 16:31:33 (+), MING TSANG wrote:
> sorry I hit the wrong key before I complete the email.Here is the other email 
> message intended to send.I attached a small snippet contains UTF-8 in file 
> name if compile fine with pdf file name contains the UTF-8.However the log 
> file cannot display UTF-8 file name (see red text below).Starting 
> lilypond-windows.exe 2.19.52 [testing-utf-8_file-name_中文.ly]...Processing 
> `C:/Users/user/Google 
> Drive/CHOIR_2016/testing-utf-8_file-name_.ly'Parsing...Interpreting 
> music...Preprocessing graphical objects...Finding the ideal number of 
> pages...Fitting music on 1 page...Drawing systems...Layout output to 
> `./tmp-lilypond-WyLwQu'...Converting to 
> `testing-utf-8_file-name_.pdf'...Deleting 
> `./tmp-lilypond-WyLwQu'...Success: compilation successfully 
> completedCompleted successfully in 1.5".
> 
> filename_名字.ly  is the LSR 197  refer to previous email (which is included in 
> this emai) below:
> 
> 
> This is to followup previous "LSR - file information [0.24759]" on Nov 26, 
> 2016.Is there a work-a-round solution? 

Perhaps reread
http://lists.gnu.org/archive/html/lilypond-user/2016-11/msg00707.html
and
http://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00331.html

Whether you can hack the scheme/guile to make it read UTF8, I don't
know. In any case, it might be a waste of time in view of the
intention, I believe, to migrate to a newer version in the long term.

Cheers,
David.

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


Re: Markup and staff spacing

2016-12-17 Thread Gilberto Agostinho
Hi Simon,


Simon Albrecht-2 wrote
> try wrapping the markup in
> \markup {
>\with-dimensions-from \null {
>% insert your markup here
> }

Thanks for your reply, that's exactly what I was looking for! I really
appreciate your help.

Cheers,
Gilberto



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Markup-and-staff-spacing-tp198127p198129.html
Sent from the User mailing list archive at Nabble.com.

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


Re: Markup and staff spacing

2016-12-17 Thread Simon Albrecht

On 17.12.2016 19:17, Gilberto Agostinho wrote:

Is there a way to make LilyPond ignore collisions or spacing issues between
a markup text and other staves or grobs?


Hi Gilberto,

try wrapping the markup in
\markup {
  \with-dimensions-from \null {
  % insert your markup here
}

HTH, Simon

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


Markup and staff spacing

2016-12-17 Thread Gilberto Agostinho
Hello all,

Is there a way to make LilyPond ignore collisions or spacing issues between
a markup text and other staves or grobs? For instance, consider this example
below:

\version "2.19.37"

\new PianoStaff <<
  \new Staff {
des''4 
f'' 
e'_\markup{
  \hspace #-1.5
  \center-column {
\combine
\arrow-head #Y #UP ##t
\draw-line #'(0 . -10)
\circle "103"
  }
}
aes'
  }
  \new Staff {
\clef bass
c1
  }  
>>

Producing: 
 

As you see, LilyPond stretches the staves quite a lot in order avoid a
collision between the bottom staff and the text (marked in red). So if I
want that arrow to actually cross over the bottom staff, the only way I
managed so far is using this approach:

\version "2.19.37"

\new PianoStaff <<
  \new Staff {
des''4 
f'' 
e'
aes'
  }
  \new Staff {
\clef bass
c1*1/2
\once \override TextScript.extra-offset = #'(0 . 8)
s2_\markup{
  \hspace #-1.5
  \center-column {
\combine
\arrow-head #Y #UP ##t
\draw-line #'(0 . -10)
\circle "103"
  }
}
  }  
>>

Producing:
 

The problem with this approach is two-fold: first, it's a bit ugly as it
involves multiplying the durations and using invisible rests to get the
markup in the right position. And secondly: this may very well affect the
distance between systems or between the last system and the margin, in the
case of a bottom system.

So is there a way better way of solving this?

Cheers!
Gilberto



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Markup-and-staff-spacing-tp198127.html
Sent from the User mailing list archive at Nabble.com.

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


Re: lSR=197

2016-12-17 Thread Simon Albrecht

On 17.12.2016 17:41, MING TSANG wrote:
Window 10 has no problem use UTF-8  .ly file. after compile through 
Frecobaldi .pdf and .mid files are created.
It seems that internal working of lilypond and its associated programs 
not handling it. I was wondering there is a work-around?


Well, you were the one reporting that there _is_ a problem with UTF-8 
file names on Windows. See 
.
The deal is very simple: If somebody comes along who needs UTF-8 file 
names on Windows, and has the time and skills to look for the problem 
and craft a fix for LilyPond so it can handle them, then the problem 
will be fixed.
However, the majority of LilyPond users and a greater majority of 
LilyPond developers do not use Windows, and while it would be nice to be 
able to use UTF-8 file names, it’s no dealbreaker if you can’t. 
Additionally, the guile-v2 transition is involved, so it’s certainly 
wise to not wait for a fix and instead adopt using ASCII-only file names 
for LilyPond work.


Best, Simon

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


Re: Variable weirdness

2016-12-17 Thread David Sumbler
Further to my earllier message, I have realized that the problem I am
getting has nothing to do with variable scope (at least, I don't think
it does), so I was asking the wrong question.
But the problem still exists.
My abbreviated file now looks like this:
%
\version "2.19.48"
\language "english"
printFluteA = 
\new Staff \relative c'' {
  b1 | c \bar "|." |
}
printMvtOne =
\new StaffGroup <<
  \printFluteA
>>
printScoreMusic =
\bookpart {
  \score {
\printMvtOne
  }
}
\book {
  \bookOutputName "../ExperimentScore"
  \printScoreMusic
}
%
As I mentioned before, the final line produces an " unexpected
BOOK_IDENTIFIER" error, but not if the preceding \bookOutputName line
is commented out.
What is going on here?
David
On Sat, 2016-12-17 at 14:48 +, David Sumbler wrote:
> I have again been trying to build up a sensible files-and-variables
> structure for more complex scores (e.g. orchestral pieces with
> several movements), and I seem once again to hav##SELECTION_END##e
> run into the limitation that 'book' and 'bookpart' have no scope for
> variables.
> 
> So I thought I would try Jan-Peter's parserDefine function, but I am
> still getting a problem.  I cannot fathom whether I have used the
> function incorrectly, or whether what I am trying to do is outside of
> its functionality.
> 
> I have pared my file down virtually to a minimum to demonstrate the
> problem.  This is what I now have:
> 
> %
> \version "2.19.48"
> 
> \language "english"
> 
> parserDefine =
> #(define-scheme-function (vkey val)(symbol? scheme?)
>    (ly:parser-define! vkey val))
> 
> printFluteA = 
> \new Staff \relative c'' {
>   b1 | c \bar "|." |
> }
> 
> printMvtOne =
> \new StaffGroup <<
>   \printFluteA
> >>
> 
> \parserDefine printScoreMusic \bookpart { \score { \printMvtOne } }
> 
> %printScore =
> \book {
>   \bookOutputName "../ExperimentScore"
>   \printScoreMusic
> }
> %
> 
> When I compile this, the \printScoreMusic line produces a syntax
> error: unexpected BOOK_IDENTIFIER
>  
> The funny thing is, that if I comment out the preceding
> \bookOutputName line, there is no error and the file compiles as one
> would expect.
> 
> Can anyone shed light on this behaviour, and see a solution?
> 
> David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: lSR=197

2016-12-17 Thread MING TSANG
Simon,Thank you for your quick response.Window 10 has no problem use UTF-8  .ly 
file. after compile through Frecobaldi .pdf and .mid files are created. It 
seems that internal working of lilypond and its associated programs not 
handling it. I was wondering there is a work-around?Immanuel,Ming.
  From: Simon Albrecht 
 To: MING TSANG ; Lilypond-usermailinglist 
 
 Sent: Saturday, December 17, 2016 11:07 AM
 Subject: Re: lSR=197
   
On 17.12.2016 17:02, MING TSANG wrote:
> UTF-8 as file name

It does not come as a surprise that non-ASCII file names cause trouble 
on windows. Simply don’t do that.

Best, Simon


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


Re: lSR=197

2016-12-17 Thread Phil Holmes
As Simon says - if you know that UTF-8 characters in filenames cause problems, 
why do you use them?  Stick to ASCII.

--
Phil Holmes


  - Original Message - 
  From: MING TSANG 
  To: Lilypond-usermailinglist ; Andrew Bernard ; Thomas Morley ; David Kastrup 
; David Wright 
  Sent: Saturday, December 17, 2016 4:31 PM
  Subject: Re: lSR=197


  sorry I hit the wrong key before I complete the email.
  Here is the other email message intended to send.
  I attached a small snippet contains UTF-8 in file name if compile fine with 
pdf file name contains the UTF-8.
  However the log file cannot display UTF-8 file name (see red text below).
  Starting lilypond-windows.exe 2.19.52 [testing-utf-8_file-name_中文.ly]...
  Processing `C:/Users/user/Google 
Drive/CHOIR_2016/testing-utf-8_file-name_.ly'
  Parsing...
  Interpreting music...
  Preprocessing graphical objects...
  Finding the ideal number of pages...
  Fitting music on 1 page...
  Drawing systems...
  Layout output to `./tmp-lilypond-WyLwQu'...
  Converting to `testing-utf-8_file-name_.pdf'...
  Deleting `./tmp-lilypond-WyLwQu'...
  Success: compilation successfully completed
  Completed successfully in 1.5".




  filename_名字.ly  is the LSR 197  refer to previous email (which is included in 
this emai) below:




  This is to followup previous "LSR - file information [0.24759]" on Nov 26, 
2016.
  Is there a work-a-round solution? 




  Thank you all for you precious time spend on this LSR 197


  Immanuel,
  Ming

--
  From: MING TSANG 
  To: Lilypond-usermailinglist  
  Sent: Saturday, December 17, 2016 11:02 AM
  Subject: lSR=197







  http://lsr.di.unimi.it/LSR/Snippet?id=197  using pure English alphabet it 
complies 



  I try to compile the above LSR using English and UTF-8 as file name, I got 
the error below:
  Starting lilypond-windows.exe 2.18.2 [filename_名字.ly]...
  Processing `C:/Users/user/Google Drive/CHOIR_2016/filename_.ly'
  Parsing...
  C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:12:2: error: GUILE 
signaled an error for the expression beginning here
  #
  (define siz (object->string (stat:size (stat filen
  C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:16:2: error: GUILE 
signaled an error for the expression beginning here
  #
  (define modt (stat:mtime (stat filen)))
  C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:17:2: error: GUILE 
signaled an error for the expression beginning here
  #
  (define modts (strftime "%m/%d/%Y %H:%M:%S" (localtime modt)))
  C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:21:31: error: unknown 
escaped string: `\siz'
  \line { "File Size = " 
  \siz }
  C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:25:31: error: unknown 
escaped string: `\modts'
  \line { "Last Modified = " 
  \modts }
  C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:33:4: error: GUILE 
signaled an error for the expression beginning here
  { $
  (string-append "File Size = "
  C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:41:4: error: GUILE 
signaled an error for the expression beginning here
  { $
  (string-append "Last Modified = "
  C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:50:31: error: unknown 
escaped string: `\siz'
  \line { "File Size = " 
  \siz }
  C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:54:31: error: unknown 
escaped string: `\modts'
  \line { "Last Modified = " 
  \modts }
  Interpreting music...
  Preprocessing graphical objects...
  (lilypond-windows.exe:8624): Pango-WARNING **: Invalid UTF-8 string passed to 
pango_layout_set_text()
  warning: no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'
  warning: no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'
  warning: no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'
  warning: no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'
  (lilypond-windows.exe:8624): Pango-WARNING **: Invalid UTF-8 string passed to 
pango_layout_set_text()
  warning: no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'
  warning: no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'
  warning: no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'
  warning: no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'
  (lilypond-windows.exe:8624): Pango-WARNING **: Invalid UTF-8 string p

Re: lSR=197

2016-12-17 Thread MING TSANG
sorry I hit the wrong key before I complete the email.Here is the other email 
message intended to send.I attached a small snippet contains UTF-8 in file name 
if compile fine with pdf file name contains the UTF-8.However the log file 
cannot display UTF-8 file name (see red text below).Starting 
lilypond-windows.exe 2.19.52 [testing-utf-8_file-name_中文.ly]...Processing 
`C:/Users/user/Google 
Drive/CHOIR_2016/testing-utf-8_file-name_.ly'Parsing...Interpreting 
music...Preprocessing graphical objects...Finding the ideal number of 
pages...Fitting music on 1 page...Drawing systems...Layout output to 
`./tmp-lilypond-WyLwQu'...Converting to 
`testing-utf-8_file-name_.pdf'...Deleting 
`./tmp-lilypond-WyLwQu'...Success: compilation successfully completedCompleted 
successfully in 1.5".

filename_名字.ly  is the LSR 197  refer to previous email (which is included in 
this emai) below:


This is to followup previous "LSR - file information [0.24759]" on Nov 26, 
2016.Is there a work-a-round solution? 

Thank you all for you precious time spend on this LSR 197
Immanuel,Ming  From: MING TSANG 
 To: Lilypond-usermailinglist  
 Sent: Saturday, December 17, 2016 11:02 AM
 Subject: lSR=197
   


http://lsr.di.unimi.it/LSR/Snippet?id=197  using pure English alphabet it 
complies 

I try to compile the above LSR using English and UTF-8 as file name, I got the 
error below:Starting lilypond-windows.exe 2.18.2 [filename_名字.ly]...Processing 
`C:/Users/user/Google 
Drive/CHOIR_2016/filename_.ly'Parsing...C:/Users/user/Google 
Drive/CHOIR_2016/filename_名字.ly:12:2: error: GUILE signaled an error for the 
expression beginning here# (define siz (object->string (stat:size (stat 
filenC:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:16:2: error: 
GUILE signaled an error for the expression beginning here# (define modt 
(stat:mtime (stat filen)))C:/Users/user/Google 
Drive/CHOIR_2016/filename_名字.ly:17:2: error: GUILE signaled an error for the 
expression beginning here# (define modts (strftime "%m/%d/%Y %H:%M:%S" 
(localtime modt)))C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:21:31: 
error: unknown escaped string: `\siz'\line { "File Size = "  \siz 
}C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:25:31: error: unknown 
escaped string: `\modts'\line { "Last Modified = "  \modts 
}C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:33:4: error: GUILE 
signaled an error for the expression beginning here{ $ (string-append "File 
Size = "C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:41:4: error: GUILE 
signaled an error for the expression beginning here{ $ (string-append "Last 
Modified = "C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:50:31: error: 
unknown escaped string: `\siz'\line { "File Size = "  \siz 
}C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:54:31: error: unknown 
escaped string: `\modts'\line { "Last Modified = "  \modts }Interpreting 
music...Preprocessing graphical objects...(lilypond-windows.exe:8624): 
Pango-WARNING **: Invalid UTF-8 string passed to 
pango_layout_set_text()warning: no glyph for character U+EFFF in font 
`C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'(lilypond-windows.exe:8624):
 Pango-WARNING **: Invalid UTF-8 string passed to 
pango_layout_set_text()warning: no glyph for character U+EFFF in font 
`C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'(lilypond-windows.exe:8624):
 Pango-WARNING **: Invalid UTF-8 string passed to 
pango_layout_set_text()warning: no glyph for character U+EFFF in font 
`C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-R

Re: lSR=197

2016-12-17 Thread Simon Albrecht

On 17.12.2016 17:02, MING TSANG wrote:

UTF-8 as file name


It does not come as a surprise that non-ASCII file names cause trouble 
on windows. Simply don’t do that.


Best, Simon

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


lSR=197

2016-12-17 Thread MING TSANG


http://lsr.di.unimi.it/LSR/Snippet?id=197  using pure English alphabet it 
complies 

I try to compile the above LSR using English and UTF-8 as file name, I got the 
error below:Starting lilypond-windows.exe 2.18.2 [filename_名字.ly]...Processing 
`C:/Users/user/Google 
Drive/CHOIR_2016/filename_.ly'Parsing...C:/Users/user/Google 
Drive/CHOIR_2016/filename_名字.ly:12:2: error: GUILE signaled an error for the 
expression beginning here# (define siz (object->string (stat:size (stat 
filenC:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:16:2: error: 
GUILE signaled an error for the expression beginning here# (define modt 
(stat:mtime (stat filen)))C:/Users/user/Google 
Drive/CHOIR_2016/filename_名字.ly:17:2: error: GUILE signaled an error for the 
expression beginning here# (define modts (strftime "%m/%d/%Y %H:%M:%S" 
(localtime modt)))C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:21:31: 
error: unknown escaped string: `\siz'\line { "File Size = "  \siz 
}C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:25:31: error: unknown 
escaped string: `\modts'\line { "Last Modified = "  \modts 
}C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:33:4: error: GUILE 
signaled an error for the expression beginning here{ $ (string-append "File 
Size = "C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:41:4: error: GUILE 
signaled an error for the expression beginning here{ $ (string-append "Last 
Modified = "C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:50:31: error: 
unknown escaped string: `\siz'\line { "File Size = "  \siz 
}C:/Users/user/Google Drive/CHOIR_2016/filename_名字.ly:54:31: error: unknown 
escaped string: `\modts'\line { "Last Modified = "  \modts }Interpreting 
music...Preprocessing graphical objects...(lilypond-windows.exe:8624): 
Pango-WARNING **: Invalid UTF-8 string passed to 
pango_layout_set_text()warning: no glyph for character U+EFFF in font 
`C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'(lilypond-windows.exe:8624):
 Pango-WARNING **: Invalid UTF-8 string passed to 
pango_layout_set_text()warning: no glyph for character U+EFFF in font 
`C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'(lilypond-windows.exe:8624):
 Pango-WARNING **: Invalid UTF-8 string passed to 
pango_layout_set_text()warning: no glyph for character U+EFFF in font 
`C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'(lilypond-windows.exe:8624):
 Pango-WARNING **: Invalid UTF-8 string passed to 
pango_layout_set_text()warning: no glyph for character U+EFFF in font 
`C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'(lilypond-windows.exe:8624):
 Pango-WARNING **: Invalid UTF-8 string passed to 
pango_layout_set_text()warning: no glyph for character U+EFFF in font 
`C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.otf'warning:
 no glyph for character U+EFFF in font `C:/Program Files 
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySc

Re: Snippet variations

2016-12-17 Thread Br. Samuel Springuel

I have never worked with TeX and its relatives, so my only experience is in
plain LY files.


For those not familiar with lyluatex, the way I'm using it works as follows:

1) Inside a the TeX file there is a pointer to the lilypond source file 
of the snippet I want to include.


2) When LuaTeX processes the document, it looks at the file indicated by 
the pointer and looks to see if there existing, up-to-date images of 
that snippet.


3) If LuaTeX cannot find existing, up-to-date images, then it runs 
lilypond on the the source.


4) The up-to-date images are then included in the document in the 
location where the file pointer was specified.



If every snippet consists of a LY file of its own, it could contain a
statement like
\include "aster-def.ily"
If you change the contents of the latter, the change applies to all
snippets.

If the snippets themselves are to be used as include files to be called in a
"master" document, you can start this document with the aster definition of
your choice, followed by the \include statements of the snippets.
I use this method very often.


In a sense, both of these conditions are true.  Each snippet has its own 
LY file and they are all being included in a master document, it's just 
that the master document is a TeX document, not a LY one.


Further, I need to use both versions of the snippet in the same 
document.  As a result, I cannot just change the LY source when I want 
one or the other, I have to be able to get both out at the same time.


Adapting what you suggested, then, it seems that I might be able to do 
the following:


1) have the snippet source which doesn't contain the \aster definition
2) have two different include files, one with \aster defined to insert 
the `*`, the other with it defined to do nothing
3) have two "top-level" files which include one of the \aster definition 
files and the snippet source
4) in the master document, point to the "top-level" file which 
corresponds to the version of the snippet which I want in that location



That seems like a fairly reasonable solution, unless some one out there 
has a better one.

--
✝
Br. Samuel, OSB
St. Anselm’s Abbey
Washington, DC
(R. Padraic Springuel)

PAX ☧ ΧΡΙΣΤΟΣ

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


Re: Variable weirdness

2016-12-17 Thread David Sumbler
I have again been trying to build up a sensible files-and-variables
structure for more complex scores (e.g. orchestral pieces with several
movements), and I seem once again to have run into the limitation that
'book' and 'bookpart' have no scope for variables.
So I thought I would try Jan-Peter's parserDefine function, but I am
still getting a problem.  I cannot fathom whether I have used the
function incorrectly, or whether what I am trying to do is outside of
its functionality.
I have pared my file down virtually to a minimum to demonstrate the
problem.  This is what I now have:
%
\version "2.19.48"
\language "english"
parserDefine =
#(define-scheme-function (vkey val)(symbol? scheme?)
   (ly:parser-define! vkey val))
printFluteA = 
\new Staff \relative c'' {
  b1 | c \bar "|." |
}
printMvtOne =
\new StaffGroup <<
  \printFluteA
>>
\parserDefine printScoreMusic \bookpart { \score { \printMvtOne } }
%printScore =
\book {
  \bookOutputName "../ExperimentScore"
  \printScoreMusic
}
%
When I compile this, the \printScoreMusic line produces a syntax
error: unexpected BOOK_IDENTIFIER
 
The funny thing is, that if I comment out the preceding \bookOutputName
line, there is no error and the file compiles as one would expect.
Can anyone shed light on this behaviour, and see a solution?
David
On Tue, 2016-11-08 at 07:44 +0100, Jan-Peter Voigt wrote:
> Hello,
> 
> here is a demo of the code:
> 
> %%% snip
> \version "2.19.49"
> 
> % the 2.18 version would just use parser and layout in the signature
> and 
> the additional parser-argument in the ly:parser-define! call
> parserDefine =
> #(define-scheme-function (vkey val)(symbol? scheme?)
> (ly:parser-define! vkey val))
> 
>  Demo
> 
> \parserDefine music \relative c'' { c b bes a }
> 
> { \music }
> %%% /snip
> 
> HTH
> Jan-Peter
> 
> Am 08.11.2016 um 07:06 schrieb Jan-Peter Voigt:
> > 
> > Hello,
> > 
> > in these situations I use a little scheme-function like this:
> > 
> > parserDefine =
> > #(define-scheme-function (key val)(symbol? scheme?)
> > (ly:parser-define! key val))
> > 
> > !!!(I will correct this later, when I am on real computer )
> > 
> > This scheme-function works on every level defining a variable into
> > the 
> > current parser.
> > 
> > HTH
> > Jan-Peter
> > 
> > Am 7. November 2016 23:55:00 MEZ, schrieb Simon Albrecht 
> > :
> > 
> > On 07.11.2016 17:56, David Kastrup wrote:
> > 
> > David Sumbler  writes:
> > 
> > I had the following lines in the main file of my
> > current
> > Lilypond project: \book { \bookOutputName
> > "../firstCello"
> > partName = "Cello 1" \include "frontcover.ily"
> > \bookpart {
> > %music... The file "frontcover.ily" contains a
> > \bookpart
> > block which prints a front cover with title, composer
> > etc.
> > - these are defined elsewhere. But it needs one more
> > variable, viz. 'partName'. I discovered that Lilypond
> > will
> > not accept a variable definition in Lilypond format in
> > the
> > position I have put it: at the top level of a \book
> > block.
> > Nor will it accept it in a \bookpart block. But at a
> > higher or a lower level, it will. This seems a bit
> > weird
> > (to say the least), in view of the fact that by
> > replacing
> > the line partName = "Cello 1" with the Scheme form
> > #(define partName "Cello 1") everything works as
> > intended.
> > Is there any useful reason why a variable cannot be
> > defined in Lilypond format in these contexts? 
> > 
> > Because they would not be local to these contexts? 
> > 
> > 
> > In other words, to make this work, books and bookparts would
> > need their
> > own namespaces, am I right? What would be the drawbacks of
> > that? I
> > daresay it would be pretty intuitive to use, and I’ve also
> > found myself
> > wanting that feature in the past, mainly to simplify \include
> > structures.
> > 
> > Best, Simon
> > 
> > ---
> > -
> > 
> > lilypond-user mailing list
> > lilypond-user@gnu.org
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
> > 
> > -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9
> > Mail 
> > gesendet.
> > 
> > ___
> > lilypond-user mailing list
> > lilypond-user@gnu.org
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
> ___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Bug on LP web page

2016-12-17 Thread Peter Toye
Andrew,

Thanks for these comments. I take your point about the stable releases, but 
I've had my fingers badly burned in the past (not by Lilypond) from using 
development-stage software. It's taken a lot of correspondence with the vendor 
and wasted a lot of time. Sometimes, it's even a full release - thank you, 
Microsoft :-)>

Anyway, Kaspersky have promised to remove the false positive (see digest 169 
issue 87), after which I'll download it for the 4th time.

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Saturday, December 17, 2016, 10:42:01 AM, you wrote:


Hello Peter,

Although 2.18 is the nominal stable release, I have found from experience that 
the development releases are remarkably clean and stable. I engrave massively 
complex modernist scores with a large amount of Scheme customization and only 
once in several years have I encountered a bug that affected my work, and that 
was fixed rapidly by the team (a small matter really relating to tuplet 
stencils.] If anybody's scores are going to throw up bugs it is going to be 
mine! And they don't. I get completely clean compiles on hundreds of pages of 
scores.

I would assert that it is worth using the latest development versions, if for 
no other reason than the large number of enhancements and fixes available. 
Also, a lot of the people on the list who are willing to help out do not 
necessarily keep 2.18 around just to answer questions.

As to Kaspersky, I may well be wrong, but it has the sound of a false positive 
to me. In such cases the usual advice is to simply turn of the virus program 
during the install, and then re-enable it. Would that not work? Kaspersky has a 
well known reputation for throwing false positives - perhaps it makes customers 
feel good to know that the program is actually doing something, as otherwise it 
sits in the background apparently doing nothing. I think this is a design 
decision from Kasperksy. I can assure you that my virus checkers on Windows 10 
do not regard that release of lilypond as malware, and it has caused no harm.

Your mail implies you think you are going to be debugging lilypond. I have not 
had to do that, except once. Not too bad!

Andrew




On 17 December 2016 at 21:09, Peter Toye  wrote:
Federico,

Thank you very much. At the moment I'm still on 2.18 so I'm using those manual 
pages. I can't download 2.19 until Kaspersky have fixed their false positive 
bug. Also, it's not a stable release, and I'm fed up with debugging other 
people's software - I spent far too much of my professional life debugging my 
own :-)>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Bug on LP web page

2016-12-17 Thread Andrew Bernard
Hello Peter,

Although 2.18 is the nominal stable release, I have found from experience
that the development releases are remarkably clean and stable. I engrave
massively complex modernist scores with a large amount of Scheme
customization and only once in several years have I encountered a bug that
affected my work, and that was fixed rapidly by the team (a small matter
really relating to tuplet stencils.] If anybody's scores are going to throw
up bugs it is going to be mine! And they don't. I get completely clean
compiles on hundreds of pages of scores.

I would assert that it is worth using the latest development versions, if
for no other reason than the large number of enhancements and fixes
available. Also, a lot of the people on the list who are willing to help
out do not necessarily keep 2.18 around just to answer questions.

As to Kaspersky, I may well be wrong, but it has the sound of a false
positive to me. In such cases the usual advice is to simply turn of the
virus program during the install, and then re-enable it. Would that not
work? Kaspersky has a well known reputation for throwing false positives -
perhaps it makes customers feel good to know that the program is actually
doing something, as otherwise it sits in the background apparently doing
nothing. I think this is a design decision from Kasperksy. I can assure you
that my virus checkers on Windows 10 do not regard that release of lilypond
as malware, and it has caused no harm.

Your mail implies you think you are going to be debugging lilypond. I have
not had to do that, except once. Not too bad!

Andrew




On 17 December 2016 at 21:09, Peter Toye  wrote:

> Federico,
>
> Thank you very much. At the moment I'm still on 2.18 so I'm using those
> manual pages. I can't download 2.19 until Kaspersky have fixed their false
> positive bug. Also, it's not a stable release, and I'm fed up with
> debugging other people's software - I spent far too much of my professional
> life debugging my own :-)>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Bug on LP web page

2016-12-17 Thread Simon Albrecht

On 17.12.2016 10:45, Peter Toye wrote:
Is there any mechanism for reporting bugs on the LP web pages? Or do 
the LP team read these emails?


It’s very likely that the Bug Squad people also follow the -user list, 
though the proper proceeding is to report to bug-lilyp...@gnu.org, both 
for program and website bugs.


Best, Simon

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


Re: Bug on LP web page

2016-12-17 Thread Peter Toye
Federico,

Thank you very much. At the moment I'm still on 2.18 so I'm using those manual 
pages. I can't download 2.19 until Kaspersky have fixed their false positive 
bug. Also, it's not a stable release, and I'm fed up with debugging other 
people's software - I spent far too much of my professional life debugging my 
own :-)>

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Saturday, December 17, 2016, 9:53:59 AM, you wrote:

> Hi Peter

> This was fixed in January, but only the 2.19 version has the correct 
> link:
> http://lilypond.org/doc/v2.19/Documentation/snippets/index.html

> I don't know if we have a proper and easy way to backport it to 2.18

> Il giorno sab 17 dic 2016 alle 10:45, Peter Toye  
> ha scritto:
>> Is there any mechanism for reporting bugs on the LP web pages? Or do 
>> the LP team read these emails?

>> The link to the LSR on the "Snippets" page has a typo: 
>> http://lsr.dsi.unimi.it/ instead of http://lsr.di.unimi.it


>> Regards,

>> Peter
>> mailto:lilyp...@ptoye.com
>> www.ptoye.com___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Bug on LP web page

2016-12-17 Thread Federico Bruni

Hi Peter

This was fixed in January, but only the 2.19 version has the correct 
link:

http://lilypond.org/doc/v2.19/Documentation/snippets/index.html

I don't know if we have a proper and easy way to backport it to 2.18

Il giorno sab 17 dic 2016 alle 10:45, Peter Toye  
ha scritto:
Is there any mechanism for reporting bugs on the LP web pages? Or do 
the LP team read these emails?


The link to the LSR on the "Snippets" page has a typo: 
http://lsr.dsi.unimi.it/ instead of http://lsr.di.unimi.it



Regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com



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


Bug on LP web page

2016-12-17 Thread Peter Toye
Is there any mechanism for reporting bugs on the LP web pages? Or do the LP 
team read these emails?

The link to the LSR on the "Snippets" page has a typo: http://lsr.dsi.unimi.it/ 
instead of http://lsr.di.unimi.it

 
Regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user