Re: convert-ly and lilypond-book

[Werner LEMBERG]

>> To sum up: Keywords like `orientation' are far too frequent in
>> normal text to be handled without protection if convert-ly is
>> applied to lilypond-book (or texinfo) input.
> 
> I'm fine with this being a command-line option to convert-ly.
> Actually, this could even be the default -- as long as there's a
> (CG-documented) way to apply convert-ly to the entire document, I'm
> happy with this change.

Unfortunately, I'm not a python guru, and handling balanced text
blocks with regular expressions is notoriously difficult.  Contrary to
Perl, which has support for that since version 5.10 (a special syntax
extension of the `+' operator and the `(?n)' construct,
cf. http://www.perlmonks.org/?node_id=660316), Python lacks this,
AFAIK.

There is the highly-praised pyparsing package, however, its license
forbids inclusion into lilypond.


Werner

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

officially dropping support for OSX 10.3 "Panther"

[Graham Percival]

Apparently GUB (from about a year ago) no longer works on 10.3.9.
It's quite possible that this was broken in the change that made it
work on 10.5.

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

I have no clue how to fix the errors.  I'm quite willing to apply test
patches and upload test binaries, but without a dedicated person
working on this, it won't go anywhere.  Unless anybody has a clue,
and/or particularly cares about the operating system that was released
in 2003 and superseded by 10.4 in 2005, I propose that we officially
drop support for 10.3.

Cheers,
- Graham

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

Re: convert-ly and lilypond-book

[Graham Percival]

On Thu, Oct 21, 2010 at 6:06 AM, Werner LEMBERG  wrote:
>
> What I consider problematic is that syntax changes aren't restricted to 
> lilypond
> environments.

This is useful for updating the docs -- we *want* it to change text
like "to change the direction of the slur, use \oldSlurUpCommand".

> To sum up: Keywords like `orientation' are far too frequent in normal
> text to be handled without protection if convert-ly is applied to
> lilypond-book (or texinfo) input.

I'm fine with this being a command-line option to convert-ly.
Actually, this could even be the default -- as long as there's a
(CG-documented) way to apply convert-ly to the entire document, I'm
happy with this change.

Cheers,
- Graham

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

convert-ly and lilypond-book

[Werner LEMBERG]

In the documentation, there is an example how to convert a texinfo
file to a newer version:

  convert-ly --from=... --to=... --no-version *.itely

A similar command can be used for lilypond-book input files:

  convert-ly --from=... --to=... --no-version *.tex

What I consider problematic is that syntax changes aren't restricted to lilypond
environments.  Just consider this input:

  \version "2.11.50"

  orientation

If you say

  convert-ly --to=2.11.51 test.ly > /dev/null

You get this output:

  convert-ly (GNU LilyPond) 2.13.31
  Processing `test.ly'... 
  Applying conversion: 2.11.23, 2.11.35, 2.11.38, 2.11.46, 2.11.48, 2.11.50, 
  Not smart enough to convert orientation in fret-diagram properties. Use 
fret-diagram-details.
  2.11.51

which can be quite irritating.  Fortunately, no action is taken upon,
but this is just accidentally true.

To sum up: Keywords like `orientation' are far too frequent in normal
text to be handled without protection if convert-ly is applied to
lilypond-book (or texinfo) input.


Werner

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

Re: spurious 'begin verbatim' in snippet

[Graham Percival]

On Wed, Oct 20, 2010 at 10:30:17AM -0600, Carl Sorensen wrote:
> On 10/20/10 9:59 AM, "Francisco Vila"  wrote:
> 
> > doctitle = "Customizing fretboard fret diagrams"
> > } % begin verbatim
> > 
> > \include "predefined-guitar-fretboards.ly"
> > \storePredefinedDiagram #default-fret-table \chordmode { c' } % begin 
> > verbatim
> > 
> > it's OK to remove the second comment? I didn't know that the string
> > did trigger the verbatim mode.
>
> Yes, please do.  It's probably my mistake.

I suspect it comes from makelsr.py, though.  Is the version in
Documentation/snippets/new/ ok?  If so, then it's the weird
re.compile() regex in scripts/auxiliar/makelsr.py that's the
problem.

Cheers,
- Graham

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

Re: [Patch] Fix #903: Add shortcuts for note names languages. (issue2606042)

[Carl . D . Sorensen]

I like this idea as a way to get the functionality you want in the short
term.  But I don't like it for the long term.  I think the long-term
syntax needs to be

\language "foobar"

so that we don't have a separate keyword for each language.  As you
point out, that will require a parser change.

In the short term, why not take care of things with your french students
by having this include file be part of the LilyPond distribution, and
creating a special lilypond command, e.g. LilyPond, that expands to

lilypond -dinclude-settings="lang-init.ly" %@

so that they will have the \langFoo shortcut you want to have available?

Thanks,

Carl



http://codereview.appspot.com/2606042/diff/1/ly/declarations-init.ly
File ly/declarations-init.ly (right):

http://codereview.appspot.com/2606042/diff/1/ly/declarations-init.ly#newcode33
ly/declarations-init.ly:33: \include "lang-init.ly"
File name should be language-init.ly

http://codereview.appspot.com/2606042/diff/1/ly/declarations-init.ly#newcode34
ly/declarations-init.ly:34: \langNederlands
Command should be \languageNederlands

But I think it would be better to leave this file as it is, since I
don't think that the \languageNederlands is an appropriate long-term
solution.  So I don't want to get it hard-coded in declarations-init.ly

http://codereview.appspot.com/2606042/diff/1/ly/lang-init.ly
File ly/lang-init.ly (right):

http://codereview.appspot.com/2606042/diff/1/ly/lang-init.ly#newcode4
ly/lang-init.ly:4:   Jan Nieuwenhuizen

Copyright should be changed to 2010 Valentin Villenave.

http://codereview.appspot.com/2606042/diff/1/ly/lang-init.ly#newcode19
ly/lang-init.ly:19: \version "2.12.0"
Version should be changed.

http://codereview.appspot.com/2606042/diff/1/ly/lang-init.ly#newcode25
ly/lang-init.ly:25: % The \langFoobar shortcut maintains compatibility
with the old
change to languageFoobar

http://codereview.appspot.com/2606042/

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

Re: T1247 - Conditionally do (use-modules (ice-9 curried-definitions)) if running with Guile V2, (issue2219044)

[pnorcks]

Hi Ian,

I just tested your patch.

In addition to the small tweak that is needed (see my comment below), it
seems that the `(use-modules (ice-9 curried-definitions))' statement
does not carry over to display-lily.scm.  I am a bit puzzled by this.

This is the error message, in context:

;;; compiling
/home/pnorcks/usr/share/lilypond/2.13.37/scm/music-functions.scm
;;; compiling
/home/pnorcks/usr/share/lilypond/2.13.37/scm/display-lily.scm
;;; WARNING: compilation of
/home/pnorcks/usr/share/lilypond/2.13.37/scm/display-lily.scm failed:
;;; key syntax-error, throw args (macroexpand "~a in ~a" ("source
expression failed to match any pattern" (define
((make-music-type-predicate-aux mtypes) expr) (if (null? mtypes) #f (or
(eqv? (car mtypes) (ly:music-property expr (quote name)))
((make-music-type-predicate-aux (cdr mtypes)) expr) #f)
;;; WARNING: compilation of
/home/pnorcks/usr/share/lilypond/2.13.37/scm/music-functions.scm failed:
;;; key wrong-type-arg, throw args (#f "Wrong type to apply: ~S" (#f)
(#f))


Fortunately, it seems that the Scheme interpreter in Guile 1.9 is used
as a fallback when compilation fails, since this doesn't interpret the
make process.

Can you reproduce this with Guile 1.9.13?

Thanks,
Patrick


http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm
File scm/lily.scm (right):

http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode227
scm/lily.scm:227: (use-modules (ice-9 curried-definitions
In this section, the parenthesis nesting needs some adjustment.

It should be

  ((guile-v2)
   (if (ly:get-option 'verbose)
   (ly:message  (_ "Using (ice-9 curried-definitions) module\n")))
   (use-modules (ice-9 curried-definitions)))

http://codereview.appspot.com/2219044/

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

Re: T1247 - Conditionally do (use-modules (ice-9 curried-definitions)) if running with Guile V2, (issue2219044)

[pnorcks]

Hi Ian,

I will test your patch shortly.

Thanks,
Patrick


http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm
File scm/lily.scm (right):

http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode231
scm/lily.scm:231: (_ "Guile 1.8\n")
Okay, I can live with this.  :)

http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode271
scm/lily.scm:271: (debug-enable 'debug)
On 2010/10/20 21:42:06, ianhulin44 wrote:

This causes a deprecation warning from Guile V1.9.13 with
$ declare -x GUILE_WARN_DEPRECATED="detailed"



[/home/ian/lilypond/out/share/lilypond/current/scm/lily.scm]
`(debug-enable 'debug)' is obsolete and has no effect.
Remove it from your code.


Go ahead.  There is another instance of `(debug-enable 'debug)' earlier
in this file, so you can remove that too.

http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode332
scm/lily.scm:332: (set-module-name! iface (module-name mod))
Please change this so that it uses a tab again.

http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode338
scm/lily.scm:338: (fresh-interface!
This line too.

http://codereview.appspot.com/2219044/

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

Re: T1247 - Conditionally do (use-modules (ice-9 curried-definitions)) if running with Guile V2, (issue2219044)

[ianhulin44]

OK to remove offending line even when using Guile V1.8.7?

Ian


http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm
File scm/lily.scm (right):

http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode271
scm/lily.scm:271: (debug-enable 'debug)
This causes a deprecation warning from Guile V1.9.13 with
$ declare -x GUILE_WARN_DEPRECATED="detailed"

[/home/ian/lilypond/out/share/lilypond/current/scm/lily.scm]
`(debug-enable 'debug)' is obsolete and has no effect.
Remove it from your code.

http://codereview.appspot.com/2219044/

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

Re: T1247 - Conditionally do (use-modules (ice-9 curried-definitions)) if running with Guile V2, (issue2219044)

[ianhulin44]

New patchset uploaded

Ian


http://codereview.appspot.com/2219044/diff/10001/scm/lily.scm
File scm/lily.scm (right):

http://codereview.appspot.com/2219044/diff/10001/scm/lily.scm#newcode231
scm/lily.scm:231: (_ "module (ice-9 curried-definitions) not in Guile
1.8\n")
Change --verbose ly:message to say just "Guile V1.8"

http://codereview.appspot.com/2219044/diff/10001/scm/lily.scm#newcode293
scm/lily.scm:293: (primitive-load file-name)
(primitive-load-path file-name)
;; for Guile V2.0 autocompile

http://codereview.appspot.com/2219044/

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

Re: NR 2.1 suggestions

[Valentin Villenave]

On Wed, Oct 20, 2010 at 7:20 PM, Trevor Daniels  wrote:
> Many thanks for your comments.  At first glance they all seem pertinent.
>  I'll have a look at fixing them up tomorrow.

Hi Trevor,

I've taken the liberty to apply James' suggestions myself:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=e123b8602af19e4bb2ac42800c76a3738099d443

Nice work James!

Cheers,
Valentin

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

[Patch] Fix #903: Add shortcuts for note names languages. (issue2606042)

[v . villenave]

Reviewers: ,

Message:
Greetings everybody,

this user-friendly modification has been discussed for a while but
nothing concrete had been done so far.  Therefore I took the liberty of
proposing a very simple patch, since this modification is something I
really really need (well, not me, but rather the French music schools,
students etc. whom I introduce to LilyPond every other day).

Please review this patch on http://codereview.appspot.com/2606042 and
the issue on http://code.google.com/p/lilypond/issues/detail?id=903 --
the discussion has somehow gone South on this page, but I hope that my
patch is basic enough to make things simpler and more straigthforward
:-)

Cheers,
Valentin

Description:
Fix #903: Add shortcuts for note names languages.

This commit adds a new file, lang-init.ly, that
introduces new shortcut commands for notenames
language selection: instead of using \include "italiano.ly",
just use \langItaliano, and so on.

Standalone shortcuts have been defined for all available
languages.  A different syntax has been considered, such as

  \lang "italiano"

However, since the only way to pass arguments is currently
through a music-functions, and since you can't have toplevel
LilyPond definitions inside a music function, this would
require to modify either the parser (a rather heavy change)
either the italiano.ly&co files, which would break compatibility
with existing code.  The way I chose was the lightest, safest
and the most straightforward.

Full compatibility with the old syntax is preserved.  Once people
get used to the new syntax, we may consider a slightly different
implementation (or not).

Please review this at http://codereview.appspot.com/2606042/

Affected files:
  M ly/declarations-init.ly
  A ly/lang-init.ly


Index: ly/declarations-init.ly
diff --git a/ly/declarations-init.ly b/ly/declarations-init.ly
index  
54aa7121e2ec6c1fe037da8ac4068b2a291ae86d..8e27d7a582abd8355449d55f67498a02ef137166  
100644

--- a/ly/declarations-init.ly
+++ b/ly/declarations-init.ly
@@ -30,7 +30,8 @@ maxima = #(ly:make-duration -3 0)
 \include "toc-init.ly"

 %% default note names are dutch
-\include "nederlands.ly"
+\include "lang-init.ly"
+\langNederlands

 \include "drumpitch-init.ly"
 \include "chord-modifiers-init.ly"
Index: ly/lang-init.ly
diff --git a/ly/lang-init.ly b/ly/lang-init.ly
new file mode 100644
index  
..ffbd68d4894e280673f9c3a1607d23aa312f3ecb

--- /dev/null
+++ b/ly/lang-init.ly
@@ -0,0 +1,69 @@
+ This file is part of LilyPond, the GNU music typesetter.
+
+ Copyright (C) 1996--2010 Han-Wen Nienhuys 
+  Jan Nieuwenhuizen 
+
+ LilyPond is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+
+ LilyPond is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with LilyPond.  If not, see .
+
+\version "2.12.0"
+
+%
+% Add shortcuts for all available note name languages.
+%
+
+% The \langFoobar shortcut maintains compatibility with the old
+% \include "foobar.ly" syntax.  Long-term TODO plan: once the new
+% syntax is widely used, deprecate the old syntax, remove all
+% foobar.ly language files from the ly/ directory and regroup
+% all \pitchnamesFoobar alist definitions in this file.
+
+
+%% Default language.
+langNederlands =
+#(ly:parser-include-string parser "\\include \"nederlands.ly\"")
+
+%% This one adds more definitions than a typical language file.
+langArabic =
+#(ly:parser-include-string parser "\\include \"arabic.ly\"")
+
+
+langCatalan =
+#(ly:parser-include-string parser "\\include \"catalan.ly\"")
+
+langDeutsch =
+#(ly:parser-include-string parser "\\include \"deutsch.ly\"")
+
+langEnglish =
+#(ly:parser-include-string parser "\\include \"english.ly\"")
+
+langEspanol =
+#(ly:parser-include-string parser "\\include \"espanol.ly\"")
+
+langItaliano =
+#(ly:parser-include-string parser "\\include \"italiano.ly\"")
+
+langNorsk =
+#(ly:parser-include-string parser "\\include \"norsk.ly\"")
+
+langPortugues =
+#(ly:parser-include-string parser "\\include \"portugues.ly\"")
+
+langSuomi =
+#(ly:parser-include-string parser "\\include \"suomi.ly\"")
+
+langSvenska =
+#(ly:parser-include-string parser "\\include \"svenska.ly\"")
+
+langVlaams =
+#(ly:parser-include-string parser "\\include \"vlaams.ly\"")



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

Re: NR 2.1 suggestions

[Trevor Daniels]

James

Many thanks for your comments.  At first glance they all seem 
pertinent.  I'll have a look at fixing them up tomorrow.


I'm actually dealing with TODOs dotted around the file in no 
particular order, so there is no high-water mark for the changes 
I've made.  You could read and comment down to 2.1.7.


Trevor

- Original Message - 
From: "James Bailey" 
To: ; "Trevor Daniels" 


Sent: Wednesday, October 20, 2010 5:55 PM
Subject: NR 2.1 suggestions


These are just some things that I noticed.

2.1.1 Entering Lyrics.

Lyrics are entered in a special input mode, which can be introduced 
by the keyword \lyricmode, or by using \addlyrics or \lyricsto. In 
this mode…
Which mode? This has bugged me for a while, and since changes are 
being made, can I request one here? As far as I understand, it's a 
statement referring to the generic mode used for entering lyrics, 
but because a keyword and two other things which haven't yet been 
defined have been mentioned in the same sentence as this mode for 
entering lyrics, it would be very helpful for a clearer sentence, 
i.e.,
Lyrics are entered in a special input mode, which can be introduced 
by the keyword \lyricmode, or by using \addlyrics or \lyricsto. In 
this special input mode…


Punctuation, lyrics with accented characters, characters from 
non-English languages, or special characters (such as the heart 
symbol or slanted quotes), may simply be inserted directly into the 
input file, providing it is saved with UTF-8 encoding.


Can I request/suggest an example that more clearly shows this? 
Maybe »Schad‘ um das so schö -- ne grü -- ne Band« (Slightly adapted 
from Die Schöne Müllerin to fit the notes already in the example.)


The first stanza is not aligned with the notes because the durations 
were not specified, and the default value of 2 is used for each 
word.
Doesn't this use the value of 2 because that was the last explicit 
value used? If the preceeding note has a value of 4, then it uses 
the value 4.

\version "2.13.36"
<<
 \new Voice = "one" \relative c'' {
   \time 2/4
   c4 b8. a16 g4. f8 e4 d r4 c
 }

% uses previous explicit duration 4;
 \new Lyrics \lyricmode {
   Joy to the earth!
 }

% explicit durations, set to a different rhythm
 \new Lyrics \lyricmode {
   Life4 is love,2. live4 life.2
 }




Why is "Keeping Contexts Alive" a "see also" for "Manual syllable 
durations"? Nothing regarding why this is necessary is mentioned 
there. If anything, it should be in the section on "Automatic 
syllable durations"


Thanks for reading, and I really like a lot of the changes. For 
context, up to which section is the rewrite finished? 




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

NR 2.1 suggestions

[James Bailey]

These are just some things that I noticed.

2.1.1 Entering Lyrics. 

Lyrics are entered in a special input mode, which can be introduced by 
the keyword \lyricmode, or by using \addlyrics or \lyricsto. In this mode… 
Which mode? This has bugged me for a while, and since changes are being made, 
can I request one here? As far as I understand, it's a statement referring to 
the generic mode used for entering lyrics, but because a keyword and two other 
things which haven't yet been defined have been mentioned in the same sentence 
as this mode for entering lyrics, it would be very helpful for a clearer 
sentence, i.e., 
Lyrics are entered in a special input mode, which can be introduced by the 
keyword \lyricmode, or by using \addlyrics or \lyricsto. In this special input 
mode…

Punctuation, lyrics with accented characters, characters from 
non-English languages, or special characters (such as the heart symbol or 
slanted quotes), may simply be inserted directly into the input file, providing 
it is saved with UTF-8 encoding. 

Can I request/suggest an example that more clearly shows this? Maybe »Schad‘ um 
das so schö -- ne grü -- ne Band« (Slightly adapted from Die Schöne Müllerin to 
fit the notes already in the example.)

The first stanza is not aligned with the notes because the durations 
were not specified, and the default value of 2 is used for each word. 
Doesn't this use the value of 2 because that was the last explicit value used? 
If the preceeding note has a value of 4, then it uses the value 4.
\version "2.13.36"
<<
  \new Voice = "one" \relative c'' {
\time 2/4
c4 b8. a16 g4. f8 e4 d r4 c 
  }

% uses previous explicit duration 4;
  \new Lyrics \lyricmode {
Joy to the earth!
  }

% explicit durations, set to a different rhythm
  \new Lyrics \lyricmode {
Life4 is love,2. live4 life.2
  }
>>

Why is "Keeping Contexts Alive" a "see also" for "Manual syllable durations"? 
Nothing regarding why this is necessary is mentioned there. If anything, it 
should be in the section on "Automatic syllable durations"

Thanks for reading, and I really like a lot of the changes. For context, up to 
which section is the rewrite finished?___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Clefs for cue notes: How to extract a grob property in an engraver?

[Reinhold Kainhofer]

Hi all,
I'm currently working on automatic cue clefs (i.e. \cueDuring in different 
clefs than the containing voice, e.g. using a violin or flute cue inside the 
cello part).
My current state is up at rietveld at:
http://codereview.appspot.com/2588042

As the cue clefs should not override the staff's clef (in particular, at the 
beginning of a piece and after a line break the staff's normal clef should be 
shown and the smaller cue clef should be shown just right before the cue 
notes), I'm adding a new grob CueClef. After the cue notes, a second clef to 
reset to the instrument's clef also needs to be added.
I have added a Cue_clef_engraver to take care of this.

An example output of the current state is at:
   http://www.fam.tuwien.ac.at/~reinhold/LilyPond/cue-clef.pdf

I'm currently struggling with two/three issues:
1) At the end of the cue notes I need to reset the clef to the clef of 
   the containing voice. Unfortunately, the clef glyph of the containing 
   voice is not stored in a context property, but as the glyph property 
   of the Clef grob. How can I retrieve that grob property from within an 
   engraver?
2) I tried to add appropriate space-alist entries to scm/define-grobs.scm and
   also add the cue-clef and cue-end-clef to the break-align-orders.
   Unfortunately, the cue clefs are not positioned correctly:
-) a cue clef at the start of a measure touches the barline (no space!)
-) an ending cue clef is printed AFTER the barline
-) an ending cue clef at a line break is repeated in the new line
3) I'm getting a programming error:
 programming error: No spacing entry from Item to `cue-clef'
   I tried to find out which spacing entry is missing, but AFAICS, I have
   added all neccessary spacings to the appropriate spacing-alist entries...

I hope someone can help me with these issues.
  
Thanks,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

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

Re: spurious 'begin verbatim' in snippet

[Carl Sorensen]

Yes, please do.  It's probably my mistake.

Thanks,

Carl


On 10/20/10 9:59 AM, "Francisco Vila"  wrote:

> Hello.
> 
> see
> Customizing fretboard fret diagrams
> Documentation/snippets/customizing-fretboard-fret-diagrams.ly
> lines 74 -- 81:
> 
> doctitle = "Customizing fretboard fret diagrams"
> } % begin verbatim
> 
> \include "predefined-guitar-fretboards.ly"
> \storePredefinedDiagram #default-fret-table \chordmode { c' } % begin verbatim
> 
> #guitar-tuning
> #"x;1-1-(;3-2;3-3;3-4;1-1-);"
> 
> 
> The second '% begin verbatim' makes the snippet to appear truncated in
> NR 2.1.4 (v2.13) at
> 
> http://lilypond.org/doc/v2.13/Documentation/notation/common-notation-for-frett
> ed-strings.html#Selected-Snippets-37
> 
> it's OK to remove the second comment? I didn't know that the string
> did trigger the verbatim mode.
> --
> Francisco Vila. Badajoz (Spain)
> www.paconet.org , www.csmbadajoz.com
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel


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

spurious 'begin verbatim' in snippet

[Francisco Vila]

Hello.

see
Customizing fretboard fret diagrams
Documentation/snippets/customizing-fretboard-fret-diagrams.ly
lines 74 -- 81:

doctitle = "Customizing fretboard fret diagrams"
} % begin verbatim

\include "predefined-guitar-fretboards.ly"
\storePredefinedDiagram #default-fret-table \chordmode { c' } % begin verbatim

#guitar-tuning
#"x;1-1-(;3-2;3-3;3-4;1-1-);"


The second '% begin verbatim' makes the snippet to appear truncated in
NR 2.1.4 (v2.13) at

http://lilypond.org/doc/v2.13/Documentation/notation/common-notation-for-fretted-strings.html#Selected-Snippets-37

it's OK to remove the second comment? I didn't know that the string
did trigger the verbatim mode.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: convert: properly escape some single-backslashes. (issue2401042)

[Carl . D . Sorensen]

LGTM.

Carl


http://codereview.appspot.com/2401042/

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

Re: LyricText #'font-series = #'bold-narrow ?!

[Werner LEMBERG]

> why does LyricText #'font-series default to #'bold-narrow?

This looks like an oversight.  The change is from 2004 where TeX has
been still used as the output device.


Werner

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

Re: LyricText #'font-series = #'bold-narrow ?!

[Valentin Villenave]

Hi Alexander,

CC-ing to the bug list just in case.

On Wed, Oct 20, 2010 at 2:39 PM, Alexander Kobel  wrote:
> why does LyricText #'font-series default to #'bold-narrow?
>
> First, it's counterintuitive to me to have a bold narrow font as the most
> important thing to read in a piece; it's just too black-ish. Condensed seems
> fine for lyrics, but bold?
> Second, it's defined for nearly no font, in particular Century Schoolbook L
> (the default of LilyPond) does not have it, IIUC, so regular is used
> instead.  At least, this holds for the free typeface; according to
> Wikipedia, there are Century designs featuring a narrow variant, but AFAICS
> all are commercial, and don't necessarily come as Century /Schoolbooks/.
> Third, even /if/ it were defined, it doesn't seem to work: I tried "Nimbus
> Sans L", the only font I could find right now which actually offers a bold
> condensed variant (with the same basename, i.e. [1]), and it falls back to
> regular even there.  Which came to no surprise after I saw
>
> # git grep bold-narrow
> Documentation/misc/ChangeLog-2.1: * scm/font.scm (paper20-font-vector): add
> bold-narrow series (only
> Documentation/misc/ChangeLog-2.1: * scm/define-grobs.scm
> (all-grob-descriptions): use bold-narrow
> scm/define-grob-properties.scm:   include @code{medium}, @code{bold},
> @code{bold-narrow}, etc.")
> scm/define-grobs.scm:             (font-series . bold-narrow)
>
> Is this symbol actually defined somewhere, and what am I missing?
>
>
> [1] This observation makes me wonder: is it possible to define different
> font basenames for several series of, say, the serif default font?  Some of
> my favourite fonts come in two flavours for normal spacing and condensed
> spacing, and my workaround - if I need both - is to define the condensed one
> as the monospace font to have easy access on it.  Which works, but is a
> complete abuse of the monospace entry.  The Real Thing would be to say
> "GarmdITC Bk BT" is my default serif font, with default proportions,
> "GarmdITC BkCn BT" is the corresponding condensed font. Some typefaces even
> need the same for bold, ultra-bold or something like this (e.g. Arial vs.
> Arial Black).  And when 'font-series is switched, of course the appropriate
> basename should be chosen.

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

Re: font defects in scripts.varsegno and accordion.push

[Werner LEMBERG]

> The README also says that we shouldn't apply transformations to
> fills, but instead transform the path then fill the path.  The
> current varsegno transforms the penstroke, which I think is contrary
> to this instruction.

Yep.  For this glyph it works accidentally.  Thanks for noticing, I've
missed it.


Werner

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

Re: font defects in scripts.varsegno and accordion.push

[Carl Sorensen]

On 10/20/10 1:59 AM, "Werner LEMBERG"  wrote:

> 
> 
>> +   ... {dir (180 - loopangle)}z7e{dir (180 - loopangle)}
> 
> This is too much :-)  The following
> 
> + ... z7e{dir (180 - loopangle)}
> 
> is sufficient.  A new patch attached (to preserve tabs for dull mail
> programs).
> 

The README also says that we shouldn't apply transformations to fills, but
instead transform the path then fill the path.  The current varsegno
transforms the penstroke, which I think is contrary to this instruction.

The draw_bulb macro should take care of the grazing intersection on the
bulb.

Thanks,

Carl


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

LyricText #'font-series = #'bold-narrow ?!

[Alexander Kobel]

Hi, folks,


why does LyricText #'font-series default to #'bold-narrow?

First, it's counterintuitive to me to have a bold narrow font as the 
most important thing to read in a piece; it's just too black-ish. 
Condensed seems fine for lyrics, but bold?
Second, it's defined for nearly no font, in particular Century 
Schoolbook L (the default of LilyPond) does not have it, IIUC, so 
regular is used instead.  At least, this holds for the free typeface; 
according to Wikipedia, there are Century designs featuring a narrow 
variant, but AFAICS all are commercial, and don't necessarily come as 
Century /Schoolbooks/.
Third, even /if/ it were defined, it doesn't seem to work: I tried 
"Nimbus Sans L", the only font I could find right now which actually 
offers a bold condensed variant (with the same basename, i.e. [1]), and 
it falls back to regular even there.  Which came to no surprise after I saw


# git grep bold-narrow
Documentation/misc/ChangeLog-2.1: * scm/font.scm (paper20-font-vector): 
add bold-narrow series (only
Documentation/misc/ChangeLog-2.1: * scm/define-grobs.scm 
(all-grob-descriptions): use bold-narrow
scm/define-grob-properties.scm:   include @code{medium}, @code{bold}, 
@code{bold-narrow}, etc.")

scm/define-grobs.scm: (font-series . bold-narrow)

Is this symbol actually defined somewhere, and what am I missing?


[1] This observation makes me wonder: is it possible to define different 
font basenames for several series of, say, the serif default font?  Some 
of my favourite fonts come in two flavours for normal spacing and 
condensed spacing, and my workaround - if I need both - is to define the 
condensed one as the monospace font to have easy access on it.  Which 
works, but is a complete abuse of the monospace entry.  The Real Thing 
would be to say "GarmdITC Bk BT" is my default serif font, with default 
proportions, "GarmdITC BkCn BT" is the corresponding condensed font. 
Some typefaces even need the same for bold, ultra-bold or something like 
this (e.g. Arial vs. Arial Black).  And when 'font-series is switched, 
of course the appropriate basename should be chosen.



Cheers,
Alexander

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

Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)

[Marc Hohl]

Am 18.09.2010 22:21, schrieb n.putt...@gmail.com:

[...]
I think the only sane method would be to use a scheme engraver, since
you could acknowledge interesting grobs and make typesetting decisions
for the TabNoteHead based on the grobs present at a particular timestep.

Done.



> This doesn't belong in 'details since it's set beyond the user's
> control: it only makes sense as an internal property, so should be
> defined separately
Done (I hope I did it right?)


Looks OK.  Just needs a few minor changes:

-) It's not user serviceable so should go in
`all-internal-grob-properties'.

Done.


-) As a flag which is usually #f, it doesn't need to be set in
define-grobs.scm: you can set the default when reading the property
instead.

Done.


-) It needs adding to an interface to prevent error messages popping up.


Done.

Regards,

Marc


http://codereview.appspot.com/2191042/




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

Re: font defects in scripts.varsegno and accordion.push

[Werner LEMBERG]

> +   ... {dir (180 - loopangle)}z7e{dir (180 - loopangle)}

This is too much :-)  The following

+ ... z7e{dir (180 - loopangle)}

is sufficient.  A new patch attached (to preserve tabs for dull mail
programs).


Werner
--- feta-scripts.mf.old	2010-10-17 13:40:03.0 +0200
+++ feta-scripts.mf	2010-10-20 09:54:57.0 +0200
@@ -1222,15 +1222,15 @@
 	penstroke z1e
 		  .. z2e
 		  .. z3e
-		  .. z4e{dir (-loopangle)}
-		  .. z5e{dir (-loopangle)}
-		  .. z6e
-		  .. z7e
-		  .. z8e
-		  .. z9e{dir (-loopangle)}
-		  .. z10e{dir (-loopangle)}
-		  .. z11e
-		  .. {dir (180 - loopangle)}z12e;
+		  ... {dir (-loopangle)}z4e
+		  -- z5e{dir (-loopangle)}
+		  ... z6e
+		  ... z7e{dir (180 - loopangle)}
+		  ... z8e
+		  ... {dir (-loopangle)}z9e
+		  -- z10e{dir (-loopangle)}
+		  ... z11e
+		  ... {dir (180 - loopangle)}z12e;
 	addto currentpicture also currentpicture scaled -1;
 
 	penlabels (1, 1', 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12);
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: font defects in scripts.varsegno and accordion.push

[Marc Hohl]

Am 20.10.2010 09:50, schrieb Werner LEMBERG:

This is probably overkill.  FontForge is quite good in doing this for
you, provided the intersections are well defined.  `fill' is necessary
because you can't exactly control the direction of the outline by
using `penstroke'.
   

But if I change from penstroke to fill, using zkr to go along one
side of the penstroke, then zkl to go back along the other side of
the penstroke, and controlling the directions at each of the points
on the glyph, I still get the same grazing intersections as showed
up in the glyph using penstroke.
 

OK.  I've just played a bit, and `fill' is indeed not necessary.  It's
sufficient to use `...' instead of `..', together with specifying
proper in and out directions to avoid inflections.  See attached
patch.  However, it doesn't fix the small grazing intersection at the
bulb.
   

Hello Werner,

thanks for this information - I will use your patch and try to get the bulb
well-defined.

Marc



 Werner


==


--- feta-scripts.mf.old 2010-10-17 13:40:03.0 +0200
+++ feta-scripts.mf 2010-10-20 09:41:46.0 +0200
@@ -1222,15 +1222,15 @@
penstroke z1e
  .. z2e
  .. z3e
- .. z4e{dir (-loopangle)}
- .. z5e{dir (-loopangle)}
- .. z6e
- .. z7e
- .. z8e
- .. z9e{dir (-loopangle)}
- .. z10e{dir (-loopangle)}
- .. z11e
- .. {dir (180 - loopangle)}z12e;
+ ... {dir (-loopangle)}z4e
+ -- z5e{dir (-loopangle)}
+ ... z6e
+ ... {dir (180 - loopangle)}z7e{dir (180 - loopangle)}
+ ... z8e
+ ... {dir (-loopangle)}z9e
+ -- z10e{dir (-loopangle)}
+ ... z11e
+ ... {dir (180 - loopangle)}z12e;
addto currentpicture also currentpicture scaled -1;

penlabels (1, 1', 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12);

   



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

Re: font defects in scripts.varsegno and accordion.push

[Werner LEMBERG]

>> This is probably overkill.  FontForge is quite good in doing this for
>> you, provided the intersections are well defined.  `fill' is necessary
>> because you can't exactly control the direction of the outline by
>> using `penstroke'.
>
> But if I change from penstroke to fill, using zkr to go along one
> side of the penstroke, then zkl to go back along the other side of
> the penstroke, and controlling the directions at each of the points
> on the glyph, I still get the same grazing intersections as showed
> up in the glyph using penstroke.

OK.  I've just played a bit, and `fill' is indeed not necessary.  It's
sufficient to use `...' instead of `..', together with specifying
proper in and out directions to avoid inflections.  See attached
patch.  However, it doesn't fix the small grazing intersection at the
bulb.


Werner


==


--- feta-scripts.mf.old 2010-10-17 13:40:03.0 +0200
+++ feta-scripts.mf 2010-10-20 09:41:46.0 +0200
@@ -1222,15 +1222,15 @@
penstroke z1e
  .. z2e
  .. z3e
- .. z4e{dir (-loopangle)}
- .. z5e{dir (-loopangle)}
- .. z6e
- .. z7e
- .. z8e
- .. z9e{dir (-loopangle)}
- .. z10e{dir (-loopangle)}
- .. z11e
- .. {dir (180 - loopangle)}z12e;
+ ... {dir (-loopangle)}z4e
+ -- z5e{dir (-loopangle)}
+ ... z6e
+ ... {dir (180 - loopangle)}z7e{dir (180 - loopangle)}
+ ... z8e
+ ... {dir (-loopangle)}z9e
+ -- z10e{dir (-loopangle)}
+ ... z11e
+ ... {dir (180 - loopangle)}z12e;
addto currentpicture also currentpicture scaled -1;
 
penlabels (1, 1', 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12);

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

Re: font defects in scripts.varsegno and accordion.push

[Werner LEMBERG]

> Here's a patch for the accordion push symbol.

This looks fine.

> It would have been simpler if I had just drawn two straight lines:
> 
> draw z1
>  -- z2;
> 
> draw z3
>  -- z2;
> 
> 
> This would seem to be allowed by the instructions in README, but I
> get the sense that mf2tp1 really doesn't like having draw
> instructions in the definition, so I thought it would be better to
> use the outline.

You can draw straight lines if the pen is a square, or rectangle, or
razor (this is the best of course), but not if it is polygonal $(Q#|(B
actually, any polygonal pen is a no-go if conversion to an outline
font is intended.

> Was I reading things right?

Mhmm, this my paragraph is really cryptic :-)  If you can reformulate
it, please do so.


Werner

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