Re: `+repage' option for convert?

[Alexander Kobel]

Werner LEMBERG wrote:

[Sorry if this has already been dealt with; I'm abroad, with no access
to the internet.]

This change

+   convert -depth 8 \
-alpha Off \
-background white \
-layers flatten \
-trim \
+repage \
$ $@

isn't understood by `convert' version 6.4.3 -- the `+repage' option
fails.  Is this a typo?


That's strange. +repage should be supported from IM 6.1.0 on, AFAIK. 
What gets converted here?


It's definitely not a typo. But if I get it right, it's just a shortcut 
for -page +0+0. (At least for BMP/GIF/PNG output; tested here using IM 
6.4.5, Ubuntu Jaunty build, on PNGs.)


Note that +repage is not (yet?) supported in the GraphicsMagick fork 
(which is the default replacement package at least in Ubuntu), while 
-page is. So to the best of my knowledge, using -page +0+0 is both an 
equivalent and more portable option, anyway.



Cheers,
Alexander


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

Re: Breve with double lines on each side

[Alexander Kobel]

Reinhold Kainhofer wrote:
A while ago we had that discussion about a user wanting two vertical lines on 
each side of the breve instead of one. I have now prepared a patch for our 
font, which adds such a noteheads.sM1double glyph:


Woah, great! Praise you! :-)

Regarding the single- vs. double-line breve: I have not yet found a reference 
to the single-line breve. Only the double-lined breve can be found practically 
everywhere:


I know the double-line shape very well, but I've seen the single-line 
version, too, in some transscriptions of Gregorian-inspired choral 
works, e.g. Samuel Barber's Agnus Dei, edition by G. Schirmer, 1967, 
and several others.


But the single-line version is especially often encountered in 
Psalmtönen, i.e. the semi-modern transscriptions of short Gregorian 
melodys, e.g. in the Gotteslob, the German Catholic church choral 
books. In this context, it is used to denote the main note (tenor) of 
the melody, which is to be repeated arbitrarily often depending on the 
number of syllables in the verse.
(See e.g. 
http://lilypond.org/doc/v2.12/input/lsr/lilypond-snippets/Rhythms#chant-or-psalms-notation.ly)


And, while you're at it: there is also a solid node head (quarter note 
head?) with single vertical lines, which basically means the same, but 
is only used for notes at the end of a line, not to be repeated too 
often, to adapt the melody to the stresses of the lyrics (finalis or 
flexa or something like that, IIRC).
I'd greatly appreciate a method to enter these without fancy scheme 
tweaks! ;-)


One thing I notice is that the vertical lines are usually a bit larger than 
the notehead. This would also change the default breve glyph, so I haven't 
included that in the patch. What do you think about this issue?


In the mentioned Gotteslob, the single-line version (both the brevis 
and the one with the solid note head) are larger than the note head - as 
a rough guess, they extend about 1/4 to 1/3 staff space above and below.
And, by the way, the lines are horizontally tight on the note head, not 
like the brevis in e.g. 
http://imslp.org/wiki/Mass_for_Five_Voices_(Byrd,_William)

If you want me to, I can make some scans tomorrow.

The same holds for some instances of the double-line variant I've 
checked in my songbooks; although I think the shape in the scores of 
Byrd's mass (with horizontal space between note head and lines) looks 
more elegant, the tight version seems to be more common.



Cheers,
Alexander


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

Re: [PATCH] option to prevent EPS backend from creating .tex/.texi/.count files

[Alexander Kobel]

Werner LEMBERG wrote:

Nice idea.  While you are at it, please investigate why there are
still clipping problems during the EPS-PNG conversion. [...]

As a possible solution, I can imagine that we add an intermediate step
to convert the fonts in an EPS file into PS paths, for example, by
using the `epswrite' device (as demonstrated in the `eps2eps' script
which comes with ghostscript).  This should assure that the bboxes are
exact.


Hi,

some time ago I tried to handle this problem with a little script. 
(Makefile attached.) However, I only dealt with PDF-PDF fixing.


In short: I couldn't quite manage to get good results with a 
GhostScript-only version, other than tweaking the BoundingBox entries in 
an intermediate EPS file for myself, using the GS -sDEVICE=bbox output.
Everything I tried with nothing but GS scripts either did not give the 
bboxes as exact as I wanted them, or actually rasterized the file.


Thus I decided to use pdftops from the libpoppler utilities. Which may 
be a problem for Windows, but perhaps it's not needed for EPS-x conversion.


Perhaps it will be useful as a template or give some ideas, but it 
certainly is not thoroughly tested. I have no idea what happens for 
multipage input files, by the way, but this problem won't come up for 
EPS-EPS conversion, I guess.



HTH,
Alexander
BASENAME=frieden
RESOLUTION=600
GS=gs -q -dNOPAUSE -dBATCH

.PHONY: all clean

all:$(BASENAME).pdf \
$(BASENAME)-trimmed.pdf \
$(BASENAME)-trimmed.png \
$(BASENAME)-trimmed-no-bg.png

%-trimmed.pdf:  %.pdf
#   $(GS) -sDEVICE=pswrite -sOutputFile=$*-fixed.ps $;
#   $(GS) -sDEVICE=epswrite -sOutputFile=$*-fixed.eps $*-fixed.ps;
#   head -n 1 $*-fixed.eps  $*-trimmed.eps;
#   echo `$(GS) -sDEVICE=bbox $*-fixed.eps 21`  $*.bbox;
#   sed -e 's/ %%HiResBoundingBox/\n%%HiResBoundingBox/'  $*.bbox  
$*-trimmed.eps;
#   tail -n +4 $*-fixed.eps  $*-trimmed.eps;
#   epstopdf --hires $*-trimmed.eps;
#   rm $*-fixed.ps $*-fixed.eps $*.bbox;
cp -f $ $@;
pdftops $@;
rm -f $*-trimmed.eps;
ps2eps -l $*-trimmed.ps;
epstopdf $*-trimmed.eps;
rm -f $*-trimmed.ps;

%.pdf: %.ly
lilypond $;

#%-trimmed.png: %.png
#   convert -trim $ +repage $@;
%-trimmed.png:  %-trimmed.pdf
convert -density $(RESOLUTION)x$(RESOLUTION) -units PixelsPerInch 
-colorspace Gray -depth 8 $ $@;

%-trimmed-no-bg.png:%-trimmed.png
convert -channel R $ -channel A -size 1x256 gradient:black-none -clut 
$@;

%.png:  %.ly
lilypond -dresolution=$(RESOLUTION) --png $;

clean: $(BASENAME).clean

%.clean:
rm -f $*-fixed.ps $*-fixed.eps $*.bbox;
rm -f $*.ps $*.pdf $*.png $*-trimmed.eps $*-trimmed.pdf $*-trimmed.png 
$*-trimmed-no-bg.png $*.midi;
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Vertical spacing of lyrics

[Alexander Kobel]

Christian Hitz wrote:

Hi,

the new vertical spacing is evaluating the skyline of the lyrics lines for
spacing. This leads to situations with a very uneven look, as the example
below shows. IMHO the tallest glyph in the used font should be used to 
derive the height of the lyrics line.


This very much depends on what you engrave. If you're making larger 
scores with many staves per system, vertical space is pretty much more 
important than everything else, and it's common practice to fit the 
lyrics as tight to the staves and as close together as possible.


If you want to have a more equal spacing, try modifying the LyricText 
#'minimum-Y-extent or (not sure if this works out) the new 
Lyrics.VerticalAxisGroup #'inter-loose-line-spacing [1]. E.g., in your 
example, adding

  \layout {
\context {
  \Lyrics
  \override LyricText #'minimum-Y-extent = #'(-1.5 . 1.5)
}
  }
to the score seems to solve the problem for me.

There are simple workarounds to simulate the 
one-box-to-rule-all-glyphs-approach, but if you decide to drop the 
skyline algorithm, it's nearly impossible to automatically achieve the 
tighter setting.



Cheers,
Alexander

[1] http://lists.gnu.org/archive/html/lilypond-user/2009-10/msg00215.html


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

Re: repeated music

[Alexander Kobel]

[from -user]

Francesco Petrogalli wrote:

I have no idea where to find documentation about this programming in
lilypond-scheme. There is a big list of scheme function in the
documentation, but I can't see any tutorial about using it.


Should this section A.16 Scheme functions also be moved to the Extend 
LilyPond manual, now that the Interfaces for programmers section is 
there? At least, there should be a link to the function list in the TOC 
of the Extend manual, and a corresponding link to the Extend manual on 
top of A.16.



Cheers,
Alexander


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

Re: Issue 638 in lilypond: auto-beam-settings do not take into account *all* durations covered by the beam

[Alexander Kobel]

lilyp...@googlecode.com wrote:
Comment #7 on issue 638 by percival.music.ca: auto-beam-settings do not 
take into account *all* durations covered by the beam


I think this is the autobeaming issue that Carl's working on.



Hi, Carl,

from what I understand from Graham's remark it is you who's working on 
beaming?
If so, perhaps you can help me with the following and/or include it in 
your thoughts and implementation.


I have a few pieces where I want use beams to denote melismata . On the 
other hand, for some longer melismata - often also including quarter or 
half notes - which I specify with slurs, I want the usual automatic 
beaming take place inside.


Now, it's awkward to always write ([ ]), when essentially ( ) already 
implies what I want. So, a straightforward idea was to leave auto 
beaming activated, and try a function like this:


INPUT: music m

slurred = false
for each chord c in m {
  if (c contains a ( [slur-begin]) {
slurred = true
add forbid-beam-to-the-left to c
add allow-beam-to-the-right to c
  } else if (c contains a )) {
slurred = false
add allow-beam-to-the-left to c
add forbid-beam-to-the-right to c
  } else {
if (slurred) {
  add allow-beam-to-the-left to c
  add allow-beam-to-the-right to c
} else {
  add forbid-beam-to-the-left to c
  add forbid-beam-to-the-right to c
}
  }
}

Alas, the problem is: the allow-beam-* and forbid-beam-* are 
nonexistent, AFAICS. \noBeam outside of the slurs destroys the auto 
beaming from the last possible beam start position to this point, which 
may influence notes in the surrounding melismata; and something like 
just adding [ to ( and ] to ) gives stub beams also in cases like { c8([ 
c4 c8]) }, where I actually want flags.



So, my question is: how much effort would it take to have such a 
allow-beam-* or forbid-beam-* functionality?
I also could imagine a \splitBeam command, which forbids a bridge beam 
between the preceding and the following note:


  { c8 c c c c \splitBeam c c c }
==  |  ===
|  |  |  |  |\ |  |  |
|  |  |  |  |  |  |  |

Then, the code for my function would look like

slurred = false
for each chord c in m {
  if (c contains a ( [slur-begin]) {
slurred = true
insert \splitBeam before c
  } else if (c contains a )) {
slurred = false
  } else {
if (! slurred) {
  insert \splitBeam before c
}
  }
}

Hell, even simpler. But - as I said - I have no idea of the work 
involved in this. It'd be great if you think about it, though.



Thanks,
Alexander


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

[GLISS] Syntax of \parallelMusic

[Alexander Kobel]

Hi, all,


something to discuss for the GLISS... I don't know where the right place 
is for such a suggestion (or if it's there at all), so I send it to 
-devel - so that it ends up in the archives at least.



I propose using a different separator for \parallelMusic than |, and 
allow to include bar checks in there.


\parallelMusic as is is very fine and handy, but sometimes you want to 
enter a whole phrase of two or three measures in a single go, and 
include the bar checks in there for readability and checking later on.
It somewhat disturbs the workflow if you always have to look up where 
the voiceN ended up in the last measure, especially if you have larger 
intervals in the voices, or reentering the durations if one voice stays 
in 16, the next in 8 and the third in 2.


What about, e.g., :? It's fast to type, and AFAICS, it only is used 
for chord mode and figured bass. And I don't see a use for those two in 
\parallelMusic, since - well, you usually only have one chord at a time, 
right?
Another idea: ||, to serve both as bar check and as delimiter. And 
there's definitely no use conflict against two bar checks at the same 
point in time, right?



Cheers,
Alexander


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

Re: [GLISS] Syntax of \parallelMusic

[Alexander Kobel]

[With forward to -user, since this may be interesting now for everybody.]

Nicolas Sceaux wrote:

Le 29 nov. 2009 à 16:15, Alexander Kobel a écrit :


I propose using a different separator for \parallelMusic than |, and allow to 
include bar checks in there.

\parallelMusic as is is very fine and handy, but sometimes you want to enter a 
whole phrase of two or three measures in a single go, and include the bar 
checks in there for readability and checking later on.
It somewhat disturbs the workflow if you always have to look up where the 
voiceN ended up in the last measure, especially if you have larger intervals in 
the voices, or reentering the durations if one voice stays in 16, the next in 8 
and the third in 2.

What about, e.g., :? It's fast to type, and AFAICS, it only is used for chord 
mode and figured bass. And I don't see a use for those two in \parallelMusic, since - 
well, you usually only have one chord at a time, right?
Another idea: ||, to serve both as bar check and as delimiter. And there's 
definitely no use conflict against two bar checks at the same point in time, right?


Currently, \parallelMusic highjacks the usual meaning of the pipe symbol: [...]
This was done so that \parallelMusic has no impact on the parser.


Thanks, Nicolas,

this was exactly the hint I needed... It never occured to me that 
parallelMusic might be a simple music function; I figured it's low-level 
and pretty involved in parser.

I can see clearly now, the rain is gone...

Which allows for a quite simple modification, to make the delimiter be 
||, combining a bar check and a voice cycle: Just count how often the 
existing voice change has been called, and only do some work if it's two 
times in a row.

The modification is attached, and seems to work flawlessly.

Of course, this still leaves the question whether the delimiter should 
be changed, and whether it's good to overload the bar check.
But it seems to me that the convert-ly rule should be so simple that 
even I might figure out how to write it, and I'm perfectly satiesfied 
with not having to remember the position of yet another symbol on the US 
keyboard layout... ;-)



Cheers,
Alexander
parallelMusic =
#(define-music-function (parser location voice-ids music) (list? ly:music?)
  (_i Define parallel music sequences, separated by '||' (double bar check 
signs),
and assign them to the identifiers provided in @var{voice-ids}.

@var{voice-ids}: a list of music identifiers (symbols containing only letters)

@var{music}: a music sequence, containing double BarChecks as limiting 
expressions.

Example:

@verbatim
  \\parallelMusic #'(A B C) {
c c | d d | e e ||
d d | e e | f f ||
e e | f f | g g ||
  }
==
  A = { c c | d d | e e | }
  B = { d d | e e | f f | }
  C = { e e | f f | g g | }
@end verbatim
)
  (let* ((voices (apply circular-list (make-list (length voice-ids) (list
 (current-voices voices)
 (current-sequence (list))
 (change-voice-call-count 0))
   ;;
   ;; utilities
   (define (push-music m)
Push the music expression into the current sequence
(set! current-sequence (cons m current-sequence)))
   (define (change-voice)
Stores the previously built sequence into the current voice and
   change to the following voice.
;; only do the actual work if change-voice is called the second time in a 
row
(if (odd? change-voice-call-count)
 (begin
  (list-set! current-voices 0 (cons (make-music 'SequentialMusic
 'elements (reverse! current-sequence))
   (car current-voices)))
  (set! current-sequence (list))
  (set! current-voices (cdr current-voices
;; increase the call counter
(set! change-voice-call-count (- 1 change-voice-call-count)))
   (define (bar-check? m)
Checks whether m is a bar check.
(eq? (ly:music-property m 'name) 'BarCheck))
   (define (music-origin music)
Recursively search an origin location stored in music.
(cond ((null? music) #f)
 ((not (null? (ly:music-property music 'origin)))
  (ly:music-property music 'origin))
 (else (or (music-origin (ly:music-property music 'element))
(let ((origins (remove not (map music-origin
  (ly:music-property music 
'elements)
 (and (not (null? origins)) (car origins)))
   ;;
   ;; first, split the music and fill in voices
   (map-in-order (lambda (m)
  (push-music m)
  (if (bar-check? m)
   (change-voice)
   (set! change-voice-call-count 0))) ;; reset the call counter
(ly:music-property music 'elements))
   (if (not (null? current-sequence)) (begin (set! change-voice-call-count 1) 
(change-voice)))
   ;; un-circularize `voices' and reorder the voices
   (set! voices (map-in-order (lambda (dummy seqs)
   (reverse! seqs

Re: [GLISS] Syntax of \parallelMusic

[Alexander Kobel]

Valentin Villenave wrote:

On Sun, Nov 29, 2009 at 4:51 PM, Nicolas Sceaux
nicolas.sce...@gmail.com wrote:

Modify parallelMusic, so that when a VoiceSeparator (instead of BarCheck)
music element is found, the function switches to the next voice.  The
parallelMusic function seems well documented, this part should not be
difficult.


(To whomever starts working on parallelMusic: please, please, please
implement #451 already!)
http://code.google.com/p/lilypond/issues/detail?id=451


Hi, Valentin,

to be honest - I have no clue what this bug report is about. Even 
assuming syntactically correct input. (By the way, after looking at 
parallelMusic, I'm not surprised at all that the newly posted snippet 
jun.ly works - however, if you wanted to use this, you'd have to write a 
new \relative {} construct for each and every bar.)


NR 1.5.2, section Writing music in parallel, explicitly explains 
examples (exciting alliterations...) to handle relative input:
	Relative mode may be used. Note that the \relative command is not used 
inside \parallelMusic itself.
	The notes are relative to the preceding note in the voice, not to the 
previous note in the input – in other words, relative notes for voiceA 
ignore the notes in voiceB.
The latter is not a bug, it's a feature - when I want to use relative 
mode, I want to not count octaves between notes, and it's much more 
reasonable for a ongoing voice to stay in the same range than the 
intervals between voices.


What's the problem about adding the relativity _after_ the 
\parallelMusic command? You barely start a \parallelMusic instance for 
three or seven notes, and if you have fifty lines of music, who cares 
about another

  relA = \relative c \A
  relB = \relative c \B
after a \parallelMusic #'(A B) { }? It's there, it's documented, and it 
does exactly what I understand to be desired from the mail linked in the 
bug description.


I think it's no problem defining a \parallelRelativeMusic command which 
does nothing but call \parallelMusic and wrap each argument inside a 
\relative c { ... } afterwards.

But do we really want this to exist?


Okay. After all the rant, I just saw that the discussion dates back to 
March 2006. Maybe this is just fixed by documentation work?



Cheers,
Alexander


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

Re: severe chord repetition problem

[Alexander Kobel]

Nicolas Sceaux wrote:

Le 6 déc. 2009 à 06:28, Werner LEMBERG a écrit :

Concerning chord repetition, the issues that have been raised are:

- Which elements should be copied?
Restrict the memorization to note chords (like c e g), and exclude
simple notes and rests?
I was recently in a situation where I would have liked to do e.g.
  re''2\rest q4 q8
whereas Alexander suggested not to memorize rests, so that on can write e.g.
  c c,8 q r q  q q r q


I think this relates to my preference of relative mode and Dutch note 
names. In contrary to the absolute mode and Do-re-mi-names, there is 
nearly no need to repeat single notes with q, since you can just type 
the note name another time without too much overhead (well, assuming you 
don't write too many eseses or fancy micro-accidentals).


I have to admit I had to look up \rest; I did not remember this command, 
and never used it so far. In such a case it really makes sense to have a 
shortcut for the copying, but IMHO the memoization of simple rests is 
unnecessary. May it be a reasonable decision to remember rests only if 
they have an attached pitch?


As another idea, I thought about implementing a custom copy policy for 
myself, which also copies some articulations, eventually those types 
defined by the user in a dedicated list. This could be done in Scheme: 
replace the repetition function and plug it in at runtime.
It'd be great if a similar approach could also be done concerning 
copying of simple notes vs. chords: The more you write in relative mode 
and with simple keys, the less you probably want q to memoize.


I'm not sure, though, if such a policy-based version is possible via 
Scheme (read: at runtime), since it seems to affect the parser.



Cheers,
Alexander


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

Re: severe chord repetition problem

[Alexander Kobel]

David Kastrup wrote:

Nicolas Sceaux nicolas.sce...@gmail.com writes:

Concerning chord repetition, the issues that have been raised are:

- \relative mode
A patch is available for review at http://codereview.appspot.com/164096
If nobody objects I'll commit it within a few days.


Maybe there should be a common strategy with \parallelMusic in
connection with \relative?  Possibly there is some overlap in the
problems.


Thought about this, too. The main difference is that it is currently not 
possible to attach ' and , to q, whereas this has to be considered for 
\parallelMusic input - although it'd make sense to have this feature 
also for q in the long term. The current patch, to my understanding, 
does not allow such an attachment, since it hardwires the octave of the 
repeated chord.



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

Re: severe chord repetition problem

[Alexander Kobel]

Nicolas Sceaux wrote:

I was also thinking about that:
Should the chord repetition function be enabled by default, or should
the interested user write e.g. \include chord-repetititon-init.ly ?

The call to a memorization function for every chords does not look like
a good idea wrt performances.


I don't know how much overhead that means. My intuition says it's not 
that bad, since it does not at all affect the positioning and layout, 
which AFAIK takes the lion's share of LilyPond's runtime. But it's 
really just intuition...


I suppose when this shortcut is polished, it will become part of the 
basic syntax in no time, so it should be as easily accessible as 
possible. That's a different thing than, e.g., the #'keep-inside-line 
property of NonMusicalPaperColumn, since it affects whether a file will 
compile at all, not just how it looks like.
If we allow the user to override the semantics of q, we could as well 
forbid it's use before booting it up, though - it's very similar to 
the choice of input note names. A sensible default could also be the 
don't copy anything and throw an error on use-policy.


In any case, I'd rather not suggest an \include ... syntax, 
considering the recent discussion about \include language.ly and the 
problem w.r.t. jail/safe mode.



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

Re: severe chord repetition problem

[Alexander Kobel]

David Kastrup wrote:

Actually, if q stands for last _chord_ rather than last note event,
then removing octave indicators is not sufficient since intervening
notes might have shifted the meaning.


Correct, that's the remaining drawback from the 
notes-chord-memorization; otherwise, this one perfectly fits /my/ usual 
needs.




But let it be clear: if LilyPond changes, it is no problem for me to
adapt Frescobaldi. If 2.14 ships with 'q' I'll do my best to have
Frescobaldi support it.


If the meaning is defined well enough.


I tend to use very simple tools - Emacs that is, in this case, without 
much sophisticated input shortcuts (like lyqi) - so I could not image 
where the problem might be to allow exchanging the memorization 
function, as long as the input is parseable. As most not-too-experienced 
programmers I tend to be overly self-confident, and say I'm gonna 
understand this if it's written there. Even when I'm going to read 
files, especially since I agree with Nicolas in:

On the other hand... which ratio of users might ever change the behavior
of chord repetition memorization?  I don't really think that readability
might suffer, as long as the default is the most convenient.
For instance, users can also completely change the note names [...]

And such a change should catch my eye.

But when it comes to editor support, things change. (In particular: a 
feature I'm desperately missing with my primitive input methods is 
actually already featured by other editors, so there might not be the 
need for it that I assume.)
Wilbert changed my opinions here - now, it looks like Nicolas' first 
idea of copying everything (well, perhaps everything but rests) may be 
what's actually needed more often. And it looks both easier maintainable 
and more robust than the notes-chord-memorization (see above.)



You (especially David i.e., but also Nicolas and Wilbert) certainly 
proved a clearer mind on such issues than me, and I agree with your 
concerns.
Still, since I'm happy to see that notes-chord-memorization gives me a 
feature I've been subconsciously craving for, and I'd be sad if it's 
removed again:
Is it okay to have an exchangable policy as long as it is very 
low-level, i.e. there are no commands inviting to write them every two 
lines, but only something like the current syntax to replace the 
repetition-memorization-function? Is it reasonable to have only one of 
those methods officially supported and recommended, the other 
deprecated, yet available? (Assuming it's not as prominently advertized 
as \parallelMusic, of course.)



Cheers,
Alexander


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

Re: bug rating

[Alexander Kobel]

Werner LEMBERG wrote:

Wouldn't it be
helpful if I could check the priority flag of the bugs to find
something I should work on more urgently than other things?  For
example, the Savannah bugzilla allows users to `rate' bugs.  The
higher the score, the more people would like to have this bug fixed.


That's actually possible, although not very prominently advertized. 
(Well, in fact it could be worse.  Once you open a specific bug, you can 
request these notifications with several links.)
It is a vote [aka star, aka subscribe] for this bug feature (first 
column in the bug list, if you're logged in), and you can show and sort 
by the Stars count column with ... on the upper right.


http://code.google.com/p/lilypond/issues/list?can=2q=sort=-starscolspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Stars

It's not too exciting, though, for now:  Out of 336 bugs, only 18 have a 
voting count of  3, with maximum 7, and about 50 have 3.  And I suppose 
one vote is automatically assigned to the one who opened the bug.



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

Re: Behaviour of chord repetition in \relative mode

[Alexander Kobel]

Werner LEMBERG wrote:

Hmm.  I won't mind if `q' is able to repeat a single note too, for the
sake of consistency.  Nicolas, would this be difficult to implement?


I don't think so - that's what Nicolas had in mind (and implemented) 
first.  I suppose I'm the one who made him thinking about the other 
variant, since I took chord not as the Event structure, but actually 
as a chord consisting of different notes, which seems useful in piano 
music.  In the meantime, I changed my mind a bit, considering the 
(valid) concerns from David and Wilbert:  the repetition of all events 
(but, perhaps, skips and rests) seems to be easier to define 
consistently, and the lack thereof might not justify irritations about 
the semantics of the input.  (E.g. in the case of this relative mode 
problem.)


Well, since the code basically seems to be there in both variants, and 
both of them are useful:  (and I expect David to come after me, but 
that's what I want since he proves a far better understanding of 
meaningful semantical conventions...)
Is it reasonable to use _both_ approaches, with shortcuts, say, q 
(everything repeated, including pitched rests, e.g.) and Q (only 
chords with several notes repeated), but not to offer the exchange of 
the memorization functions for those?



Cheers,
Alexander


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

[PATCH] Re: Centered Poet rolling of the paper 2.12.2 and 2.13.1

[Alexander Kobel]

Alexander Kobel wrote:

Wilbert Berendsen wrote:

Hi,

this code:

\header {
  poet = \markup \center-column {
\line { poet with Long Name }
\small (1800-1900)
  }
  composer = \markup \center-column {
\line { composer with Long Name }
\small (1800-1900)
  }
}

{ c' }

results in falling the poet off the paper. It looks like the column is 
centered on the margin.


Confirmed.  Looks like a strange artifact of the \fill-line markup 
(containing both poet and composer) w.r.t. a negative first X-extent 
entry of a \center-column, IIUC.


The attached patch for fill-line (scm/define-markup-commands.scm) should 
do the expected thing.
fill-line currently only considers the extents of the stencils, not 
their position relative to the X-origin; with the patch, they are 
shifted according to the first stencil argument.


Sorry in advance for non-proper indentation, a probably non-proper patch 
format, and not having in on Rietveld or something like this, but to be 
honest, I don't want to take the time to bother with git's functionality 
and a coding account setup right now.



Cheers,
Alexander
--- scm/define-markup-commands.scm.new	2010-01-11 16:47:46.0 +0100
+++ scm/define-markup-commands.scm	2010-01-11 16:43:31.0 +0100
@@ -850,11 +850,8 @@
 
 (if (null? (remove ly:stencil-empty? orig-stencils))
 	empty-stencil
-  (ly:stencil-translate-axis
-  	 (stack-stencils-padding-list X
-  RIGHT fill-space-normal line-stencils)
- (- (car (ly:stencil-extent (car stencils) X)))
- X
+	(stack-stencils-padding-list X
+ RIGHT fill-space-normal line-stencils
 
 (define-markup-command (line layout props args)
   (markup-list?)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Where does paper-height come from?

[Alexander Kobel]

b...@shingarov.com wrote:

Hi all,

I am playing with the vertical spacing algorithms, and am very
surprised by the behavior of page-height.

Let's say for example that I set my paper to A6.  This, by ISO216, is
148mm high.
when calc-printable-height applies (ly:output-def-lookup layout
'paper-height), it ends up in Output_def::lookup_variable() and
ultimately in ly_module_lookup().  This does not return 148, but
84.22!!! [...]


Hi.

Are you aware of the units?  I'm not at all, and neither did have a look 
in the code, but 84.22 is suspiciously near to 148 / (7/4), where the 
parenthesized term is 7 mm per 4 staff units, which is (not considering 
rounding errors) the default global staff size.
More accurate: I think LilyPond uses a pt size of 1/72.27 in, so a staff 
(with four staff units) has height 20*25.4/72.27 mm = 7.0292 mm, and 148 
/ (7.0292 / 4) = 84.22 to a precision of three digits.


So I'm quite sure that the output of output-def-lookup is in global 
staff size units, not in mm, and a conversion happening somewhere hidden 
in the code, and not specifically for page-height.



HTH,
Alexander


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

Re: (bug?) irregular lyrics distance in 2.13.10

[Alexander Kobel]

Joe Neeman wrote:

Am Mittwoch, 13. Januar 2010 17:02:18 schrieb David Kastrup:
That's basically the approach taken by Joe for spacing staves: Place the 
center lines minimum-spacing apart, except if the skylines would (almost?) 
overlap (including a padding). In the latter case add space until no overlap 
occurs. Of course, when stretching is enabled, things are a little more 
involved.


I just don't know how Joe aligns lyrics, in particular, whether only the 
extents are used or whether the baseline is used like the center line for 
staves.


The minimum-distances are measured from the origin of the line. That
is, if the extent of a staff is (-5 . 5) then we measure from the
center. Thus, we just need to make sure that the origin of a Lyrics
line is its baseline (I can't check this right now). Then it should be
sufficient just to set minimum-distance to the desired line-skip.


This would be sufficient for the inter-lyrics spacing, but we should 
take care that it does not influence the staff-to-lyrics spacing for the 
bad.  Or is this one determined by the actual extent of the glyphs?



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

Re: (bug?) irregular lyrics distance in 2.13.10

[Alexander Kobel]

Reinhold Kainhofer wrote:

Here's a file with all different spacings from 2.0 to 4.0...

Looking at some scores with two lyrics lines (mostly oratorios with two 
different language), I would tend to choose 2.8 or 3.0.


+1.


There are some other issues I notice with the layout:

1) For my taste the piece names are too close to the previous score (and too 
far away from the one they are attached to).


+1.

2) The distance between the last lyrics line to the next staff is not constant 
throughout the page!


It's not a bug, it's a feature.  At least I think so - it's because of 
the default 'staff-affinity to the top staff.  See the attached file 
with 'staff-affinity = #CENTER.  You won't change the 'minimum-distance 
for each system in a real-world example, so IMHO it'd be a very minor 
problem, anyway.


Still, the lyrics have a larger subjective whitespace distance to the 
staff below than the one above, probably due to the spacing based on the 
baseline.
\version 2.13.11
\pointAndClickOff

\paper { ragged-last-bottom = ##f }

lyr = \lyricmode { 
  These are just some ran -- dom __ _ _ ly -- rics, these are just some ran -- _ _ dom ly -- rics!
}

cs = \new ChoirStaff 
\new Staff { \new Voice =1 \relative c'' { \repeat unfold 5 { c4 c c c } } }
\new Lyrics \with { \override VerticalAxisGroup #'staff-affinity = #CENTER } \lyricsto 1 \lyr
\new Lyrics \with { \override VerticalAxisGroup #'staff-affinity = #CENTER } \lyricsto 1 \lyr
\new Lyrics \with { \override VerticalAxisGroup #'staff-affinity = #CENTER } \lyricsto 1 \lyr
\new Staff { \new Voice =2 \relative c' {\clef bass \repeat unfold 5 { c2 c } } }
\new Lyrics \lyricsto 2 \lyr
\new Lyrics \lyricsto 2 \lyr
 

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #2.0
}
  }
  \header { piece = Lyrics minimum-distance = 2.0 }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #2.25
}
  }
  \header { piece = Lyrics minimum-distance = 2.25 }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #2.5
}
  }
  \header { piece = Lyrics minimum-distance = 2.5 }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #2.8
}
  }
  \header { piece = Lyrics minimum-distance = 2.8 }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #3.0
}
  }
  \header { piece = Lyrics minimum-distance = 3.0 }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #3.2
}
  }
  \header { piece = Lyrics minimum-distance = 3.2 }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #3.5
}
  }
  \header { piece = Lyrics minimum-distance = 3.5 }
}

\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #3.7
}
  }
  \header { piece = Lyrics minimum-distance = 3.7 }
}



\score {
  \cs
  \layout {
\context {
  \Lyrics
  \override VerticalAxisGroup #'inter-loose-line-spacing #'minimum-distance = #4.0
}
  }
  \header { piece = Lyrics minimum-distance = 4.0 }
}



lyrics_spacing.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patch: issue #659

[Alexander Kobel]

Marc Hohl wrote:

I don't know. The staff lines should end a little bit earlier, see

http://lilypond.googlecode.com/issues/attachment?aid=-394070284723943851name=segno-end.pnginline=1 

I don't think it is a good idea to let the segno sign reach into the 
margin, so

the staff lines have to end before reaching the right margin.


Hi, Marc,

thanks for dealing with this.


I found another example (the one in the bugtracker comes from me, too), 
from Bosworth  Co. as well, but this time without bar lines spanned 
across the staves.  (Anyone seen a source where this glyph is used by 
another publisher?)
Here, the double bar lines are not drawn through the whole staff, but 
the staff lines actually extend across the segno.


I'd prefer drawn-through bar lines (which seems easier to implement, 
anyway), but I'd expect the segno sign to reach into the margin.  (The 
same as with, say, a fermata centered over the final bar line.)
If (as shown here) the system is actually ragged-right (or stopped after 
the segno), it doesn't harm too much, anyway, since the Dal segno text 
comes after it with some padding.  However in case the segno ends a 
flush-right system, it occurs to me that a visually shorter staff 
(especially with SpanBar lines) is worse than the segno extending into 
the margin.


Just my two pennies...


Cheers,
Alexander
inline: dal-segno-end.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patch: issue #659

[Alexander Kobel]

Marc Hohl wrote:

Trevor Daniels schrieb:

It is easy
for a user to move the sign to the end of the staff lines with

   \once \override Score.BarLine #'extra-offset = #'(1 . 0)
   \once \override Score.SpanBar #'extra-offset = #'(1 . 0)

if this was really wanted, although this would admittedly push
it into the right margin.


Indeed.  It's not quite exactly '(1 . 0), but just slightly less, but 
this is nearly not noticeable.



Would it make sense to provide another varsegno symbol which looks exactly as
the one I have drawn, but has no positive witdh (to the right of the center)?


This sounds more elegant than the tweak above, but I'm not sure if this 
alone is worth the effort of an additional symbol.



Another idea: Is it possible to have a double bar line at the end of a 
line, and the segno bar line at the beginning of the next?  What about 
.S doing this, as opposed to S, or have an additional ||S and S||?



Cheers,
Alexander


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

Re: Patch: issue #659

[Alexander Kobel]

Marc Hohl wrote:

Alexander Kobel schrieb:

Marc Hohl wrote:

Trevor Daniels schrieb:

It is easy
for a user to move the sign to the end of the staff lines with

   \once \override Score.BarLine #'extra-offset = #'(1 . 0)
   \once \override Score.SpanBar #'extra-offset = #'(1 . 0)
[...]
Would it make sense to provide another varsegno symbol which looks 
exactly as
the one I have drawn, but has no positive witdh (to the right of the 
center)?


This sounds more elegant than the tweak above, but I'm not sure if 
this alone is worth the effort of an additional symbol.
Me, too. It still feels somewhat clumsy to do it in this way, but on the 
other hand - if it looks alright,

one more sign in the font should not be a big problem.


I just noticed that the 'extra-offset won't influence the spacing of the 
notes before the bar line.  The better property to tweak should be the 
right-edge extra space, but this does not work if the line ends 
prematurely.  (See the attached example.)
Still, like Trevor I'm not sure why modifying the X-extent does not work 
- this should be the favourite option, theoretically equivalent to 
another glyph without positive width, right?


Another idea: Is it possible to have a double bar line at the end of a 
line, and the segno bar line at the beginning of the next?  What about 
.S doing this, as opposed to S, or have an additional ||S and 
S||?


I must admit that I don't have lots of references for this symbol and 
its use. If this is a sensible
default, there is no problem in defining .S just doing what you 
proposed. Can you do some investigations?
As you posted the examples in the tracker, I think you are the most 
important source of informations here ;-)


I don't really know if I saw the ||-before-break, S-after-break 
combination, but I think it makes sense to offer it since coda parts are 
often seperated by double bar lines when the default segno sign is 
above them.
I'll see what I can find in real examples.  I don't think I have 
anything more at my place, though, so I'll have to look through the 
repertoire of my choir.  (Again, I can't remember to have it seen in any 
non-Bosworth  Co. scores...)  I'll give you feedback ASAP.



Cheers,
Alexander


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

Re: Patch: issue #659

[Alexander Kobel]

Marc Hohl wrote:

Alexander Kobel schrieb:
I don't really know if I saw the ||-before-break, S-after-break 
combination, but I think it makes sense to offer it since coda parts 
are often seperated by double bar lines when the default segno sign 
is above them.
I'll see what I can find in real examples.  I don't think I have 
anything more at my place, though, so I'll have to look through the 
repertoire of my choir.  (Again, I can't remember to have it seen in 
any non-Bosworth  Co. scores...)  I'll give you feedback ASAP.
Did you find anything? If not, tell me what you want to have as 
standard, and I will adapt my code.
I doesn't seem that there is an overwhelming interest in the varsegno - 
which doesn't bother me,
because *I* like the sign and will use it regularly as soon as it is 
released.  So we both, being called the

varsegno group should be able to decide what we want ;-)


Hi Marc, hi all,

and sorry for the delay.  As you certainly noticed, the weather was an 
experience the last days, and thus my choir did not have any rehearsals, 
so I had to wait for a look into our note repertoire.


I did not found too much.  Most parts have the plain S bar somewhere 
in between, but I found one combination of a segno and a |: bar line 
afterwards (once more Bosworth  Co.).  This one also has the double bar 
line drawn through the segno symbol, and there's about the width of a 
double bar line between S and |:.  (It's a cheap old copy, not very 
legible, but I can provide you a scan if you want.)  Yes, this really 
makes sense if there are several stanzas (with volta repeats), and the 
first part of the last stanza switches to a coda.
I'm not sure how the double bar line would look in combination with a 
SpanBar, though - I'd guess it looks best if the SpanBar only affects 
the |:, but not the S part.


So, what do I think is useful?  In the optimum, we should have the 
following combinations:


In-line:
- S
- :|S (repeated intro, e.g.)
- S|: (the case mentioned above)
- :|S|: (certainly unusual, but possible)

On a line break:
- |S (| end of line, S begin of line)
- S| (S only end of line)
- ||S (|| end of line, S begin of line)
- S|| (vice-versa)
- basically the same options for repeats, i.e. :|S, S:|, S|:, 
|:S, :|S|:, and perhaps even :|S.|:, where the :|S is at the end 
of line, and only |: at begin of line.


S should be mapped to either |S or ||S on line breaks - I'd prefer 
||S, since this exactly fits my use of the traditional segno glyph so 
far, but that's just personal taste.
In general, I have a strong opinion against the S at the end of the 
first line in break situations, because the reader is forced to do an 
additional saccade, but I've seen several scores where the traditional 
segno sign is placed at the end of the line.  Anyway, it has to be 
offered, because things like \stopStaff followed by a Dal segno al 
fine have to be possible.


As for the X-extent, as I mentioned before, I'd prefer the segno 
slightly sticking out of the staff lines into the margin and having the 
|| aligned with the right edge, but that's just personal taste - I 
could not find a print where S is used at the end of a line without a 
D.S. al fine text following, and for this both variants (staff lines 
drawn through the whole symbol, or just to the double bar line) can be 
found.
One more remark: I did not test your current implementation in 
combination with clef, key or time changes.  Is this an issue?  It'd be 
nice to have a key change printed between S and a D.S. al fine text 
to remind the reader of the different key in the repeated part.



Whoah.  I'm afraid that might be more than you hoped for?

Cheers,
Alexander


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

Re: bounties

[Alexander Kobel]

On 2010-05-19 17:00, Kieren MacMillan wrote:

Hi Graham,

There are also other sponsorship offers (by me, which I can confirm are still open) 
which don't seem to be in the Google code bounty pile: [...]

http://lists.gnu.org/archive/html/lilypond-user/2009-11/msg00789.html

Plus, I seem to recall at least two other people willing to chip in for the 
bounties on break-alignment with MetronomeMarks, and a real 
piano-with-centred-dynamics fix.
[Can't find the links right now.]


Yup, here I am for the piano-centered dynamics - same link, 50 EUR.  Not 
sure if there's anybody else, though.

And of course my offer still holds.

Oh, and of course I know that this amount is extremely low given the 
work involved, as Graham stated, but ... well - it's better than 
nothing.  Even more so when Joe provides a perfect example, saying that 
he's happy to accept bribes, but they won't drastically affect his TODO 
list priorities, just because his main constraint on Lilypond work is 
time rather than money.
AFAIK (and hope), none of you guys codes in Lily for his living, but at 
least there may be a free dinner sometimes to soothe the Significant 
Other...



Cheers,
Alexander

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

Re: bounties

[Alexander Kobel]

On 2010-05-19 19:08, Graham Percival wrote:

I mean, if something
would take you 20 hours, and somebody offers $10 and a piece of
bubble gum, it's not very encouraging.  If ten people offered the
same thing, it would add up, of course.


True.  And that's how we all like to see it, right?  Alas, the joy of 
idealism...



But I've heard from some
developers that taking a bounty isn't worth the trouble of setting
up a paypal account.


Depends on your usual day business, I guess, and whether you're paid 
what you're worth.  If not so, the 300 $ you mentioned is quite a bunch 
of money, too...



AFAIK (and hope), none of you guys codes in Lily for his living, but at
least there may be a free dinner sometimes to soothe the Significant
Other...

[...]
An alternative to donating it to the FSF (or whatever charity you
like) would be for the developer to offer a bounty on something
that affects *them* -- either something they want to use for their
own lilypond compositions, or something they want for their own
*development* work (like the source code indentation program or
new build system).


Of course that's entirely up to the developer of some patch.  I'd be 
fine with either option.



Cheers,
Alexander

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

Re: Bezier curves [was: Dependencies in Lilypond]

[Alexander Kobel]

On 2010-06-08 17:59, Carl Sorensen wrote:

P.S. If you have more stuff you want to do with Beziers, give me a shout.
I've taken Dr. Sederberg's class, so I'm somewhat aware of clever tricks
with splines.  That's where my bezier stuff came from earlier.


Whoever wants to do something serious with Bezier curves or splines 
(curves, surfaces, whatever), be sure to check out Gerald Farin's 
Curves and Surfaces for CAGD (Computer Aided Geometry Design): A 
practical guide, Morgan Kaufmann Publishers.  It's to Bezier what Ross 
is to music engraving, I guess (though I didn't manage to get the latter 
in my hands yet).  A really amazing book, which should be available in 
every university library with an ounce of self-respect.



Cheers,
Alexander

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

PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)

[Alexander Kobel]

See http://codereview.appspot.com/1689041.

My fix tries to reintroduce the behaviour of 2.13.11 for the issue 
mentioned, before my patch to 
http://www.mail-archive.com/lilypond-devel@gnu.org/msg27098.html, but 
to keep the 2.13.12+ behaviour for more than two elements inside a 
fill-line.
Besides, I tried to tackle the issue I mentioned here: 
http://www.mail-archive.com/lilypond-u...@gnu.org/msg51242.html, which 
is that nested fill-lines used to shift their contents by some amount to 
the right.


I still think that fill-line is badly specified for single arguments, 
but I can't think of any better rationale for it as well.


For some reason, I don't seem to be able to build the regtests; so all 
this should be taken with care, I did not really check if it breaks 
anything.
And once again, please clean up the indentation.  The real sources 
just look like a complete mess in my Emacs configuration.  I did not try 
to understand this, but rather to guess my tabs and spaces to fit...



Cheers,
Alexander

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

Re: PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)

[Alexander Kobel]

On 2010-06-14 20:24, Neil Puttock wrote:

On 14 June 2010 15:34, Alexander Kobeln...@a-kobel.de  wrote:


Besides, I tried to tackle the issue I mentioned here:
http://www.mail-archive.com/lilypond-u...@gnu.org/msg51242.html, which is
that nested fill-lines used to shift their contents by some amount to the
right.


Heh, I was just about to post a fix for that myself
(http://code.google.com/p/lilypond/issues/detail?id=382), using a
slightly different approach: checking whether the text-width equals or
exceeds line-width.


I thought about that, too, when I first tried to do this several months 
ago.  Not sure why it didn't work out; probably it was just a  vs. = 
issue.
On the other hand, I don't quite get why word-space = 1 is necessary. 
If there's no space left, the user has trouble anyway, and I don't see 
why an arbitrary minimum space should help.  And this should be the 
reason for the shift, IIUC.  Seems like an ugly hack to me, but probably 
there's some reason?


Another question: What does mol stand for in the markup definitions, 
e.g. in general-align in define-markup-commands.scm?



For some reason, I don't seem to be able to build the regtests; so all this
should be taken with care, I did not really check if it breaks anything.


It compiles fine without any breakages.


That's how far I could go.  I just can't get the regression tests, so I 
can't compare if it breaks desired output in other examples than mine.



And once again, please clean up the indentation.  The real sources just
look like a complete mess in my Emacs configuration.  I did not try to
understand this, but rather to guess my tabs and spaces to fit...


Doesn't C-M-\ indent a region for you automatically?


It does, but it also reindents the existing code in a completely 
different manner than what's currently there.



One thing your patch doesn't cover is Reinhold's problem with compound
time signature formatting (see
http://code.google.com/p/lilypond/issues/detail?id=732);


Okay; didn't check this.  Probably one can see it in some regression 
test, then...



I wonder
whether we should just add his suggestion for translating the stencil
returned by \center-column onto its left edge (which would simplify
your \fill-line fix.)


If we do, we should probably normalize all stacked stencils (read: 
right-column, too) in the same manner.  Which would make sense to me, 
since it's a consistent behaviour, but I suspect this to be incompatible 
with the current design.  And one might require to write \right-align 
\right-column to get the (current?) extent ((- width) . 0), which looks 
clumsy from the typical user's POV.



Cheers,
Alexander

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

fill-line spec and (center-/right-)column alignment [was: PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)]

[Alexander Kobel]

[ Reordering the topics according to general interest. ]

On 2010-06-14 23:14, Neil Puttock wrote:

On 14 June 2010 21:47, Alexander Kobeln...@a-kobel.de  wrote:

On the other hand, I don't quite get why word-space = 1 is necessary. If
there's no space left, the user has trouble anyway, and I don't see why an
arbitrary minimum space should help.  And this should be the reason for the
shift, IIUC.  Seems like an ugly hack to me, but probably there's some
reason?


I don't know why that's there; the default is set in
ly/paper-defaults-init.ly to 0.6.


Uh-oh, so that's another occurence of defaults set in different places 
to different values (in define-markup-commands.scm, and thus the NR, 
it's 1)...  I can hear David's screams... ;-)


Anybody knows if we can remove the minimum space?  IMHO, this will make 
the code cleaner without causing unexpected trouble on the user side.
Checking the NR A.8.2, \fill-line is the only markup command to mention 
a separate default for word-space, and the description of \fill-line 
says nothing about it's meaning.  Looks to me like it was copied from 
\line, and been forgotten afterwards.



I wonder whether we should just add his suggestion
[Reinhold: http://code.google.com/p/lilypond/issues/detail?id=732]
for translating the stencil
returned by \center-column onto its left edge (which would simplify
your \fill-line fix.)


If we do, we should probably normalize all stacked stencils (read:
right-column, too) in the same manner.  Which would make sense to me, since
it's a consistent behaviour, but I suspect this to be incompatible with the
current design.  And one might require to write \right-align \right-column
to get the (current?) extent ((- width) . 0), which looks clumsy from the
typical user's POV.


Hmm, I hadn't considered that, though I wonder if anybody uses \right-column.


Definitely, at least in the composer field (though it should not matter 
there, since this one gets nested in a fill-line anyway), but probably 
also for instrument names or a whole bunch of little tweaks and markups. 
 Googling on the LSR gives about 40 hits for center-column and 
right-column, and of course there's thousands of hits on the whole web. 
 It seems very hard to tell in advance how many of those will be 
affected by a change in the extent.




Some of the indentation in \fill-line is incorrect (e.g., for the
definition of fill-space), so you're probably improving it. :)


Ah, this might well be why it does not make too much sense to me right now.
So, usually the Emacs default is okay for Scheme code, too?  The CG only 
says that GNU style is used for C++, but nothing about Scheme.



Another question: What does mol stand for in the markup definitions [...]

It's short for molecule [...]


Ok, thanks.


Sorry, I meant the regression tests run fine (with `make check'); no
test snippets appear broken.


Perfect.  Thanks, too.


Cheers,
Alexander

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

Re: fill-line spec and (center-/right-)column alignment [was: PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)]

[Alexander Kobel]

On 2010-06-15 00:28, Alexander Kobel wrote:

On 14 June 2010 21:47, Alexander Kobeln...@a-kobel.de wrote:

On the other hand, I don't quite get why word-space = 1 is necessary. [...]


Anybody knows if we can remove the minimum space? IMHO, this will make
the code cleaner without causing unexpected trouble on the user side.
Checking the NR A.8.2, \fill-line is the only markup command to mention
a separate default for word-space, and the description of \fill-line
says nothing about it's meaning. Looks to me like it was copied from
\line, and been forgotten afterwards.


I updated the issue on Rietveld with a version of fill-line where 
word-space is completely ignored: http://codereview.appspot.com/1689041.


I think I know now how to properly compile and check the regression 
tests, and I can't spot anything that's broken by this change.  Comments?



Cheers,
Alexander

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

[Doc Patch] Re: (2.13.x) bottom-system-spacing

[Alexander Kobel]

Hi, dear developers  doc reviewers,

concerning the documentation of bottom-system-spacing discussed on -bug, 
I'd like to propose some additions/corrections to the docs.  All those 
deal with NR 4.1.2, Page formatting.

http://codereview.appspot.com/1710046


Cheers,
Alexander


On 2010-06-18 17:02, Graham Percival wrote:

On Fri, Jun 18, 2010 at 3:42 PM, Alexander Kobeln...@a-kobel.de  wrote:

On 2010-06-18 16:02, Joe Neeman wrote:

For the same reason that between-system-spacing uses the center of the
staff and not the edge. The height of the footer can vary from page to
page and if we use it then the vertical spacing will not be consistent.


Okay, I see now.  Maybe this should be mentioned in the docs, then.


I don't have a clue what you're talking about, but it sounds like
something that falls under the small doc additions after looking at
documentation suggestions:
http://lilypond.org/website/help-us.html


True.  Again, a hint in the docs, where foot-separation used to be, might be
useful.


Same here.


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

Re: patch for underline function

[Alexander Kobel]

On 2010-05-25 14:33, Kieren MacMillan wrote:

Hi all,

I want to have independent control of the thickness and offset of the
underline markup function -- unfortunately, they are currently linked
(i.e., the offset is a multiple of the thickness). [...]


[This mail is essentially copied from 
http://code.google.com/p/lilypond/issues/detail?id=1104 to have it on 
-devel...]


@ Graham: W.r.t. 
http://lists.gnu.org/archive/html/lilypond-devel/2010-07/msg00015.html, what's 
a non-developer supposed to do with his review?  Post on -devel? 
Comment in the issue description?  Both?  Neither?



Hi, Kieren,


LGTM, but I'm not allowed to push, too.  I'm just trying to follow 
Graham's beg for reviewers...


A minor correction:
(* -1 offset) can be simplified to (- offset) in the (let*) clause for y.

   (let* ((thick (* (ly:output-def-lookup layout 'line-thickness)  [...]
  (y (* -1 offset))   [...]


I like your default value for offset, since in normalsize text, the 
underline does not cross the descenders of the font.  But I wonder 
whether both offset (linearly) and thickness (= linearly) should be 
scaled with font-size, for a consistent look e.g. in the 
((sub-)sub-)title fields?



Cheers,
Alexander

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

Re: patch for underline function

[Alexander Kobel]

On 2010-07-14 10:42, Graham Percival wrote:

On Wed, Jul 14, 2010 at 10:34:01AM +0200, Alexander Kobel wrote:

@ Graham: W.r.t.
http://lists.gnu.org/archive/html/lilypond-devel/2010-07/msg00015.html,
what's a non-developer supposed to do with his review?  Post on -devel?
Comment in the issue description?  Both?  Neither?


A post to -devel is fine.  If you have a lot of comments, it might
be nice to post on the codereview google website... but merely
sending an email to -devel is still incredibly helpful.


Once I recognized that it's not very hard to get the build setup running 
(on a Linux box, I mean), I immediately appreciated the benefits of 
Rietveld.  If the patch is there, it's of course the best option to 
comment there.
Kieren still lacks a git setup, though, and this very patch has only 
been mentioned on the -devel list and the bug tracker, so I guess it's a 
special case.  I can prepare a proper git patch and post it on Rietveld, 
but I'd rather do so once I have some comments about the font-size 
relation of this functionality.


Regarding your new entry in the tracker about how to comment:  Rietveld 
looks like the best option for reviews, but I dislike to force everybody 
to use it.  I'm not sure how many developers really can't prepare git 
diffs or submit to Rietveld, but I vaguely remember and respect David's 
concerns to open yet another account, especially with a possible data 
leech, and it requires an up-and-running git.
Since it requires write access to finally push the patch anyway, I 
propose discussions on -devel, and a link to the thread in the bug 
tracker for reference.  Once the patch LGTEveryone, preparing the git 
diff-style patch should not take long.  And it can be done by anybody, 
like me, with no need for real (LilyPond) programming experience.



Cheers,
Alexander

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

Re: patch for underline function

[Alexander Kobel]

On 2010-07-14 12:15, Graham Percival wrote:

On Wed, Jul 14, 2010 at 12:08:39PM +0200, Alexander Kobel wrote:

Regarding your new entry in the tracker about how to comment:  Rietveld
looks like the best option for reviews, but I dislike to force everybody
to use it.  I'm not sure how many developers really can't prepare git
diffs or submit to Rietveld,


Everybody developer can do this.  Lilybuntu makes it easy to have
git and compile stuff.


You're aware that Kieren reads this, too? :-)  Or does this run in the 
virtual box under MacOS now?



but I vaguely remember and respect David's
concerns to open yet another account, especially with a possible data
leech, and it requires an up-and-running git.


I'm not happy about requiring a gmail account, but since that's
necessary for the issue tracker as well, I think we just need to
bite the bullet and accept it.  :(


Uh, correct.  I completely forgot this. I never use my gmail account 
anyway, and the login's stored...


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

Re: patch for underline function

[Alexander Kobel]

On 2010-07-14 12:34, Graham Percival wrote:

On Wed, Jul 14, 2010 at 12:21:56PM +0200, Alexander Kobel wrote:

Or does this run in the virtual box under MacOS now?


Lilybuntu is a virtual machine.  It can be run in vmware or
virtualbox on top of linux, windows, or macos.  We've had two new
documentation writers using lilybuntu exclusively for the past 6
months, on a mixture of windows and osx machines.


Oh, that's good news.  I missed that; I didn't want to be sarcastic, but 
rather really didn't know about it.



Any other questions?


Nope, thanks. :-)


Cheers,
Alexander

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

Re: [PATCH] fix to issue 1116

[Alexander Kobel]

On 2010-07-30 21:51, Neil Puttock wrote:

On 30 July 2010 15:11, Mike Solomonmike...@ufl.edu  wrote:

This solution works for the minimal example given with the issue, and it
works in general if one accepts the assumption that there is no reason that
anything fed through stack-lines (in scm/stencil.scm) should have an X
extent whose left boundary is anything other than 0.  However, I
don'tunderstand lilypond well enough to know:

a) if this is a good assumption
b) if this assumption breaks something else.


You'll probably be interested in Alexander Kobel's patch for this
(http://codereview.appspot.com/1689041/show).


Hi, Mike and Neil,


I just had a quick glance at your mails, and as Neil recognized, I'm 
still waiting for a response on my latest patch to fix this issue.
I'm quite satisfied with the solution w.r.t. centering headers, but 
there's still room left for further investigation of fill-line, as I 
described in the comments to the patch Neil quoted.


Unfortunately, I most probably won't have any spare minute until Aug 09 
to care about this piece of code (there's a kind of festival taking 
place in my hometown which I help to manage), but feel free to discuss 
my code and possible extensions.  I'll have a look at it next week.



Cheers,
Alexander

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

Re: Odd messaage from 2.13.32

[Alexander Kobel]

On 2010-09-01 04:28, Mike Solomon wrote:

Hey all,
 Just got 2.13.32 running and got the following message:

warning: couldn't fit music on page: overflow is -0.00

I think it's good to get a warning message when there's spillover, but it
seems odd that an overflow of 0 would solicit a warning message.  Thoughts?


I think this might be due to an actual value just below zero, but not 
far enough to fit in the seven shown digits.  This warning comes from 
lily/page-layout-problem.cc, line 307-309:

  if (!spacer.fits ())
warning (_f (couldn't fit music on page: overflow is %f,
 spacer.configuration_length(spacer.force()) - 
page_height_));


I suspect the warning procedure (macro?) just calls printf, which by 
default only shows the leading digits:

  printf (Small number: %f\n, -0.01);
  printf (Higher output precision: %.16f\n, -0.01);
gives
  Small number: -0.00
  Higher output precision: -0.0100
on my system.


HTH,
Alexander

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

Re: -dinclude-settings=INCLUDEFILE.ly

[Alexander Kobel]

On 2010-09-04 00:35, Trevor Daniels wrote:

Am Freitag, 3. September 2010, um 22:49:50 schrieb -Eluze:

my command was: lilypond -V -dinclude-settings
c:\data\ly\includes\myTestInit.ly test.ly

what is wrong?


No idea. Your file works fine here.


This works fine here in the Vista command window:

C:\Users\Trevorlilypond -dinclude-settings=includes/testInit.ly test4.ly

It also works if I use a backslash, but it generates the warning:

programming error: file name not normalized: includes\testInit.ly
continuing, cross fingers


Looks like relative paths are okay, while absolute paths cause trouble. 
 Just an idea, I don't own a Windows system to test.



Cheers,
Alexander

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

Re: lily/freetype-error.cc: const struct #include ;

[Alexander Kobel]

On 2010-09-07 01:28, Alexander Kobel wrote:

[...] Here's my shot to explain it:  [...]


Hm, when I just tried to look up a bit of the syntax, I stumbled across 
this:

  http://en.wikipedia.org/wiki/C_preprocessor#X-Macros
That's basically it.


Cheers,
Alexander

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

Re: lily/freetype-error.cc: const struct #include ;

[Alexander Kobel]

 On 06/09/10 22:30, Wols Lists wrote:

 Because C doesn't give a monkeys about white space, but the
 pre-processor does. The #include has to be the first thing on the line
 otherwise the pre-processor will screw up, but once the pre-processor
 has done its job, the compiler will happily ignore all the surplus new
 lines.


And, IIRC, the preprocessor even deletes the newline after the include, 
which is why the compiler issues a warning if included files do not end 
with a newline character.  An #include in the next line would be 
ignored, or something like this.



const struct Freetype_error_message // this bit is the structure definition
{
  FT_Error err_code;
  const char*  err_msg;
// this bit now declares the array and fills it
} ft_errors[] = ( (1, message1), (2, message2), (0, 0) ) ;


That bit between the = and ; initialises the array (and I've almost 
certainly got my syntax complete crap :-).


The ()s should be {}s, but otherwise it's okay, I think.


Here's my shot to explain it:
Assume you have a list of items like these in a header file, which 
should not be copied, but rather only included to stay aware of updates:


/* data.h */
/*TitleArtist Year  Best Song */
DISC (Back in Black, AC/DC,   1980, Hells Bells)
DISC (IV,Led Zeppelin,1971, Stairway to Heaven)
DISC (Thriller,  Michael Jackson, 1982, Billie Jean)
/* EOF */

Now you want to fill an array of structs, but you only care about the 
best songs of each artist.  Then you can just do:


/* some .c file */
/* ... */
#define DISC (t, a, y, s) { a, s }
struct BestSongOfArtist {
  const char * artist,
  const char * song
} artist_song_map[] = {
#include data.h
};
#undef DISC
/* ... */

and here you are.

In the case of fterrors.h, stuff is slightly more complicated since 
there are default mappings for some macros.  Say, most people won't need 
the best song, but only the remaining fields, then the file looks like this:


/* default_format_data.h */
#ifndef DATA_START_TOKEN
{
#else
DATA_START_TOKEN
#endif

#ifndef DISC
#define DISC_DEFAULT_USED
#define DISC (t, a, y, s) { t, a, y }
#endif
#include data.h
#ifdef DISC_DEFAULT_USED
#undef DISC
#endif

#ifndef DATA_END_TOKEN
}
#else
DATA_END_TOKEN
#endif
/* EOF */

and you could just write

/* some .c file */
/* ... */
struct DiscStruct {
  const char * title,
  const char * artist,
  const char * year
} database[] =
#include default_format_data.h
;
/* ... */

It's not a nice coding style, but it keeps all those definitions at only 
one place (good thing), and once you figured out what's going on, it's okay.
And as is noted somewhere in the docs for the Boost preprocessor 
metaprogramming library, the preprocessor exists to be used, so don't 
shy away.  It's bad to clutter the global space with #defines, but it's 
equally bad to introduce a lot of non-macro (struct, function, 
variable...) names there.  (Sadly, namespaces are not an option for C.) 
 It's not all that rare for larger libraries to have a little stuff 
coded like this.


As Wol, I didn't compile this, so my syntax might be crap, too; but the 
essence should be there.  (And no, I didn't know the release years just 
out of my head... ;-))



HTH,
Alexander

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

Re: equivalent to \once within scheme?

[Alexander Kobel]

On 2010-09-15 10:09, Marc Hohl wrote:

Hello all,

IIUC, \override grob #'foo = #bar
is more or less the same as
(ly:grob-set-property! grob foo bar)

Is there a scheme equivalent for
\once \override Grob #'foo = #bar ?


Hi, Marc,

if _I_ understand correctly, the (ly:grob-set-property! grob ...) is 
_exactly_ the \once \override ..., since it applies to the specific 
instance of a grob you give as an parameter.  It just depends where you 
call it - which is usually inside some callback set by \override Grob 
#'after-line-breaking or such.  Thus, the (ly:grob-set-property grob 
...) is called for every grob of type Grob.
But if you, say, construct grobs in scheme, and run the function only 
for one of the resulting grobs, or apply it only the second instance of 
a broken spanner (which is divided into two grobs (or even more for a 
three-system-long VoltaBracket, e.g.?) it behaves exactly like a \once 
\override.



HTH,
Alexander

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

Re: attachment points for vertical spacing dimensions

[Alexander Kobel]

On 2010-10-05 21:53, Carl Sorensen wrote:

On 10/5/10 12:09 PM, Mark Poleskymarkpole...@yahoo.com  wrote:

Of the three, bottom-system-spacing is slightly more
complicated, since it currently controls the spacing below
systems *and* markups, when either is the last on a page.
So the natural attachment point for systems would remain the
same, but would be shifted to the lowest Y-coordinate for
markups (ideally).


Again, I like the name last-item-spacing, which would apply to whatever is
the final layout item and the bottom margin.

Again, with proper understanding of padding, I think everything works
properly.

As I now understand things, I think that I would be unlikely to use
minimum-distance for anything.  I think I'd just use space and padding.


I regularly use 'minimum-distance and a large negative 'padding in 
bottom-system-spacing to align the last staves to the same Y-offset, 
regardless of single note descenders or similar.
Also, this is a case where I actually wish the reference point of the 
markup were on the opposite side, i.e. the bottom of the markup (or top 
of the bottom margin), s.t. any copyright or tagline really stays inside 
the footer and does not destroy the alignment of the staves on the page. 
 That'd amount to introducing a new last-staff-to-bottom-margin-spacing 
and leaving bottom-system-spacing as is, or - functionally equivalent, 
but somehow irritatingly - shifting the attachment point of 
bottom-system-spacing to the bottom of the markup and adding 
last-staff-to-top-of-markup-spacing.



Personally, I think we should add a new variable to control
the spacing between a markup and the bottom margin.  We
could call it bottom-markup-spacing for now


@ Mark: is the latter what you meant with your idea from above?


Cheers,
Alexander

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

Re: attachment points for vertical spacing dimensions

[Alexander Kobel]

On 2010-10-07 04:11, Joe Neeman wrote:

On Wed, Oct 6, 2010 at 1:26 AM, Mark Polesky markpole...@yahoo.com
mailto:markpole...@yahoo.com wrote:
Joe Neeman wrote:
  I would argue that the baseline is more natural then the
  bottom.  Moreover, using the baseline as a reference point
  will result in more even spacing of multiple consecutive
  lines of markup.

Okay, that's a good point, so I agree -- baseline is better
than bottom.  But do you agree with Carl and Trevor that we
should always use the same reference point for markups?  I
was specifically proposing to use the bottom of the upper
markup and the top of the lower markup for
between-title-spacing, but Carl argued eloquently against
it.  Carl's argument is probably much more solid than mine,
but just for the record, what do you think?

I don't care so much about one versus two reference points (although the
current code only works with one), but I do think that the reference
points should not depend on any ascenders or descenders.


Hm, I'm not sure.  The baseline in some sense is the natural place to 
attach references to - that's how it's done in most applications I can 
think of.  On the other, hand, these typically deal with single lines on 
their own...
For a markup placed /above/ a staff (or another markup, by the same 
argument), the baseline of the lowest line of the markup is a sensible 
reference (even better than the bottom corner, since, as you pointed 
out, this does not depend on an ascender).  However, this is a poor 
choice for markups (like footer) /below/ a staff - if you add a line 
here, you'd have to redo spacing.  Using the baseline of the top-most 
line would be better, but looks far harder to code.
Furthermore, both baselines don't allow a good handling of the case of 
non-character markups (a score - What's the baseline there? The middle 
line of some staff? -, a figure, whatever) which has larger height than 
a letter of the default font.  And font sizing doesn't change the 
baseline, but the ascender and descender height.


Honestly, I don't think it's worth the hassle.  IMHO, we should try to 
give reasonable definitions, but not to deal with each and every 
possible use case; the user needs to tweak, and he probably won't find 
the optimal values for all these spacing variables by anything but 
trial-and-error.  Let's not complicate this by overcluttering with a 
huge bunch of options.
As for fonts, it's not too hard to guess the extent of a line, 
especially since baseline-skip is given in staff units.  The topmost 
point as anchor works fine in many cases, and padding additionally is 
there to avoid trouble.


The only point the current layout does not work well for me is tweaking 
the pages s.t. the topmost and bottommost (center lines of) staves align 
over all pages, but even there I can perfectly live with a manual 
positioning of the footer and, optionally, a \with-dimension #'(0 . 0) 
#'(0 . 0) there.  And if the very last line of a score is slightly above 
the others, I don't feel it disturbs the overall impression.  Things are 
easier for the top, since the first page has the book header, and the 
page number has the same extent on all the others.



I've noticed that in many traditionally-engraved scores, [...]
For example, say score1 has title/subtitle/etc. in the usual
place (top center), and piece/opus also in the usual place
(flush left and flush right just above the top system), and
the top system has no protruding skyline.  Now score2 has
all the same titling but the top system has a really high
note just before the rightmost barline.

To prevent a collision between the last note and the opus,
LilyPond will shift the first system down.  Fine.  But what
I've noticed in the classic scores is that in this
situation, the top system is not shifted down, but rather
the opus is shifted *up*.  This is an important difference!

It means that the placement of the top system is determined
by the bookTitleMarkup, and the scoreTitleMarkup is
determined by the top system.  And it usually looks better
this way (and more consistent from score to score). [...]

I won't say it's more trouble than it's worth, but I don't think it's
trivial. In lilypond-spacing-backend terms, I think you want to treat
the opus markup as a loose line.


Now, that'd be an feature...  Even assuming that we'd have to take opus 
out of the header tags - can one manually add loose lines besides Lyrics?



Cheers,
Alexander

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

Re: names of vertical spacing dimensions

[Alexander Kobel]

On 2010-10-06 17:46, Mark Polesky wrote:

I also think the name 'space is misleading; I propose
'default-distance.  Opinions?


I can't see why 'space should be misleading, but that might just be that 
I'm accustomed to it by now.  It's shorter, but anything other is okay 
as well.
(Of course, this requires an understanding of the connections 'padding 
vs. 'space and 'stretchability vs. 'minimum-distance.)


But should it be 'default-distance or 'optimal-distance?  Default to 
me (non-native speaker) implies that it's the value proposed by the 
system, which can be overridden by the user.  I think optimal fits 
better in the sense that it's the user-given value which the layout 
algorithms aims to achieve, but does not always succeed to reach.  In 
this sense, 'stretchability is a deeper feature most users hopefully 
don't have to care about too much; what you want to tweak is 'space.



Cheers,
Alexander

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

Re: names of vertical spacing dimensions

[Alexander Kobel]

On 2010-10-07 15:53, Carl Sorensen wrote:

I like base-; it's shorter to type, and it still carries the right
connotation.


+1.


Cheers,
Alexander

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

Re: names of vertical spacing dimensions

[Alexander Kobel]

On 2010-10-09 17:46, Mark Polesky wrote:

CURRENT NAME   PROPOSED NAME
   -
top-system top-system
top-title  top-markup
between-title  markup-markup
after-titlemarkup-system
between-system system-system
before-title   system-markup
bottom-system  system-bottom
between-scores-system  score-system


Huh.  Sorry that I missed the weekend discussion; in general I support 
these names.
I'm not quite sure if they will be clearer to the everyday user who 
mainly thinks in terms of titles and scores, headers and footers, 
though, and probably won't have a bunch of settings for all of these, 
but rather uses the default for everything but what used to be 
'after-title-spacing. [1]
But since the new names are consistent and I definitely lack to come up 
with something more clever, I'm satisfied.  (At least until GLISS, that is.)


[1] I tried to figure out what's the buzz with scoreTitleMarkups and 
bookTitleMarkups.  From a user's POV, both of them are 
top-level-markups, right?  Is there anything different because one 
belongs to the score and the other to the book (aka real top-level)?
I think after-title and between-title are the perfect identifiers for 
the spacing between those, but the whole naming system gets messed up if 
you include custom markups.  /Perhaps/ I'd like aliases, but I don't 
want to think about this until GLISS.  And, essentially, aliases are 
ugly anyway, so encapsulating headers in a separate category (score - 
markup - headerMarkup?) may be better, or...  Not something to discuss now.


By the way, right now it isn't possible to change spacing /in between/ 
of a book environment, is it?  It's reasonable to think that the very 
main header (and the very first music line) will need a different 
spacing than all other markup-system-pairs, even if a scoreTitleMarkup 
is absent.
So it'd be cool to allow changing the spacing variables inside the book 
block, or have some LaTeX-\vfill-like command with the four spacing 
variables as arguments:  \vspace #'((spacing . 5) (stretchability . 
20)), ... you get the point.  But again, this looks like a major (read: 
postponed) change is necessary.



Cheers,
Alexander

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

Re: names of vertical spacing dimensions

[Alexander Kobel]

On 2010-10-12 14:27, James wrote:

On 12/10/2010 12:54, David Kastrup wrote:

Jamesjames.l...@datacore.com writes:

Why do we have
'top-system' but 'system-bottom' and not instead, 'bottom-system'?


Because there is no system after the bottom?


?

I'll stop if I am really showing my ignorance (I am not a code
developer), but from a user-point of view it would be much more
'logical' if the naming was split *consistently* into

What you are changing (system, markup, title etc) and where you are changing.


That's what I meant when I wrote after-title-spacing and 
before-title-spacing (as is) are good names IMHO.
/But:/ The more consistent naming scheme is the new one; on this I agree 
with Mark, Carl, David, and some of the others.


All these variables describe vertical spacing, which means there is 
always a Foo above the space and a Baz below the space.  Thus, 
foo-baz-space sounds fine, doesn't it?  (This logic implies 
system-bottom-spacing, of course.)
Of course, the user usually thinks of your three-divisioned scheme 
titling/headers, music, markups, but Lily's state of the art is that 
titling and top-level markups are the same.  If we were to introduce 
this distinction as a separate, well, 
object-taking-vertical-top-level-space category, we'd have even more 
meaningful and understandable names; but this looks like it's /far/ out 
of the scope of this patch and discussion.


And as to where you are changing: The settings just do not allow 
controlling the spacing independent of the subsequent element.  That'd 
look like - similar to the (horizontal) space-alists for some grobs - 
the following, if I understand you correctly:

  after-staff-spacing = #'((Staff . ((space . 5) (stretchability 7)))
   (Lyrics . ((minimum-distance . 7)))
   (Markup . ((padding . 3)))
   (Titling . ((space . 8) (stretchability 20) 
(minimum-distance . 8) (padding . 5
... and so on.  This looks theoretically possible, but to me it does not 
look better than the current approach.  Rather worse: what if you want 
to change just a single entry? Rewrite the whole thing?


I see your point, but do you think it's worth it before GLISS?


Cheers,
Alexander

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

Re: names of vertical spacing dimensions

[Alexander Kobel]

On 2010-10-13 00:20, Wols Lists wrote:

  On 12/10/10 14:02, Kieren MacMillan wrote:

Hi James,
 [...]
If Lilypond users are confused because they don't have an understanding of that 
basic and universal terminology, they should read (1) some engraving books, and 
(2) the Lilypond introductory documentation.

3) Take a basic music theory course.

For a musician to get that wrong is as seriously incompetent [...]


On 2010-10-12 15:24, Trevor Daniels wrote:

I'm afraid you're showing your ignorance as a musician.
System and score are not synonomous. [...]


Come on, guys, calm down.  First, not everybody's a native speaker, and 
even if they are or know the terms, score-system-spacing is confusing at 
the first glance.  After all, the user might think: My scores consist of 
systems - why should I specify a distance between the system and the 
score it is in?  Ah, okay, it probably means the spacing between 
different systems in a score.
Well, bang, you're dead - wrong conclusion drawn.  I'd understand this 
way of reasoning if somebody only sees the name of the variable without 
further explanation, and thus I see James' point.  But really, the logic 
upper object - lower object is simple enough to explain in one 
sentence, and if the user reads it, he should be fine.



Cheers,
Alexander

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

Re: names of vertical spacing dimensions

[Alexander Kobel]

On 2010-10-13 00:27, Wols Lists wrote:

Add stave to this. Actually, I would have defined a stave as a line of
music, and a system as a group of linked staves played simultaneously.
But that all depends on how you understand the word line :-)


Stave or staff?!  Are these identical?  I thought stave is just a 
wrong singular form of staves, which itself is the correct plural of 
staff?

Merriam-Webster says nothing about these words in a musical context... :-(

Cheers,
Alexander

___
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: LyricText #'font-series = #'bold-narrow ?!

[Alexander Kobel]

On 2010-10-20 15:34, Werner LEMBERG wrote:

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.


Ok.  So #'medium should be correct now?
It's hardly worth it (it's just one change in scm/define-grobs.scm), but 
here's a patch: http://codereview.appspot.com/2675042/.  Would you 
check this?



Cheers,
Alexander

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

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

[Alexander Kobel]

On 2010-10-28 02:30, Ralph Palmer wrote:


On Wed, Oct 20, 2010 at 9:27 AM, Valentin Villenave
valen...@villenave.net mailto:valen...@villenave.net wrote:

Hi Alexander,

CC-ing to the bug list just in case.

On Wed, Oct 20, 2010 at 2:39 PM, Alexander Kobel n...@a-kobel.de
mailto:n...@a-kobel.de wrote:
  why does LyricText #'font-series default to #'bold-narrow?
[...]
Greetings -

I'm directing this primarily to bug-list folks. This was submitted over
a week ago, and I see no action. Did I miss something? [...]


Hi, Ralph,

thanks for your attention, but it's fixed (by commit 
d0c8a258b168c41a3d40f714c55f8fccadfe7d8c).  Werner and I forgot to send 
a note to the bug- list, sorry.



I don't
understand fonts or typefaces or their parameters well, so I don't
understand whether there is a bug or not.


Since we don't offer a bold-narrow style in Century Schoolbook (and most 
other fonts don't as well), the fallback was the regular font anyway. 
So it's been an unexpected expected (desired) behaviour.



[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.


This might count as enhancement request.  Postponed, if you ask me.


Cheers,
Alexander

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

Re: Renaming the 'space alist-key

[Alexander Kobel]

On 2010-11-06 18:32, Mark Polesky wrote:

7 proposals for renaming the 'space alist-key have been
discussed, but a decision has not yet been made.  And I just
added an 8th proposal (initial-distance).  [...]

2) optimal-distance
* sounds like the resulting trade-off between the
  desired distance and situational spacing constraints
3) desired-distance  [...]
5) base-distance
* sounds like the distance between bases  [...]


This might complicate it, but 2, 3 or 5, with decreasing preference.

Sorry for not being active anymore in the recent discussions, by the way.


Cheers,
Alexander

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

Re: Renaming the 'space alist-key

[Alexander Kobel]

On 2010-11-07 16:30, Mark Polesky wrote:

[...]
 SPACE  MINIMUM-DISTANCE
--  --
1)   basic-distanceminimum-distance
2) initial-distanceminimum-distance
3)   basic-separation  minimum-separation
4) initial-separation  minimum-separation

Alexander, I hope you don't feel disenfranchised, [...]


I didn't even know that word until now, so I can't possibly be. ;-)  I'm 
by no means offended, and I very much appreciate the thoughts and work 
you invested in this topic; far more than I'm able to do.



It's nothing personal, and I hope you understand!


Of course - you're welcome.


Trying to sum up:


Alexander: 1
Carl:  1
David:  1
Joe:
Mark:  1
Patrick:   2
Trevor: 4
Valentin:  2


Doesn't look like my opinion is underrepresented, by the way... ;-)


Cheers,
Alexander

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

Re: renaming vertical spacing inside systems props

[Alexander Kobel]

On 2010-11-09 00:54, Trevor Daniels wrote:

Mark Polesky wrote Monday, November 08, 2010 7:14 PM

Keith E OHara wrote:

We will use this in context that makes that first
qualifier almost redundant :
\override Context.StaffGrouper #'withingroup-staff-staff-spacing


This is an excellent point, and in response I'd like to
propose one more option -- just remove the withingroup
prefix altogether:

\override StaffGrouper #'staff-staff-spacing
\override StaffGrouper #'staffgroup-staff-spacing

Thoughts?


LGTM

(As I've said before, I admire your persistence :)


+1.


Cheers,
Alexander

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

Re: Clarifying the 'padding alist-key

[Alexander Kobel]

On 2010-12-09 16:15, Mark Polesky wrote:

Mark Polesky wrote:

1)
padding - the minimum required amount of vertical
whitespace between two items, measured in staff-spaces.
When available, skylines are used in the spacing
calculation.

2)
padding - the minimum required amount of vertical
whitespace between the skylines of two items, measured in
staff-spaces.



Carl Sorensen wrote:

I prefer 2.


Trevor Daniels wrote:

2, but is skylines explained anywhere in the docs?  If
it is, it is not indexed.


2 for me, too.


Interesting.  I just assumed you'd both prefer #1, because
IIUC most items don't have skylines for padding.


Most?  Anyway, after all, the main task of LilyPond still is typesetting 
/music/, not the headers.  And for the spacing of staves, the skyline is 
both available and essential to understand, and should be prominently 
advertized.



For example, do things like title/toplevel markups, lyrics, etc.
have skylines?


Markups: No, but - no skyline is a skyline, too, just a flat one...  I 
consider this as a missing feature; I don't see the point why headers 
and toplevel markups should not have skylines.  It's an annoyance when a 
single high note and a tempo mark at the beginning of a piece push the 
distance to the header, although only the composer and arranger (right 
side markup) are given.  So, documenting the skylines sounds like the 
correct thing to me, but stating that top-level markup's ones are, well, 
somewhat unusual for now.
(When available from #1 sounds simple and descriptive, though, but I'd 
like to have skyline the default.)


Lyrics do have skylines, as well as chord names and IIUC basically 
everything you can enter in a score block.  That is, everything /but/ 
top-level markups?
(Though sometimes the estimations aren't that good as well; see the 
discussions recurring every now and then about refining skylines for 
hairpins, slurs or volta brackets, where the skylines are used for the 
intra-system spacing and extent estimation.)



Trevor: when I `git grep' for skyline in the Documentation
directory, I get nothing, so to answer your question: no,
skylines are not explained anywhere in the docs.


Well, the same point I mentioned in 
http://codereview.appspot.com/2316042/, right?
I'm still not sure if it eases or complicates things to not use the term 
for the user, but in the end it's not too hard to understand to spare it 
out.  And that it's lacking in the whole Documentation dir means that 
it's in absolutely no docs, right?  That's bad - I can't see a point 
where this fits in the IR, but for some spacing tweaks it's important to 
have the real deal explained.



Cheers,
Alexander

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

Re: lilypond authors, release notes, announcements

[Alexander Kobel]

On 2011-01-05 11:09, James wrote:
 Marc,
 
 On 05/01/2011 09:50, Marc Hohl wrote:
 My contribution to fonts was the rotation of the G clef and the varsegno
 sign
 (which nobody seems to use, anyway ;-)
 
 Au contraire mon amis!
 
 I use the varsegno glyph at the slightest opportunity!

Dito.

 It helps the 'beginners' (I find) that I play with as it seems to be
 much more easy to spot for them that are not used to jumping about in a
 score, than the regular segno.

Additionally, sometimes I think it's far more easily to integrate in the
overall design than the usual symbol.  Yours takes no precious vertical
space, and I don't have to bother with shifting around till it's at the
best place.

 I am sure that I am breaking some engraving 'rule' but it's a nice glyph.

I've seen it in Bosworth  Co. scores only, but they seem to use it
exclusively instead of the common shape.
But I also made up the habit of telling the ones I hand my scores out to
that I use a unusual symbol for d'al segno, to avoid irritations.


Cheers,
Alexander

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

Re: lilypond authors, release notes, announcements

[Alexander Kobel]

On 2011-01-05 11:13, Graham Percival wrote:
 On Wed, Jan 05, 2011 at 10:09:27AM +, James wrote:
 Marc,
 What I think we need actually - slightly off topic - is a nice
 LilyPond-glyph similar in essence to when you see the word 'Latex'
 in a body of text. I suppose some would call it a 'logotype' or
 colophon.

 tagline = \markup { Engraved by \musicglyph #scripts.lilylogo }
 
 I've mused about trying to create a logo using the markup
 commands.  If you think about all the graphical ones, plus music
 glyphs, there's a lot of options.  The d could be a rotated bass
 clef, the ls could be compressed treble clefs, the p could be a
 half note, etc.

I tend not to like those assembled logos very much.  Most of the time,
they end up too clumsy IMHO; more like something quickly hacked
together, just for the sake of quoting musical symbols.
However, I'd certainly use a predefined command for the inclusion of
something like Valentin's logos from lilynet.net. [*]  (Sadly, I don't
remember the correct address where I downloaded it from.  I mean the SVG
sources of http://www.lilynet.net/img/lilylogo.png and
http://news.lilynet.net/local/cache-vignettes/L125xH100/lesite-d163a.png.)
 One might argue that the quaver looks childish, but IMHO it does in a
very joyful and charming manner.  And I really like the lilys, but I'm
not sure whether a full-colored logo is a good default choice.

[*] I actually already used these once, but in a separate title page
generated with inkscape, not via LilyPond itself.


Cheers,
Alexander

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

Re: lilypond authors, release notes, announcements

[Alexander Kobel]

On 2011-01-05 12:11, James wrote:
 No this isn't what I was referring to. [...]
 I was thinking more of a 'lilypond' in some
 cursive-cum-signature-cum-all-joined-up script,
 but something 'created' as a glyph than just put together.
 
 If you think of J S Bach's signature then that could be used as nice
 glyph on a tagline.

Ah, okay, I get it.  Sorry for the misunderstanding.  Of course I meant
logo + LilyPond text, not the logo alone, but still that's a different
thing.
Yeah, that'd be nice indeed...

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

Re: lilypond authors, release notes, announcements

[Alexander Kobel]

On 2011-01-05 12:58, Federico Bruni wrote:
 Il giorno mer, 05/01/2011 alle 11.36 +0100, Alexander Kobel ha scritto:
 I tend not to like those assembled logos very much.  Most of the time,
 they end up too clumsy IMHO; more like something quickly hacked
 together, just for the sake of quoting musical symbols.
 
 You mean something like this? (my 5 minute try, really horrible)
 
 \version 2.13.45
 
 \markup {
   \lower #.5 { \number 1 }
   \musicglyph #scripts.ustaccatissimo
   \lower #.5 { \number 1 }
   \musicglyph #scripts.ustaccatissimo
   \lower #.5 { \dynamic p }
   \musicglyph #noteheads.s0 \hspace #1
   \musicglyph #scripts.prall
   \semiflat
 }

13371p4wn3d, huh? ;-)

Yup, that's what I meant.  I know a couple of amateur musicians who
copied some musical symbols to replace single characters of their names
for their letterheads.  I can't think of a single one which doesn't look
ugly.  Sizes don't match, kerning (if that term is allowed for this)
does not match, it looks crowded...  Just like using about the whole
fonts folder for an A5 greeting card.

I'm aware that a good designer can do amazing stuff in this direction,
but this will need subtle quotations and resemblence to the symbols, not
just concatenating and rotating a few of them.  If someone's up to it -
well, then show us what you can do!

 However, I'd certainly use a predefined command for the inclusion of
 something like Valentin's logos from lilynet.net. 
 
 That's a nice idea. Maybe we could provide a blackwhite logo also...

Still, I like James initial idea of a scripted logo.  But in the
meantime, this looks like a good alternative to me.
Isn't there an engraver application which has some inkpot-and-feather
logo? Something along this line.


Cheers,
Alexander

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

Re: lilypond authors, release notes, announcements

[Alexander Kobel]

On 2011-01-05 15:17, Reinhold Kainhofer wrote:
 Am Mittwoch, 5. Januar 2011, um 13:33:26 schrieb Graham Percival:
 On Wed, Jan 5, 2011 at 11:58 AM, Federico Bruni fedel...@gmail.com wrote:
 Il giorno mer, 05/01/2011 alle 11.36 +0100, Alexander Kobel ha scritto:
 I tend not to like those assembled logos very much.  Most of the time,
 they end up too clumsy IMHO; more like something quickly hacked
 together, just for the sake of quoting musical symbols.

 You mean something like this? (my 5 minute try, really horrible)

 That looks quite busy to my taste.  My latest 5-minute hack is
 something like this:
 
 Attached is a small modification (created in inkscape rather than lilypond 
 itself). What I really don't like about it is the different slant of the L, 
 the l and the p)...

Huh, that's a good one, kudos!

I personally think the p is just a bit too large; IMHO it should fit to
the same x-height as the neighbor letters.
In smaller size, I also think that the blackness of L and p is extremely
dominant in contrast to the other letters, but this is just from scaling
of the PNG.  Maybe a real markup implementation in Lily would perform
better due to the scaled fonts.
And I'm not too sure about the Music typesetting for everyone.  It's
nicely integrated, and looks very good in a large image.  But if the
logo goes into the tagline, IMHO it should also look acceptable in a
size where the staff lines are at about the same distance as for the
default music staves.  The subscript tagline has certainly less than
1.5 mm height then, and if it's removed, the lower serif of the L gets a
bit too dominant for my taste, too.  So I suppose we'd need this in two
versions, for smaller and larger logos.


Cheers,
Alexander

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

Re: Bug in ties over barlines

[Alexander Kobel]

On 2011-01-31 11:04, Jan Warchoł wrote:
 [...] If the last note in the
 following example doesn't get a natural, it's *impossible* to tell
 that it's not another ces:
 
 ces'1~ | ces'
 ces'1( | c')
 
 It may be argued that the slur looks different than the tie, but it's
 not enough.
 I'm sure that engraving books will agree with me - may someone check this?

Now that I have a brand new copy of Gardner Read's Music Notation in
my bookshelf since just yesterday, I do.  I didn't yet read the whole
book, though...

In the chapter for accidentals (p. 131), it says:
It is not necessary to repeat the accidental before a tied note. The
tie itself serves to prolong the effect of the accidental. The one
exception to this general rule occurs when the note or notes affected by
an accidental and tied over the barline come at the end of a system or
at the bottom of the page.
Which is what we all know.

Regarding slurs, I found exactly nothing.  But I'm absolutely sure, if
Read had written anything about it, it would be: If in doubt whether
the reader will know what to do: make it clear.  Or, rather: Write the
natural, dummy.  He constantly advocates the use of notation that eases
the understanding of the music, and disapproves any elements that are
hardly possible to distinguish or perform.
And this may be an example just too obvious that he felt the need to
comment it.

Not that I know a single instance where this occurs, though.  In a piano
piece that requires a moderately trained player, perhaps I'd leave it
out; but only in the case of chords which are very clear to interpret.
Yet, in any other case, I consider it good style to write the natural
even when there's no slur.  In particular for a single voice, say a
two-note melisma in choral music.
By the way: if you have  { r2.. cis8( | c2!) r2 }  all over the place,
and then there suddenly comes a  { r2 cis2~ | cis2 r2 }, you'd expect an
additional sharp there too, don't you?

Just my two pence...


Cheers,
Alexander

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

Re: Bug in ties over barlines

[Alexander Kobel]

On 2011-01-31 21:06, James Lowe wrote:
 -Original Message-
 From: Alexander Kobel n...@a-kobel.de
 By the way: if you have  { r2.. cis8( | c2!) r2 }  all over the place,
 and then there suddenly comes a  { r2 cis2~ | cis2 r2 }, you'd expect an
 additional sharp there too, don't you?
 
 Hmm...why not use (in your example) { r2.. cis8( | c2?) r2 } which to me
 makes more sense. [...]
 No one (as I can see) has spoken about the ? Vs ! And I think that's the
 difference for me. It depends on what is already sharp/flat in the key
 signature as a musician. ! Means it isn't and ? Means it is but 'be aware'
 right?

Ah, good point. I didn't actually think about the ? vs. ! difference;
probably it's just a matter of personal taste of the engraver.  In this
situation, I guess both can be reasoned: the cautionary since the key
signature says it should be c by default anyway, and the mandatory
accidental (without parentheses) because tie and slur could not be
distinguished otherwise, so it's indeed at least semi-mandatory.
But IMHO the important point here is the fact that the notation can be
ambigous without the accidental, and is definitely clear with it.  No
matter if ? or !.


Cheers,
Alexander

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

Re: Most popular French users request : bar numbering of alternatives

[Alexander Kobel]

On 2011-11-28 09:44, Colin Hall wrote:


On Mon, Nov 28, 2011 at 01:04:06AM +0100, Xavier Scheuer wrote:

Dear LilyPond developers,

Dear Bug Squad members, could you add this enhancement request to
the tracker?  Thanks!

This is by far the most popular enhancement request from the French
users mailing list: Bar numbering of repeat volta _alternatives_.

Currently LilyPond counts the measures of each alternative as
normal, unrepeated, measures hence incrementing the currentBarNumber
in both alternative 1. and 2..  Several references supports what is
actually asked by many users: bar numbering of alternatives should not
be counted twice.


Thanks, Xavier. Added to the tracker as issue 2059:

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


Looks like a duplicate of
  http://code.google.com/p/lilypond/issues/detail?id=785
with some additional links...


Best,
Alexander

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

Re: upgrade to c++11

[Alexander Kobel]

On 07/14/2013 10:41 PM, Frédéric Bron wrote:

I had taken a look previously at CGALURL:http://www.cgal.org/  since
the kind of stuff we are doing with skylines would benefit from
ready-made code like
URL:http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Envelope_2/Chapter_main.html
and frankly, doing things like computational geometry tasks is
a) a resource drain
b) a source for problems


It seems that cgal makes more than boost::geometry that cannot compute
convex hull of curves.


Disclaimer: (By choice of PhD topic and working group,) I'm a CGAL 
developer, though rarely active and if so, then not in one of the 
publicly visible areas.


CGAL is a very neat library if you need robust and exact geometry 
processing. It's complex to set up though (the current workflow requires 
CMake and, for a typical setup, quite a number of dependencies), so I 
don't know how nicely it plays with GUB. OTOH, the hard requirements 
boil down to Boost and GMP+MPFR(+MPFI). There's currently progress on 
even removing GMP as a dependency, but for us GMP licensing is a 
non-issue, and using it makes your CGAL life a lot easier.
For use cases like skylines of segments which mostly deal with linear 
geometry and are very unlikely to hit degenerate cases, CGAL is a very 
heavy hammer. But using it saves you from even thinking about what 
situations can occur, and this code is highly optimized.


If you know a good piece of code to test a migration to CGAL, give me a 
ping, and I'll try to help.



Best,
Alexander

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

Re: Suggestion: Keep original breaks

[Alexander Kobel]

On 11/27/2013 04:32 PM, Urs Liska wrote:

Am 27.11.2013 16:25, schrieb Carl Sorensen:

On 11/27/13 8:04 AM, David Kastrup d...@gnu.org wrote:


Urs Liska u...@openlilylib.org writes:
[...]

originalBreak =
#(define-music-function (parser location)()
   ( #{ \tag #'keep-original-breaks \break #} ))
[...]

If the general case were added, and a special include were included, then
it seems like we'd have both David's wish for keeping things general and
Urs's wish for having an easily-used tool for the specific use case.


For me this sounds good.
Requiring to write \include original-breaks.ly is significantly better
than requiring to define the commands.
But it would still need a separate switch, presumably through the
command line.


I do not want to open a Pandora's box here... Just some thoughts:
Would it be easy to add commandline switches for
 - including files with LilyPond input at the very beginning of the 
compilation unit
 - inserting Lilypond input given as a commandline argument at the 
beginning of the document?
And would it be feasible to have the equivalent of the LaTeX commands 
\providecommand and \renewcommand and/or \if\defined?


I imagine commandlines like the following:
  lilypond --include-first=stylesheet1.ly piece.ly [equivalent to]
  lilypond --input='\include stylesheet1.ly' piece.ly
  lilypond --input='#(set-default-paper-size a5)' \
   --input='#(set-global-staff-size 15.87)' piece.ly
and, eventually,
  lilypond --input='originalBreak = {}' piece.ly
where piece.ly contains an
  \include original-breaks.ly
which uses \providecommand instead of the Urs' above command to define 
\originalBreak. Or you could re-point a tag name to the actual tag which 
will be used in the score.


Even without the \providecommand and \if\defined functionality, this 
looks like a useful feature for commandline control of Lily's output. 
And of course I hope that pretending some lines in front of the actual 
input file should not be too complicated or intrusive to implement?



Best,
Alexander

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

Re: fixing German's Wikipedia entry of LilyPond

[Alexander Kobel]

On 01/13/2014 02:30 PM, Werner LEMBERG wrote:



Which browser?


Firefox 26, Chromium and Konqueror 4.8.5 - also after reload.


Very strange.


Fine here with Chromium (Debian wheezy, v31.something) and Iceweasel 23, 
but the cropped image I made (see below) exhibits the blue 
only-behaviour. Workaround also below.



BTW, how can I make Lilypond crop the SVG, similar to EPS output?


I only know the setting of the paper dimensions beforehand.


Looks like this should be put on the wishlist...


 (fully?) working version below 
inkscape --verb=FitCanvasToDrawing --verb=FileSave --verb=FileClose file.svg

does the job, albeit not from LilyPond.

Also, IIRC not all browsers can deal with SVG fonts very well - maybe 
you should convert to paths? That'd be


inkscape --verb=EditSelectAllInAllLayers --verb=ObjectToPath 
--verb=FitCanvasToDrawing --verb=FileSave --verb=FileClose file.svg


at the expense of an increase of file size by ~30%.


 (fully?) working version here 
This seems to be fine, but no clue why:

inkscape --verb=EditSelectAllInAllLayers --verb=ObjectToPath 
--verb=FileSave --verb=FileClose file.svg

./svgclip.py -o cropped.svg file.svg

where svgclip.py is here: https://github.com/skagedal/svgclip
If text is not rendered to paths first, this moves the tuplet numbers 
around, but with the Inkscape command first, it works.



BTW, I recognized that the SVG contains (local) links to the .ly file; 
did you remember to disable pointAndClick?




Best,
Alexander

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

Re: fixing German's Wikipedia entry of LilyPond

[Alexander Kobel]

On 01/13/2014 02:17 PM, Joram Berger wrote:

On the other hand, the uncropped SVG image

   
http://upload.wikimedia.org/wikipedia/de/archive/4/4d/20140113112433%21Klavierst%C3%BCcke_%28Stockhausen%29_Nr2-Klavierst%C3%BCck2-Anfang.svg

gets displayed fine, while the cropped SVG image

   
http://upload.wikimedia.org/wikipedia/de/4/4d/Klavierst%C3%BCcke_%28Stockhausen%29_Nr2-Klavierst%C3%BCck2-Anfang.svg

(cropping done with Inkscape) exhibits color mistakes in Firefox's SVG
handling.  Sigh.  I thought that displaying SVG images is mature
meanwhile.


Yes, it shows more blue objects than the original, no red.
The article image links to the uncropped image and shows the
corresponding ~A4 aspect ratio. The content however is the cropped one.
The article has not changed, the image has.


Note that (at least for me) objects are blue exactly if they have a 
textedit:///home/wl/stockhausen.ly hyperlink. Could you try to crop the 
same file, compiled with \pointAndClickOff?
Inkscape seems to rewrite the entire document when changing the page 
margins. I suspect that it removes colors for the a tags, Firefox makes 
links blue per default, and the color for the noteheads has no priority 
over that. (Which might be a bug. Or not.)



Best,
Alexander

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

Re: fixing German's Wikipedia entry of LilyPond

[Alexander Kobel]

On 01/13/2014 04:16 PM, Werner LEMBERG wrote:

This seems to be fine, but no clue why:

inkscape --verb=EditSelectAllInAllLayers --verb=ObjectToPath
--verb=FileSave --verb=FileClose file.svg
./svgclip.py -o cropped.svg file.svg

where svgclip.py is here: https://github.com/skagedal/svgclip


I've followed that and uploaded a new version.


BTW, I recognized that the SVG contains (local) links to the .ly file;
did you remember to disable pointAndClick?


This time I did. :-)


Excellent. This also solves the blue-notes issue in Firefox for me, even 
after clipping in Inkscape. So, to summarize for reference:


1.) For cropping,
  inkscape --verb=FitCanvasToDrawing --verb=FileSave --verb=FileClose 
file.svg
works, but has some caveats (probably for non-standard-conforming 
viewers only, including Wikipedia's SVG-to-PNG-converter).


2.a) Firefox in some version(s) draws elements with links in blue if the 
a tag does not specify another color.
2.b) Since Inkscape's FitCanvas rewrites the entire SVG and drops those 
(seemingly superfluous) color attributes, you have to use a different 
route with links: https://github.com/skagedal/svgclip
2.c) svgclip does not handle position of real text properly, hence you 
have to convert to paths first.
  inkscape --verb=EditSelectAllInAllLayers --verb=ObjectToPath 
--verb=FileSave --verb=FileClose file.svg

  ./svgclip.py -o cropped.svg file.svg
That's the only universal variant we have for SVGs with links.

3.) Even without links, real text causes funny positions with 
Wikipedia's PNG thumb renderer [1]. Hence,
  inkscape --verb=EditSelectAllInAllLayers --verb=ObjectToPath 
--verb=FitCanvasToDrawing --verb=FileSave --verb=FileClose file.svg
should be okay for SVGs with \pointAndClickOff, eliminating the need for 
an additional tool.



Correct?


HTH,
Alexander


[1] Compare

https://upload.wikimedia.org/wikipedia/de/thumb/archive/4/4d/20140113150856%21Klavierst%C3%BCcke_%28Stockhausen%29_Nr2-Klavierst%C3%BCck2-Anfang.svg/500px-Klavierst%C3%BCcke_%28Stockhausen%29_Nr2-Klavierst%C3%BCck2-Anfang.svg.png
with text and

https://upload.wikimedia.org/wikipedia/de/thumb/4/4d/Klavierst%C3%BCcke_%28Stockhausen%29_Nr2-Klavierst%C3%BCck2-Anfang.svg/500px-Klavierst%C3%BCcke_%28Stockhausen%29_Nr2-Klavierst%C3%BCck2-Anfang.svg.png
with paths.

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

Re: Changing how a font style is requested

[Alexander Kobel]

Hi all,

since I could not find anything suitable to solve the issue described 
below, I decided to write a little patch.  Please have a look at


https://codereview.appspot.com/108700043

and tell me what you think about it.

[ BTW: This might or might not be entirely orthogonal to the music font 
selection methods which are debated about currently, in the sense that 
the feta font loader is hard-coded and built-in into 
make-pango-font-tree and the proposed make-expert-font-tree.  Sorry, I 
did not follow those discussions in detail; but if you think that's a 
good time to integrate music font selection as well, please go ahead. ]


I could not see a way to achieve what I need in user-level Scheme, since 
add-font is not exposed publicly (and probably for a good reason).  I'm 
happy to take comments on functionality and coding style; I will write a 
bit of documentation in addition to the regtest once (if?) you deem the 
interface acceptable.


I hope goals and syntax are somewhat self-explaining; otherwise, feel 
free to ask for further explanations.  I barely added syntactic sugar 
(except the default font scale 1.0), but I'm willing to reconsider the 
input syntax to make-expert-font-tree if you have any better ideas. 
However, a front-end to it should be much more easy to write, and this 
is doable in user-level code.



Thanks in advance,
Alexander


On 07/11/2014 11:59 AM, Alexander Kobel wrote:

Dear all,

I like to use the Romande ADF font family [1] in one of my scores. I do
the usual rule-of-three with

   \paper { ... (make-pango-font-tree
 Romande ADF No2 Std Romande ADF Std monospace
 (/ myStaffSize 20)) ... }

(If you wonder, No2 is condensed, and the non-condensed version, used in
the headers, is mapped to sans for easy access.)

However, here's the catch: Romande does offer a bold variant, but it
announces it as DemiBold instead of Bold, according to fc-list. I
know that I can switch to the different font each time I need bold, but
that's an utter nuisance.
Is there any way to tell Lily how to choose a bold variant? Bonus points
if it only applies to a specific, say, the serif font. Or, wishlist to
follow, if it is possible to define a mapping similar to

   myserif = { regular: # default
Romande ADF No2 Std:style=Regular,
   bold:# choose way of selecting bold
Romande ADF No2 Std:style=DemiBold,
   italic:  # pretend I don't like Romande's italics
# and need to scale some other font to match
Gentium:style=Italic:scaling=0.93,
   bold-italic: # use small caps family instead
Romande ADF Style Std:style=Regular }
   ...
   \paper { #(define fonts (myserif mysans mymono (/ myStaffSize 20)) }

Obviously, that's not Lily's syntax, but you get the point...


Thanks in advance,
Alexander


[1] http://arkandis.tuxfamily.org/adffonts.html

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



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

Rietveld with Google two-factor authentification

[Alexander Kobel]

Hi all,

does one of you use Google's two-factor authentification thingie?  I 
used it without any trouble on usual apps, but now I'm kind of stuck 
with git cl to commit patches to Rietveld.
AFAICS, the only way to login is via an application-specific password, 
which is an ugly beast not meant for manual input more than once.  My 
usual password is not accepted (which is good), since git-cl does not 
ask for the second-factor token (which is bad).  And obviously git-cl is 
not able to cache the credentials - I get


Could not find stored credentials
  $HOME/.lilypond-project-hosting-login

each time.
What am I missing here?


Best,
Alexander

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

Re: Rietveld with Google two-factor authentification

[Alexander Kobel]

On 07/16/2014 03:58 PM, Graham Percival wrote:

On Wed, Jul 16, 2014 at 03:11:31PM +0200, Alexander Kobel wrote:

My usual password is not accepted (which is good), since
git-cl does not ask for the second-factor token (which is bad).  And
obviously git-cl is not able to cache the credentials - I get

Could not find stored credentials
   $HOME/.lilypond-project-hosting-login
each time.


That is correct, git-cl does no caching, no fancy authentication,
etc.  It attempts to read the above file, and it takes the first
line in that file as the username and the second line in that file
as the password.  That's all it does.


Ah, okay.  That means if I put this application-specific password there, 
I'm done?  Cool.  Now I just need to write some new patch to test...



Patches to git-cl most welcome.  :)


I see... ;-)


I've heard of this two-factor authentication, but I've never
used it (even in my personal life),


I do like the concept a lot, but it's certainly not for everyday tasks - 
if you push 30 patches a day, you don't want to read a token each time. 
 That's what those app-specific passwords are there for; they can be 
revoked independently of each other, and they only apply for specific 
tasks.  E.g., with the Rietveld-only password it is impossible to access 
my calendar.  So while it's still a risk to store it in some potentially 
publicly available place, I don't expose my entire Google profile with 
it.  YMMV.



and git-cl was my first foray into authentication on foreign servers.
I was kind-of expecting that somebody familiar with
python+google+authentication to take 30 minutes (rough estimate for
somebody familiar with the above) to fix it after a few months, but
obviously there's been no takers yet.


I just stumbled across the issue; I'll never did anything 
authentication-related, too, but I'll have a look.



Thanks,
Alexander

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

Re: Next step for easier custom music font switching

[Alexander Kobel]

On 07/20/2014 11:47 AM, Janek Warchoł wrote:

2014-07-19 16:48 GMT+02:00 tisimst tisi...@gmail.com:

- Question 1: *Should the new syntax be something like this?* (where the
music and piano-brace fonts are put at the first)

\paper {
   #(define fonts
 (make-pango-font-tree
 *lilyjazz*  ; music font
 *gonville*  ; piano brace font
 FreeSerif
 FreeSans
 Inconsolata
 (/ staff-height pt 20)))
}


I agree with David's comment here.
Btw, just to make sure: have you seen
https://code.google.com/p/lilypond/issues/detail?id=4014 ?


Hi all,

and Janek: thanks for the ping...  I'm currently travelling, I won't 
have too much internet access for the next week or so, and then again 
just for a few days til vacation starts.  In other words, don't expect 
much time from me until mid-August.
@all: feel free to modify the make-expert-font-tree as you think it fits 
if you want to!
I think if the make-expert-font-tree makes it into master at some point 
in some variant, it would be worth to check whether we should have this 
as the backend for make-pango-font-tree.



Best,
Alexander

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

Re: Next step for easier custom music font switching

[Alexander Kobel]

On 07/22/2014 02:58 PM, Urs Liska wrote:

On 22. Juli 2014 07:51:00 MESZ, James pkx1...@gmail.com wrote:

On 21/07/14 09:46, Alexander Kobel wrote:

On 07/20/2014 11:47 AM, Janek Warchoł wrote:

Btw, just to make sure: have you seen
https://code.google.com/p/lilypond/issues/detail?id=4014 ?


Janek: thanks for the ping...  I'm currently travelling, I won't
have too much internet access for the next week or so, and then again
just for a few days til vacation starts.  In other words, don't
expect much time from me until mid-August.


So does that mean this patch 'needs work' now?

It's currently on countdown (I'm the owner/patch-shepherd as Alexander
doesn't have commit access).


IISC it does _not_ mean to postpone it, quite the contrary.


Yes and no.  It does not necessarily mean to postpone the feature, but 
my intention for the announcement of the patch in its current shape was 
threefold:


a) (ACHIEVED.)
I needed the feature, right now.  Well, turned out I didn't, but I 
thought I do.


b) (ACHIEVED.)
I wanted to have a draft ready before some interface for the music font 
changing is settled, because we might want to do both in one shot.


c) (TODO)
I hoped for a small comment or two about the (informal) interface 
proposal (by example).  I do intend to write a piece of documentation 
about it, because I feel that already make-pango-font-tree is not as 
accessible for people which are not familiar with the Linux-/LaTeX-style 
{roman,sans,monospace}-default-definition idea.  I might be mistaken, 
though.  On the other hand, I actually don't know if it is correct when 
I say: the Pango description string for the font, which is passed as-is 
to the Pango interface.  Is this Pango?  Is it fontconfig?  Is it 
correct that `fc-match string` will tell me what 
`(make-expert-font-tree '((... string)) ...)' will do, or almost, but 
not quite?  I'm kinda lost there myself.



The last one is the big TODO, and the reason why I'm also fine with 
postponing it.  And I don't want to have it in master unless it's 
reasonably unlikely that the interface (let's say the format of 
font-spec-list) will change within a few days.



BTW: I think it's strange that Century Schoolbook is taken as the 
default, while sans is left to the environment.  Is that because there 
was no need for a sans or mono font with built-in features before chords 
and the tagline were introduced?  Or because there was no agreement on a 
good (quality/liberty/freedom) font?



Best,
Alexander

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

Re: Next step for easier custom music font switching

[Alexander Kobel]

On 07/24/2014 01:08 AM, Alexander Kobel wrote:

https://code.google.com/p/lilypond/issues/detail?id=4014 ?


On the other hand, I actually don't know if it is correct when
I say: the Pango description string for the font, which is passed as-is
to the Pango interface.  Is this Pango?  Is it fontconfig?  Is it
correct that `fc-match string` will tell me what
`(make-expert-font-tree '((... string)) ...)' will do, or almost, but
not quite?  I'm kinda lost there myself.


Oh, and I forgot one:
Is it an expected and supported behaviour that I'm allowed to 
advertise that you can introduce new lily-family symbols ('markup and 
'condensed in the example, but I could think of, e.g., 'lyrics, 'header, 
'chords or 'mark to be useful)?  Or is it rather an unexpected feature 
(aka. bug) that might vanish at some point?  I assume that it's safe to 
use, but I'm not sure.
And if yes, should we also implement a mapping between logical and 
physical lily-families (similar to structural markup vs. direct markup 
in Latex or HTML)?  Like, per default,

  'lyrics - 'roman
  'header - 'roman
  'chords - 'sans
  'url- 'typewriter
and the user may add a 'condensed family and re-map 'lyrics to 
'condensed.  Or is this overkill, and we should stick to the one-layer 
strategy we already have?



Best,
Alexander

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

Re: Add an expert font tree interface (issue 108700043 by perpeduumimmob...@gmail.com)

[Alexander Kobel]

On 07/25/2014 05:55 AM, markpole...@gmail.com wrote:

https://codereview.appspot.com/108700043/diff/80001/input/regression/font-expert-selection.ly


Mark, thanks for the comments.  James, give this at least one more 
cycle, please.  I'll incorporate the changes as soon as I can find the 
time, and want to double-check the entire patchset again - hopefully 
I'll have more time available next week.



Best,
Alexander

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

Re: Text and music font handling

[Alexander Kobel]

On 07/26/2014 09:30 AM, Urs Liska wrote:

Hi Abraham and Alexander,

I'm slightly losing track of the font selection discussions that happen
in parallel currently.
Are you actually in touch with each other? I'd be really sorry if either
of your development wouldn't make it into LilyPond because of a lack of
communication.


Hi Urs, hi Abraham,

don't worry, it'll end up in LilyPond at some point.  But I have to 
admit that I did not have a look at Abraham's work other than skimming 
over the newest PDFs.  I was travelling, and also will be on vacation 
from Sunday for a week.  As soon as I'm back again, I will push myself 
to polish up and see how we can integrate our work.


By the way, Abraham: IIRC, you asked about how to prepare a patch for 
review.  I'm not an expert in that, but it looks like I did so 
successfully; so if you can wait for another 10 days or so, feel free to 
contact me and I'll do what is necessary.  Or take the offer by other 
friendly helpers.



Regarding the music font selection:
My uneasy feeling about breakinge existing code is surely invalid
because convert-ly will handle that easily.


That's good to hear.  I'm not familiar enough with convert-ly, but I 
agree that if we come up with a somewhat sane approach for choosing the 
fonts, it should not be too hard to concoct a rule which will do the job.



What I'm still not completely happy with is the fact that one has to
always specify all five fonts, even when one only wants to change the
roman font or the music font.


+1.  It's on my TODO list.  I consider this as syntactic sugar over the 
current make-pango-font-tree and make-expert-font-tree, but I totally 
agree that this should be integrated.  Won't be difficult, I just need 
to figure out how to modify the currently active font tree in place.



It would be awesome if you could think of an infrastructure that
separates the internal work and the user interface so that one could
either have a function using, say, named arguments with default values
or have different functions depending on what you want to change.


Ditto.


Best,
Alexander

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

default text-font-size

[Alexander Kobel]

Hi all,

can anyone explain me why both numbers 11 and 12 (as in 11pt and 12pt) 
appear in the implementation of add-pango-fonts (scm/font.scm, lines 
208, 219 and 224)?  Also, what should be and/or is the default font size 
for lyrics? Is it really 12 pt as indicated by Mark in

  http://comments.gmane.org/gmane.comp.gnu.lilypond.general/94814
I'm not sure if there is a minor bug (only conceptually behind the 
scenes; I'm pretty sure it does not impair the output).


I have an idea, but I don't want to spoil an explanation with my guess. 
 Can someone have a look?



TIA,
Alexander

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

Re: See the new music fonts in action

[Alexander Kobel]

On 08/01/2014 09:46 PM, Abraham Lee wrote:

On Thu, Jul 31, 2014 at 12:07 PM, Urs Liska u...@openlilylib.org wrote:

Or send me the latest version of the file. Urs


Urs,

Here's the newest version of font.scm. I decided to create my own
function after all so that make-pango-font-tree (at least from the
user's perspective) follows the same syntax, it is only changed under
the covers. I'm sure this will trip people up, though, so we'll need to
discuss an appropriate solution for that. It doesn't make much sense to
me to have all these different functions available that all kind of do
the same thing, but behave slightly different from each other. That will
only confuse people.

The function add-music-fonts still needs to be modified for all this
to work.

I call my function (drum roll, please...): set-global-fonts. It's
different in that ALL the font choices are optional, keyword arguments.


Abraham, Urs,

that's great.  Again, not much time now, but I had a quick look and it 
seems that this is not only a perfectly clean approach, but also that I 
can integrate the new text font selection easily.
The only part I want to figure out is whether it is possible to change 
the font tree after initial setting, so that a user can write his own 
stylesheet commands for different music fonts, header fonts, lyric fonts 
etc. and plug them together without rewriting the entire command set for 
each and every combination of fonts.  Maybe it suffices to simply expose 
add-*-fonts or add-*-node to the public and/or give corresponding 
replace-or-add functions.



Thus, if I only want to change the notation font, that's all I need to
specify. Here's a minimal example showing all the optional, keyword
arguments (and you can't just put in the string values! They MUST be
preceded by the key identifier, but any and all can be omitted):

\version 2.18.2
\include english.ly

\paper {
   #(define fonts
  (set-global-fonts
   #:music lilyjazz
   #:brace gonville
   #:roman lilyjazztext
   #:sans FreeSans
   #:typewriter Inconsolata
   #:factor 1 ; should this EVER NOT be 1?
))
}


factor is relevant if you set the global staff size to something 
different than 20, the default.  The usual rule-of-tree used to be 
something like

  myStaffSize = #17.82
  #(set-global-staff-size myStaffSize)
  #(define fonts (make-pango-font-tree ... (/ myStaffSize 20)))

BTW, I never really understood whether it is technically possible to 
automatically figure out factor at the point where 
make-pango-font-tree is called?  If not, why?  And if yes, is there any 
reason why it is not done?



Best,
Alexander

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

Re: See the new music fonts in action

[Alexander Kobel]

On 08/02/2014 09:00 AM, David Kastrup wrote:

Abraham Lee tisimst.lilyp...@gmail.com writes:


On Fri, Aug 1, 2014 at 3:51 PM, Alexander Kobel n...@a-kobel.de wrote:


BTW, I never really understood whether it is technically possible to
automatically figure out factor at the point where
make-pango-font-tree is called?  If not, why?  And if yes, is there
any reason why it is not done?


Ah, yes. I knew there was a reason for the syntax (/ staff-height pt
20) or its equivalent. I just tried to play around with
make-pango-font-tree and I couldn't seem to figure out how to
reference the staff-height variable within this function.

David Kastrup? Anyone? Any ideas?


Well, looking at the definition of set-global-staff-size would seem to
indicate how the size is being set.  I suspect that calculating the
relevant module in that manner and then looking up output-scale in it
might do the trick.  But I haven't really understood the output scale
business anyway.  It's not clear to me how it works in every
circumstance.


That's not quite what I wanted to hear...  If /you/ say that, it makes 
me wonder whether a) the entire business is seriously broken by design 
or b) it's waaay above what I'll ever understand.
I agree that looking up the relevant module seems to be the missing 
link.  Anyway, I'll have a look after Aug, 10.



Best,
Alexander

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

Re: Sans-serif free Unicode font (was Re: Ghostscript 9.15)

[Alexander Kobel]

On 03/25/2015 06:58 PM, Carl Sorensen wrote:

On 3/25/15 6:54 AM, u...@openlilylib.org u...@openlilylib.org wrote:


I think the fonts we're looking for should have a similarly classic or
old-fashioned look as Century.

Maybe we should look for fonts that (optionally) ship with texlive.

[...]
I think that the following show some promise:

Alegreya Sans


+1. The entire Alegreya family (also the serif) is beautiful, is not too 
wasteful with horizontal space, and comes with a large set of variants 
(including proper small capitals). I like it a lot in scores.


Another font I used is Optima. It's almost overused, it's not a strict 
sans-serif in my opinion, because the varying widths of the strokes give 
the impression fake serifs to some degree, but it's beautiful. And 
with MgOpen Cosmetica, URW Classico (one of GS default fonts) and Linux 
Biolinum, there are a number of high-quality free siblings.


W.r.t. a monospace font, the M+ font collection comes to my mind. It has 
some nice families which look good in print, too. It's a large 
collection, but e.g. M+1m or M+2m should be enough. (Although the latter 
has a pretty unique character with it's g glyph; not sure if that fits 
overall.)



Just my 2 pence,
Alexander

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

Re: Understanding and modifying font nodes

[Alexander Kobel]

On 2015-04-26 01:05, Urs Liska wrote:

I have wrapped around about anything I could think of, but I'm stuck and
would greatly benefit of some help now.

I'm working on the font interface and will (hopefully soon) present a
patch that may improve font handling (with the new alternative fonts
provided by Abraham) significantly. The last big obstacle is modifying
the add-font procedure in font.scm to an add-or-replace-font
behaviour. The idea is removing the annoying limitation that fonts can
only be set once and not reset. In order to change anything one has to
recreate the complete font-tree.


Hi Urs,

I agree that this is highly cumbersome. Not that it helps, but let me 
remark that some time ago I tried to achieve the same, and have not been 
successful.


On a different note, at least it looks as if by now we can remove that 
annoying manual font scaling for non-default global staff sizes by setting

  (/ (* staff-height pt) 2.5)
as a default factor. This remedies one of the potential user problems.


It boils down that I simply don't understand what's going on inside the
font nodes and how many of them are processed in the iterations,
regardless how much debug printing I use to get to grips with it.


+1 from me... :-/


Best,
Alexander

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

Re: Spare SSD anybody?

[Alexander Kobel]

On 2016-06-01 11:07, David Kastrup wrote:

David Kastrup  writes:


Hi,

my current development SSD, graciously donated by James, currently has
the following readings:

Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  UPDATED  
WHEN_FAILED RAW_VALUE
   5 Reallocated_Sector_Ct   0x0033   099   099   ---Pre-fail  Always   
-   13
   9 Power_On_Hours  0x0032   094   094   ---Old_age   Always   
-   25748


Ok, I might have been panicking because of all the lines with "Pre-fail"
and "Old_age" but they only indicate the _category_ of the respective
settings.  Sorry for that.

I'm still trying to figure out the readings as such though.  The
"documentation" including online is not much help.


Hi David,

recently I was afraid about my SSD for the same reason, so I asked our 
institute's IT service staff who cares for some dozens (hundreds?) of 
laptops and desktops with SSDs.


They say that even power users of hibernation with high rate of data 
turnover didn't manage to damage their SSDs lately; the horror stories 
for the first generations of SSDs seem not to apply anymore. You still 
have to take a bit of care (try to have some empty space, and run fstrim 
once in a while), but other than that you should be fine.
As you experienced, the SMART information is rather unhelpful unless you 
have additional context by the manufacturer; more often than not, the 
only semi-reliable source are the manufacturer's own toolkits (which, 
unfortunately, are hardly available on Linux).


However, there have been a few reports in the past about shaky power 
supply for the disks, probably when laptop batteries grow older. Some 
SSDs cope with that without problems, others are very sensitive to 
voltage differences (?) and suddenly become unstable. Signs of this 
behavior are ATA warning messages concerning the "ATA interface" in 
dmesg output, such as those:

  https://lime-technology.com/wiki/index.php/The_Analysis_of_Drive_Issues
Quote: "There have been too many cases of drives thrown out or returned 
by an RMA process, when the problem was just a bad cable!" - which 
exactly matches the experience of our IT.
If drives barf out for those reason, they have always been able to copy 
the contents with an external adapter - annoying, but not dangerous.



That being said: which form factor/connector do you need? I can ask if I 
can grab something. Many parts from few-year old machines are sorted out 
regularly here. Not sure about hard disks, though - there might be 
regulations for data protection that prevent them from giving out old 
drives.



Cheers,
Alexander

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

Re: Fun with upgrades - not

[Alexander Kobel]

On 2016-07-08 14:11, Phil Holmes wrote:

Problem 2: running configure:

ERROR: Please install required programs: /usr/local/bin/fontforge >=
20110222 (installed: )

See INSTALL.txt for more information on how to build LilyPond
phil@ubuntu12:~/lilypond-git/build$ fontforge --version
bash: /usr/local/bin/fontforge: cannot execute binary file: Exec
format error


What does

   file /usr/local/bin/fontforge

state?  This sounds like you are trying to run a 64bit executable on a
32bit kernel, or a 32bit executable on a system unequipped to do so
(missing essential libraries and loaders).  Or even have a complete
mismatch of architecture.


Looks right:

phil@ubuntu12:~/lilypond-git$ file /usr/local/bin/fontforge
/usr/local/bin/fontforge: ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15,
BuildID[sha1]=1c01d759ac10c3f83d000f8e3d36cbea63f909e5, not stripped

It's 32 bit OS.  Any idea how to replace it with a 32 bit version?


I guess you should just get rid of it; the version from the repositories 
should be recent enough. Just make sure that /usr/bin/fontforge is used 
instead of this one.
If you still have the directory from which this installation was built, 
a `sudo make install` from that folder should do whatever is necessary.



HTH,
Alexander

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

Re: Fun with upgrades - not

[Alexander Kobel]

On 2016-07-08 14:31, David Kastrup wrote:

Alexander Kobel <a-ko...@a-kobel.de> writes:


phil@ubuntu12:~/lilypond-git$ file /usr/local/bin/fontforge
/usr/local/bin/fontforge: ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15,
BuildID[sha1]=1c01d759ac10c3f83d000f8e3d36cbea63f909e5, not stripped

It's 32 bit OS.  Any idea how to replace it with a 32 bit version?


I guess you should just get rid of it; the version from the
repositories should be recent enough. Just make sure that
/usr/bin/fontforge is used instead of this one.
If you still have the directory from which this installation was
built, a `sudo make install` from that folder should do whatever is
necessary.


 sudo make uninstall

you mean.


Oops, of course. Good catch... ;-)

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

Re: Fun with upgrades - not

[Alexander Kobel]

On 2016-07-08 14:14, David Kastrup wrote:

Alexander Kobel <a-ko...@a-kobel.de> writes:


On 2016-07-08 13:44, Phil Holmes wrote:

  [...]

Last week I decided to bite the bullet and upgrade from Ubuntu 10.04
to a more recent version. [...]

sudo apt-get build-dep lilypond


Did this, thanks, and now have the following problems.


Hi Phil,

I'm trying to give pointers without having access to the same
environment, so bear with me if they turn out misleading.


Problem 1:

phil@ubuntu12:~/lilypond-git$ sh autogen.sh --noconfigure
processing .
Running autoconf ...
autogen.sh: 17: autogen.sh: autoconf: not found


Hm. Sounds like autoconf is not installed; it's not listed explicitly
in the build dependencies in the Debian package either, so that's
probably an oversight by the package maintainer.


autoconf is not normally a requirement when building from a tarball
which usually contains the autoconf-generated files.  autoconf is only
needed for building directly from a repository checkout.  I don't think
that Debian usually does that.


I see. So IIUC, the build-dep target will give you whatever tools are 
necessary to rebuild the contents of the official package locally, which 
might be different from what you want for a custom compilation from source?



Thanks,
Alexander

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

Re: Fun with upgrades - not

[Alexander Kobel]

On 2016-07-08 13:44, Phil Holmes wrote:

 [...]

Last week I decided to bite the bullet and upgrade from Ubuntu 10.04
to a more recent version. [...]

sudo apt-get build-dep lilypond


Did this, thanks, and now have the following problems.


Hi Phil,

I'm trying to give pointers without having access to the same 
environment, so bear with me if they turn out misleading.



Problem 1:

phil@ubuntu12:~/lilypond-git$ sh autogen.sh --noconfigure
processing .
Running autoconf ...
autogen.sh: 17: autogen.sh: autoconf: not found


Hm. Sounds like autoconf is not installed; it's not listed explicitly in 
the build dependencies in the Debian package either, so that's probably 
an oversight by the package maintainer.
`dpkg -l autoconf` should tell you whether this is the reason; `sudo 
apt-get install autoconf` should solve it.



Problem 2: running configure:

ERROR: Please install required programs: /usr/local/bin/fontforge >=
20110222 (installed: )

See INSTALL.txt for more information on how to build LilyPond
phil@ubuntu12:~/lilypond-git/build$ fontforge --version
bash: /usr/local/bin/fontforge: cannot execute binary file: Exec format
error
phil@ubuntu12:~/lilypond-git/build$ sudo apt-get install fontforge
Reading package lists... Done
Building dependency tree
Reading state information... Done
fontforge is already the newest version.
0 to upgrade, 0 to newly install, 0 to remove and 6 not to upgrade.

Any suggestions?


Looks like the configure script found a fontforge in /usr/local/bin, 
which it seems to prefer over the "official" one which should be 
installed in /usr/bin.
Unfortunately, the latter seems to be compiled for a different 
architecture. Could you give the output of the following commands:


  # This will show what your system is running
  uname -a
  # This will show what the custom fontforge is compiled for
  file /usr/local/bin/fontforge

I guess those values will not match. Also, could you post the output of 
`echo $PATH`? I presume it will contain "/usr/local/bin" quite early, 
which will make binaries there the preferred choice over ones in /usr/bin.
If you do not need that preference, you could try to edit ~/.bashrc 
(most probably) and adjust the setting of PATH there; otherwise, you 
will probably have to uninstall the custom fontforge. The ugly way is to 
`rm /usr/local/bin/fontforge`, but it will be better to find out how it 
got there, and look for something like a `make uninstall` in the source 
tree of fontforge.



HTH,
Alexander

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

Re: Fun with upgrades - not

[Alexander Kobel]

Hi Phil,

I had a bit of trouble to parse your setup description. IIUC, you used 
to have a machine with


- Ubuntu 10.04 running natively as host
  - VirtualBox environment on this one
- LilyDev/Ubuntu 12.04 VM
- Windows Vista VM
- Windows 7 VM

and want to go to

- Ubuntu 14.04. running natively as host
  - VirtualBox environment on this one
- possibly a LilyDev/Ubuntu 12.04 VM ?
- Windows Vista VM
- Windows 7 VM

Correct? Or will you just install a Win7 on your shiny new piece of 
hardware and keep Ubuntu on the old one?


W.r.t. the mountpoints, have a look at

http://askubuntu.com/questions/336518/why-has-ubuntu-moved-the-default-mount-points#336580
for an explanation and

http://askubuntu.com/questions/214646/how-to-configure-the-default-automount-location/276670#276670
for a way to go back to the pre-10.10-behavior (untested though, I'm 
quite happy with the new behavior on Arch Linux here).
That different users cannot access the drive with the new default is the 
intended feature, not a bug, though it might come unexpected.


For a quick-and-dirty solution, you can check whether symlinks (con: not 
a "proper" directory; pro: simple and persistent over reboots) or 
bind-mounts (pro: proper directory; con: more difficult to setup, in 
particular if you want them for automounted drives) serve the same 
purpose. Also, mounting a device multiple times as Wol suggested is no 
problem at all.



As far as GUB is concerned, I have no idea, sorry - never used that. 
However, compiling Lily natively on my platform (whether Arch, Debian or 
Ubuntu) always worked like a charm for me, using all the build 
dependencies from the repositories, so I'd strongly suggest to at least 
give it a shot. However, my last proper use of Ubuntu was around 2013; 
I'm not sure if there are build dependencies for recent LilyPond that 
cannot be satisfied from 14.04s upstream repositories.

Is there a specific reason why you don't want to go to 16.04 directly?


Finding out why the VM became slow sounds difficult. I am a VirtualBox 
user, too, but never experienced severe problems - on the other hand, I 
basically use it once a year for the tax declaration, and even less 
often to buy sheet music on sites which ship Scorch files. In contrast, 
Lightroom sounds like an application that might be interested in direct 
access to the graphics hardware. I assume that there comes a newer 
VirtualBox with 14.04 than the one on 10.04; I suggest to double-check 
whether there is a setting that enables or disables GPU support and/or 
PCI passthrough. The explanations here


https://blogs.oracle.com/fatbloke/entry/3d_acceleration_with_ubuntu_guests
might still be valid (don't miss out on the vboxvideo module part, could 
be important...).



HTH,
Alexander


On 2016-06-28 16:50, Phil Holmes wrote:

Last week I decided to bite the bullet and upgrade from Ubuntu 10.04 to a
more recent version.  I downloaded an upgrade to 12.04, and then used that
to do an online upgrade to 14.04.  As a result of this, I lost most of the
applications needed to build LilyPond.  I've grabbed a number of then with
the software installer or apt, but gave that up for a while whilst I
needed the machine for another purpose.

This was to run a Windows 7 VM - I use this with Adobe Lightroom 6 (which
won't run on my Vista desktop) for editing my photos.  So I installed the
latest Oracle VirtualBox and discovered that 14.04 mounts its disks in
media/username, meaning that VB could not find the image of my VM.  I
hacked the set up file by hand, and got the VM running.  Problem is, it
runs like a complete drain, taking about two minutes to move between
photos.  The VM on 10.04 was instantaneous.  No idea why this should be,
but I got so p**sed of with it that I've ordered a new PC just for my
photography.

So I'm back to thinking about what to do with the Linux installation.  An
option would be to start from scratch with the latest version of LilyDev.
My concern is how this would mount my two non-system disks: a 2TB hard
drive and an SSD.  With 14.04, if I access my SSD from my "patchy" user,
my mail "phil" uer can't see the drive since it seems to mount at
media/patchy.  I'm also not sure how I would best go about GUB builds.
Previously I had a 64 bit Ubuntu 12.04 VM running on the 10.04 machine
from a "gub" user.  Not sure whether it would be best to save the VM image
and try to transfer it to the new build, or forget about it and start from
scratch again.  Also not sure whether GUB will run OK just on the base
LilyDev build, rather than in a VM?  I'm concerned that if Windows is so
slow on a VM on 14.04, perhaps the GUB Linux will have the same problem?

Advice from anyone who knows what they're talking about even slightly
would be welcome.


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




___

Re: Back in the Pond

[Alexander Kobel]

Hi David,

On 2017-01-19 12:59, Trevor Daniels wrote:

David, you wrote Thursday, January 19, 2017 10:18 AM


it would appear that my excursion into a regular workplace ended up

somewhat shortlived.

Really sorry to hear that, but it's great to have you back!


Ditto.  I wish that you would have had better luck with that endeavor...


So for the short time range, I am again dependent
on support by other LilyPond lovers.


I'll definitely turn on my financial contribution again.


Ditto, although it's just a drop in a mostly empty bucket...


So what's next on my agenda?
[...]
And, of course, this is an opportunity to try putting out the 2.20
release finally.


Definitely the top priority, IMO.


+1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" { ... } 
has the potential to be a killer feature w.r.t. usability for choir 
literature (especially combined with the upcoming automatic extenders). 
Unfortunately, assignment of lyrics to *container* contexts does not 
work (at least, not reliably), and extender generation is completely 
defunct. I reported that in a thread from 2016-12-26 on bug-lilypond, 
but could not motivate any supporters yet.


I saw a comment by you that you are aware of the issue; can't remember 
where, it was at some point during my (unsuccessful) debugging streak 
for the problem - might well be a very old comment in the issue tracker 
or a commit message or the like.  May I kindly ask you to have a look 
and think about whether this might be tackleable before 2.20?  I have no 
good intuition for the complexity of this issue; the *specification* 
part should be reasonably simple (which syllable corresponds to which 
note(s)), but I don't know what kind of difficulties the current design 
presents for actually coding it.



Cheers,
Alexander

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

Re: Back in the Pond

[Alexander Kobel]

Hi (almost) everybory (dropping -user)!

On 2017-01-20 10:20, Knut Petersen wrote:
> Hi everybody!
> 
>>> +1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
>>> ... } has the potential to be a killer feature w.r.t. usability for
>>> choir literature (especially combined with the upcoming automatic
>>> extenders). Unfortunately, assignment of lyrics to *container*
>>> contexts does not work (at least, not reliably), and extender
>>> generation is completely defunct.
>> Uh, I thought that people replaced extenders right now?
> Well, may I cite the notation manual:
> 
> "extender lines cannot be drawn when there is no associated voice."
> 
> The autoextender patch only adds extenders at places where extenders can be 
> added without it.

Good catch. From what I spotted, the missing piece is indeed the association 
between lyrics and voices. Note that it's not just extenders that are broken: 
I'm not entirely confident whether the lyrics placement is what it is supposed 
to be, in case there are different rhythms within a container context and 
outside. At least IIUC the searchForVoice and associatedVoice{,Type,Context} 
properties.

As soon as there is an associated voice (e.g., through the searchForVoice 
algorithm), extenders /are/ drawn. The problem with that approach: AFAICS it is 
not possible to restrict the search to a certain context. E.g., for 
ChoirStaves, you'd only want the search to extend to Voices that are 
(currently) printed on some Staff that is part of the ChoirStaff.
For scores that only consist of one ChoirStaff, the workaround I gave in the 
other thread actually works.

IIUC, the melisma translator you are talking about would ensure that moments 
are skipped where all candidate associated voices have melisma_busy? That's 
another useful feature, obviously, but AFAICS the lyric-voice-correspondence 
should be somewhat independent.
Anyway, I'll stop handwaving and speculating here without a good cause. If you 
want me to proceed, you know where to find me...

> Prior to Alexanders bugreport I wasn't even aware that something like 
> \lyricsto ChoirStaff ... could work.
> If we get it to work it might be a good idea to document the feature in the 
> notation manual.

Yes. In fact, Trevor already mentioned that he will at least modify the SATB 
template to use that feature and document it there. But obviously, once 
everything is reliable, NR 2.1.2 "Polyphony with shared lyrics" could be 
simplified drastically, with the current docs merely an emergency or special 
purpose option...

>>> I reported that in a thread from 2016-12-26 on bug-lilypond, but could
>>> not motivate any supporters yet.
> 
> I verified that the changes made by the autoextender patch are unrelated
> but decided that probably the person who added the feature is the most
> obvious candidate to fix it ;-)

To make sure: this wasn't a complaint about lack of interest from my side. And 
yes, I also double-checked that the auto extenders aren't the culprit...

> Currently I work on  LyricHyphen enhancements. After I know if the 
> autoextender
> patch will be accepted I'll send a patch that will implement the following 
> features: [...]

Whoo! Nice!


Cheers,
Alexander

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

Re: Back in the Pond

[Alexander Kobel]

On 2017-01-20 10:46, David Kastrup wrote:
> Knut Petersen  writes:
> 
>> Hi everybody!
>>
 +1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
 ... } has the potential to be a killer feature w.r.t. usability for
 choir literature (especially combined with the upcoming automatic
 extenders). Unfortunately, assignment of lyrics to *container*
 contexts does not work (at least, not reliably), and extender
 generation is completely defunct.
>>> Uh, I thought that people replaced extenders right now?
>> Well, may I cite the notation manual:
>>
>> "extender lines cannot be drawn when there is no associated voice."
>>
>> The autoextender patch only adds extenders at places where extenders
>> can be added without it.
> 
> That does not sound like we should remove __ from lyrics to me.

That already proved to be a source of endless misinterpretations, so be careful 
to complain... ;-)

Two-line summary:
1. (What used to be) __ is added *everywhere.*
2. *Processing (printing)* of LyricExtenders changed such that only the 
extenders you expect to appear are drawn by default.

Because of 1. it would be rather surprising if the need arises to add it 
manually ever again, and thus it should be safe to deprecate and ignore the 
token.
W.r.t. 2., I think all reasonable use cases are covered. If, however, you have 
any example of lyrics without associated voice, where extenders are required 
and working with the old __, please raise your voice now. I can't imagine that. 
(BTW, this has absolutely nothing to do with the \lyricsto ... = ... { ... } 
issue per se. It's just that both are a tremendous simplification for choral 
scores.)


Cheers,
Alexander

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

Re: Stepping down and moving on

[Alexander Kobel]

Dear David,

my sincere thanks for your past and ongoing work and dedication for 
Lilypond (and other FOSS, by the way). We are well aware that our 
donations could not sustain you in the long run. As always in such 
situations, it's a pity for the community to hear that an important 
member of the dev team has to move on, but I guess we all do understand 
your reasons and support your decision. Actually, I'm surprised that you 
managed to tolerate the status quo for so long, and I'm glad that you 
seem to have found an apt employment. Good luck with the commuting, 
though...


On a personal note: I think you are too pessimistic about your abilities 
in leading and managing. I've only scratched the varnish of the very 
surface of Lilypond's development, but I silently followed many 
conversations. I doubt that any different attitude or communication 
style would have led to any "more successful" outcome in recruiting or 
motivating. I've seen many sincere discussions in rough tones, including 
ones about your opinions and personality, but in the end I can't 
remember many occasions when other developers did not eventually 
appreciate the fact that issues were discussed openly. And I've never 
felt doubts by anyone about your dedication and motivation for the 
common goal, despite of disagreements in the execution.
There is no team working together over such a long time without 
discussions, disputes and arguments - the art is settling them, and 
approaching new tasks (and the same people) with an open mind. When I 
remember the few pictures I saw from the personal developer meetings at 
your place, I feel that you are way better in social affairs than you 
might think. And I'll miss your humor on those lists...



All the best in your future endeavors!


Thanks again,
Alexander

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

David's pearls [was: [GSoC] Implement cross-voice dynamic spanners (issue 304160043 by starry...@gmail.com)]

[Alexander Kobel]

David,

while I did not read the entire mail, I just happened to stumble across 
this comment - made my day!


On 2016-10-21 15:22, d...@gnu.org wrote:

lily/include/engraver-group.hh:56: friend class Spanner_engraver;

What is the friendship needed for in particular?  When it's not too much
effort, it is nice to get along without friends, but if one does lean on
them, it makes sense keeping book on what you need them for.

This is not life advice.


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

Re: music function to be included somewhere in scm/*

[Alexander Kobel]

Hi Knut, hi all.

On 2016-12-14 10:16, Knut Petersen wrote:

Hi everybody!

There is a discussion on lilypond-user with the target to allow
automated lyric extenders to lilypond. One part of that is a patch
to clean and extend lyric_extender.cc.


Knut is playing down his work here. The crucial point: with his patch, 
there is no harm in adding lyric extenders everywhere, because they will 
not produce any output on non-melismata (unless overriden specifically). 
Also, the handling of extender's minimum-length is cleaned up.



To allow automated creation of lyric extenders a helper function is
needed


... that does exactly this, adding extenders everywhere.

IMHO, the actual question to decide upon is: Do we want this to be 
enabled by default? IIUC, the fact that extenders are not automatic is a 
known shortcoming. NR 2.1.1 states under "Known issues and warnings":
"Extender lines under melismata are not created automatically; they must 
be inserted manually with a double underscore." (see 
http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-vocal-music#multiple-notes-to-one-syllable)


With Knut's patch, this will mostly impact scores where extenders are 
left out unintentionally. Still, it will be a burden for convert-ly 
unless we have a global (or per lyric definition) \noAutomaticExtender 
rule that is inserted by default.


On the other hand, there is the chance to get rid of scores where users 
don't add extenders simply because they are not aware of their 
importance or the proper syntax.




Putting the
following code into a lilypond score does the job:

#(define autoextenders (define-music-function (lyrics) (ly:music?)
   (music-map
 (lambda (event)
   (if (and (eq? (ly:music-property event 'name) 'LyricEvent)
  (not (let* ((art (ly:music-property event 'articulations))
  (is-hyphen? (lambda (ev) (eq? (ly:music-property
ev 'name) 'HyphenEvent
   (find is-hyphen? art)))
  (not (string=? (ly:music-property event 'text) " ")))
  (ly:music-set-property! event 'articulations
 (append (ly:music-property event 'articulations) (list
(make-music (quote ExtenderEvent) event )
 event)
   lyrics)))

Q1: Where should a definition of \autoextenders reside?
scm/music-functions.scm?


AFAICS: yes.


Q2: Obviously the definition of \autoextenders does not match the coding
style used in scm/*. It does not even
work if it is added to music-functions.scm. Some advice is needed ...
the extending-manual is not a real help in
this case.


I think you mixed up define-music-function and a plain Scheme define.
IIUC, define-music-function creates an anonymous function with some 
syntactic sugar (e.g., type-checking of the additional arguments past 
parser and location) which is then assigned to a variable:


function = #(define-music-function
 (parser location arg1 arg2)
 (arg1-type-check? arg2-type-check?)
 ...)

That's used in user space and relies on Lilypond's parser, for the 
assignment of the anonymous function. So if we use that, it must go to 
some .ly file with my original syntax; e.g. ly/lyrics-tkit.ly, is apt.


Otherwise, it can go to a .scm file as just
(define (autoextenders lyrics)
 (music-map ...))


Cheers,
Alexander

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

Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)

[Alexander Kobel]

Hi James,

thanks for taking care of that one.

On 2016-12-14 13:15, James wrote:

Hello,

On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote:

Reviewers: ,

Message:
add choral and choral-cautionary accidental style

...


Please review this at https://codereview.appspot.com/311430043/

Affected files (+151, -1 lines):
  M Documentation/notation/pitches.itely
  M ly/engraver-init.ly
  M scm/music-functions.scm

___


Does this have an associated tracker item or do we need to create one
for you?

https://sourceforge.net/p/testlilyissues/issues/?source=navbar


I don't think git-cl created one; I received some error message but I 
thought it related to the known and documented "no automatic 
notification" after patch upload. But obviously, I mis-configured 
git-cl's Allura bearer token...
Please create one if you don't mind; I will have a look at the 
configuration for my next upload.



Thanks,
Alexander

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

Re: music function to be included somewhere in scm/*

[Alexander Kobel]

Hi Urs, hi all.

On 2016-12-14 11:18, Urs Liska wrote:

Am 14.12.2016 um 10:43 schrieb Alexander Kobel:

To allow automated creation of lyric extenders a helper function is
needed


... that does exactly this, adding extenders everywhere.

IMHO, the actual question to decide upon is: Do we want this to be
enabled by default? IIUC, the fact that extenders are not automatic is
a known shortcoming. NR 2.1.1 states under "Known issues and warnings":
"Extender lines under melismata are not created automatically; they
must be inserted manually with a double underscore." (see
http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-vocal-music#multiple-notes-to-one-syllable)


With Knut's patch, this will mostly impact scores where extenders are
left out unintentionally. Still, it will be a burden for convert-ly
unless we have a global (or per lyric definition) \noAutomaticExtender
rule that is inserted by default.

On the other hand, there is the chance to get rid of scores where
users don't add extenders simply because they are not aware of their
importance or the proper syntax.


My gut feeling says: Yes, this is an improvement and should be there by
default. IIUC the reason why this has to be discussed is because that
could change/break existing scores, right?


Correct. Change: yes, for sure; break: hardly, unless non-standard 
adjustments to lyrics have been made.



If so, could you please think about an example where the patch would
have a negative impact that can't reasonably be caught by convert-ly?
Just because you two are much more into the topic, so that could help us
others understand ...


The only difficult situation for an automatic conversion that I can 
think of is the following:
Attached is a modified version of the "divisi lyrics" example from NR 
2.1.2, along with a modified version of \autoextenders that alleviates 
the severity and offers a way out. The file features a slightly 
different approach to divisi lyrics, where the second voice persists 
over the entire length of music, but some notes are skipped in the 
lyrics with _.


The short stub extenders after "We" and in the third lyrics line will be 
removed by Knut's patch, so they are not a problem (the picture is made 
from an unpatched Lily version). The issue is with the long extenders 
after "will" without corrections. That's because the several _ _ in the 
lyrics create a melisma over several notes, which is semantically wrong, 
but visually indistinguishable from the correct semantics; hence, I 
could imagine that this notation has been used in several scores with 
divisi lyrics. I'm no exception myself.


My guess is that a convert-ly rule that translates every occurence of
   word _
to
   \once \override LyricText.self-alignment-X = #LEFT word \markup{\null}
or
   \once \override LyricText.self-alignment-X = #LEFT word ""
will be sufficient to resolve it, but I'm not sure how robust this 
approach is. This fakes the melisma by left-alignment, but semantically 
leaves "word" assigned to only one note.
"" gives a warning "LyricText has empty extent and non-empty stencil.", 
though; for the more verbose \markup{\null} I can't figure out how to 
leave out the braces: \markup \null translates to (markup #:null) in 
Scheme, but the Scheme construct (markup #:null) creates (markup #:line 
(#:null)) somewhere on the way, and those don't compare equal...



For "normal" lyrics, it's difficult to tell. I cannot imagine a 
"negative" impact in the sense that readability is affected for proper 
lyrics. But at least there is a change.


E.g., I took some (more or less) random piece from CPDL - have a look at
   http://www.uma.es/victoria/pdf/Cum_Beatus_Ignatius.pdf
A typical renaissance piece with typical notation (no slurs). Alvarez is 
clearly aware of extenders and uses them, e.g. in m. 43. However, he 
decided not to add them at other places, e.g. for the very first word of 
the canto or in the final bars m. 100 - 102. I guess that this is 
deliberate decision and not lazyness, and the same is done throughout 
his other scores.


I could e.g. imagine that some editor distinguishes for { b2~ | b r } in 
m. 53: with extender, hold the entire value of the note; without, you're 
allowed to stop earlier, e.g. on the barline. Not saying that this is 
Alvarez' intention, or that this is a good or bad interpretation, but 
you never know. At least, it would be an explanation for having 
extenders only here and there.



But I'm confident that in most cases (basically, short of misusing 
lyrics for other means), the changes will not deteriorate the appearance 
and readability, rather the contrary.



Cheers,
Alexander
\version "2.19"

autoextenders =
#(define-music-function (lyrics) (ly:music?)
   (let* ((has-hyphen?
   (lambda (event)
 (let* ((art (ly:music-property event 'articulation

Re: music function to be included somewhere in scm/*

[Alexander Kobel]

Hi Knut, hi everybody.

On 2016-12-15 13:34, Knut Petersen wrote:

Hi Alexander, hi everybody!


And we might need to offer a way to remove a LyricExtender event.
Unless we go the radical route and ...


After a bit of thinking I'd say: go the radical route.

Attached is a patch against current master that implements it that way.


Beautiful. I was afraid of the amount of work this requires, but it's 
also my preferred approach. And it looks like the issue popped up at the 
right time, with a capable person taking care of the dirty details... :-)



An additional no-extender property
is added that can only be overridden by the force-extender property.


 If a user doesn't want it, we need to provide a function \extenderOff
(that translates, e.g., to \override LyricExtender.stencil = ##f).


\layout {
\Lyrics
\override LyricExtender.no-extender = ##t
}


I like that.


Only thing to consider there: We'd need a "stop sign" for extenders
that shall only extend to some point in a _ _ _ sequence, as required
in a divisi lyrics setting.


"" and \markup\null are usefull, see 5th exampled in attached
lyrextest.ly/pdf


Works like a charm. If "" is to be recommended in the docs (and I think 
\markup\null is too verbose for that purpose), we should make sure that the

  warning: LyricText has empty extent and non-empty stencil.
is not issued in that case.


I know that the documentation would need some work, but there is no
reason to start with that until it is known that the changed code
would be accepted.


Makes sense. I'm perfectly happy with that patch. Let's wait for some 
more opinions.



Thanks and cheers,
Alexander

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

Re: add choral and choral-cautionary accidental style (issue311430043by perpeduumimmob...@gmail.com)

[Alexander Kobel]

On 2016-12-15 13:34, Trevor Daniels wrote:

Alexander, you wrote Wednesday, December 14, 2016 11:49 PM


yes, I guess I never asked to be on that list. My last commit was
pre-Rietveld and pre-Allura, I think; and it's unlikely that
contributions from my side will come more often in the foreseeable
future (except for one more patch "in the pipeline", waiting for a
cleanup and documentation).
So I guess it's not really worth to give me any other status than other
occasional users. On the other hand, do whatever is the most convenient
for you - handling a lonesome patch every other year manually or adding me.


Adding you to the dev list is very little work, but you do have to
get a SourceForge id and tell me what it is for me to do that.

James probably is willing to undertake the work of creating an
issue and servicing it on your behalf, but if you yourself are not
known to Allura you will not be able to contribute to any discussion
on _any_ issue - including those James has created on your behalf.


Okay, makes sense. In this case, I guess it's reasonable to add me no 
matter how much (or little) I will participate. I created an SF account 
with username akobel.



Cheers,
Alexander

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

Re: music function to be included somewhere in scm/*

[Alexander Kobel]

On 2016-12-15 17:19, Trevor Daniels wrote:

Knut Petersen wrote Thursday, December 15, 2016 1:55 PM


minimum-length in my patch means:
- Don't generated automatic extenders if it's impossible to give them 
minimum-length.
- Use minimum-length for forced extenders at unusual places (single note) if 
possible.

I think the most reasonable way is to keep that traditional name.


I don't understand what you mean for the proposed behaviour.

Currently, I set minimum-length = 0 in all Lyric contexts so that I
can place identical lyrics in several voices, all with extenders, but
the extenders appear in the score only when they correspond to melismata.


With the effect that sometimes you'll have extenders that are merely 
flyspecks, yes.



In other words the extender is permitted to reduce in size to 0, which
seems pretty well what "minimum-length" means.

Will this behaviour change with your proposed patch?


Yes: it will improve.

(1) You can put the lyrics to all voices, as extenders are only printed 
on melismata (unless explicitly enforced).
(2) You don't have to add __ in your lyrics anymore - it's done 
automagically (unless explicitly disabled).
(3) minimum-length (or some other name) is used to control appearance 
(right now, you "abuse" it to fake semantics).


Explanation for (3): On short melismata you'll often want to hide 
extenders if the syllable has (almost) the same horizontal extent as the 
music. That's dependent on line breaks etc., so you'll optimally want a 
minimum-length /strictly/ larger than 0 (to ensure that you don't have 
the previously mentioned flyspecks), but smaller than, say, 2 staff 
spaces. So extenders that have a natural length of 2 units are printed, 
shorter ones aren't.
IMHO, setting minimum-length to 0 is an ingenious workaround for a 
missing functionality (namely, disabling extenders on non-melismata), 
but it means that you lose the functionality it is intended for.


AFAICS, nothing will change for your existing scores.


Cheers,
Alexander

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

Re: music function to be included somewhere in scm/*

[Alexander Kobel]

On December 15, 2016 8:41:14 PM GMT+01:00, Simon Albrecht 
<simon.albre...@mail.de> wrote:
>On 15.12.2016 17:45, Alexander Kobel wrote:
>> (1) You can put the lyrics to all voices, as extenders are only 
>> printed on melismata (unless explicitly enforced).
>> (2) You don't have to add __ in your lyrics anymore - it's done 
>> automagically (unless explicitly disabled).
>> (3) minimum-length (or some other name) is used to control appearance
>
>> (right now, you "abuse" it to fake semantics). 
>
>This is a _huge_ improvement and new feature! I’ll be thrilled to see
>it 
>in the code base.
>
>Best, Simon

+1. And the most surprising thing about it is that I had a (slightly less 
elegantly scheme-d, but still working) solution in my toolbox and posted on the 
list years ago, and never noticed its potential. So a big thanks to Joram! 
Usability-wise, that's the most drastic improvement for my typical Lilypond 
work I can imagine...


Cheers,
Alexander

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