Re: Please test gub

[Alexander Kobel]

On 08.02.19 14:12, Knut Petersen wrote:

Hi everybody!
 Use /usr/bin/env python2? Does every python 2.x installation 
really contain a python2 executable?
 OSX 10.12 Sierra has python 2.7 but does not have a python2 
executable.  Only python.


At least this is the case on my machine.


Gosh, didn't expect that.

In that case, I'd vote for leaving python shebangs as they are.

Arch is clearly not following (one of) the recommendation in the PEP, 
that python "should" deliver python2. So it's Arch's fault, and their 
(packagers/users') responsibility to take appropriate action.



Again, something to document ;-)

Gub itself does not provide a python2.

I think with the attached test-patch on top of the patch I already sent 
to you 'make lilypond' (not only bin/gub xxx::lilypond) should succeed 
after you put the newly created wrapper directory in front of PATH.


I see; this wrapper directory is more convenient than asking the user to 
provide a dir with only the symlinks python{,-config} -> 
/some/where/python2{,-config} on his own and add it to the PATH.


But isn't it against the purpose that now the shebangs of bin/gub/* read

#! /usr/bin/env python2

? I think you meant: add the wrapper directory PATH such that we *don't* 
have to replace python by python2 in those shebangs.


-TARGET_PYTHON=/usr/bin/python
+TARGET_PYTHON=/usr/bin/env python

in gub/specs/lilypond{,-doc}.py (rather than python2) is necessary and 
(almost) correct in the patch, though.



Cherry-picking only those changes, everything seems to start fine.


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

On 08.02.19 04:51, Carl Sorensen wrote:

On 2/6/19, 3:42 PM, "lilypond-devel on behalf of Knut Petersen" 
 wrote:

 
 >> - the need to make sure that `python` calls a python2 interpreter.

 > No idea how this could be solved elegantly.  I guess it can't, so we
 > have again something to document...
 >
 Use /usr/bin/env python2? Does every python 2.x installation really 
contain a python2 executable?
 
OSX 10.12 Sierra has python 2.7 but does not have a python2 executable.  Only python.


At least this is the case on my machine.


Gosh, didn't expect that.

In that case, I'd vote for leaving python shebangs as they are.

Arch is clearly not following (one of) the recommendation in the PEP, 
that python "should" deliver python2. So it's Arch's fault, and their 
(packagers/users') responsibility to take appropriate action.



Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

On 06.02.19 23:31, Knut Petersen wrote:

On 06.02.19 15:09, Werner LEMBERG wrote:

That leaves the two problems of

- LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so
   (I rm'ed LLVMgold.so there for the purpose of the above gub run.)

This is definitely *not* a gub issue.  It's strange that only the
compilation of guile is affected by the problem, but I consider this a
pure coincidence.  IOW, this should be added to the gub documentation,
as a special preparation step for some LLVM/binutils combinations.


I agree.


I have no idea regarding that issue and trust your assessment.


- the need to make sure that `python` calls a python2 interpreter.

No idea how this could be solved elegantly.  I guess it can't, so we
have again something to document...

Use /usr/bin/env python2? Does every python 2.x installation really 
contain a python2 executable?


Not sure, but according to PEP 394, they "should". The PEP dates back to 
2011, so I'd assume that all systems have a corresponding alias by now, 
and only the default `python` is different.


(IIUC, Gentoo follows Arch's example, see the bottom of 
https://wiki.gentoo.org/wiki/Python; do we have any Gentoo users here?)


Of course, Arch obviously disregards the PEP's first recommendation 
(python should point to python2), so it's perfectly fair to consider 
this entirely Arch's / Gentoo's fault. However, one of the good reasons 
Archers state to follow the explicit python2 / python3 spelling (and 
having python3 as default) is that python2 will see it's end of 
maintenance at the end of this year, and they plan to stop distributing 
python2 as a first-class citizen in the core repositories more or less 
immediately (it will still be easily available via community repos 
though). So following all of the PEP, you'd end up with a system that 
has python3, but neither python nor python2. Perhaps that's harsh, but 
it's a reasonable decision given that official support ends.


In the rationale, the PEP says

"As some of the former distributions did not provide a python2 command 
by default, there was previously no way for Python 2 code (or any code 
that invokes the Python 2 interpreter directly rather than via 
sys.executable) to reliably run on all Unix-like systems without 
modification, as the python command would invoke the wrong interpreter 
version on some systems, and the python2 command would fail completely 
on others."


so this might not be *entirely* smooth.
https://mail.python.org/pipermail/python-dev/2011-March/108491.html 
mentions Debian, Slack and BSDs; but AFAIK, all of those follow the PEP 
these days.



I think we also would need to change some lilypond files ...


FWIW, this is what is done in the Arch packaging process:

  for file in $(find . -name '*.py' -print); do
sed -i 's_^#!.*/usr/bin/python_#!/usr/bin/python2_' $file
sed -i 's_^#!.*/usr/bin/env.*python_#!/usr/bin/env python2_' $file
  done

  sed -i 's|GUILE_CFLAGS=.*|GUILE_CFLAGS="`pkg-config --cflags 
guile-1.8`"|' configure
  sed -i 's|GUILE_LDFLAGS=.*|GUILE_LDFLAGS="`pkg-config --libs 
guile-1.8`"|' configure


plus a patch regarding fontsizes; not sure what this is about:

https://git.archlinux.org/svntogit/community.git/tree/trunk/lilyfontsize.patch?h=packages/lilypond


It might be worth testing whether applying this patch upstream breaks 
anything for someone else; but of course, that's from an Arch user's 
perspective...



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi Knut,

On 06.02.19 13:17, Knut Petersen wrote:

Hi Alexander!

Perfectly correct, your expectations are met. 


I hope that story of success continues ;-)


it does. :-)


Would you be so kind to test the attached patch?


Sure.

  bin/gub --fresh linux-x86::lilypond linux-64::lilypond

succeeded with your patch.

That leaves the two problems of

- LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so
  (I rm'ed LLVMgold.so there for the purpose of the above gub run.)

and

- the need to make sure that `python` calls a python2 interpreter.


For the latter, the course of action is clear (but sorry, I didn't find 
the time to investigate yet), and AFAIU, the problem is entirely 
Arch-specific at the current point in time.
So the former issue apparently is more pressing, as it also emerged on 
Werner's OpenSUSE setup.



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

On 05.02.19 09:20, Knut Petersen wrote:

Hi Alexander!


In case you wonder, on Arch both /lib and /lib64 are symlinked to 
/usr/lib; they also abandoned the distiction between /bin, /sbin, 
/usr/sbin and /usr/bin, and the former three are symlinked to the latter.



Ok, that's an important difference to other linux systems:

Could it be that

bin/gub --fresh darwin-ppc::guile darwin-x86::guile
freebsd-64::guile freebsd-x86::guile linux-ppc::guile mingw::guile
tools::guile

succeeds


It does.


and that

bin/gub --fresh linux-x86::guile
bin/gub --fresh linux-64::guile

both fail?


They do.


I think (hope) that

bin/gub --fresh darwin-ppc::lilypond darwin-x86::lilypond
freebsd-64::lilypond freebsd-x86::lilypond linux-ppc::lilypond
mingw::lilypond

should also succeed in that case ...


Perfectly correct, your expectations are met.


HTH,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

On 05.02.19 08:40, Knut Petersen wrote:

On 04.02.19 15:29, Alexander Kobel wrote:

Remote debugging... Perfectly correct, here you are.


Thanks.

The file /usr/lib/ld-linux-x86-64.so.2 is used instead of the expected 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/ld-linux-x86-64.so.2.


Could you please execute

ls -l `find -L /lib* /usr /home/akobel/gub | grep ld-linux-x86-64.so.2`

and mail me the result?


Sure, that'd be

lrwxrwxrwx 1 akobel akobel 11 31. Jan 17:32 
/home/akobel/gub/gub/target/linux-64/root/lib64/ld-linux-x86-64.so.2 -> 
ld-2.3.6.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 /lib64/ld-linux-x86-64.so.2 
-> ld-2.28.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 /lib/ld-linux-x86-64.so.2 -> 
ld-2.28.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 
/usr/lib64/ld-linux-x86-64.so.2 -> ld-2.28.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 
/usr/lib/ld-linux-x86-64.so.2 -> ld-2.28.so


and /usr/lib/ld-2.28.so is part of the glibc package.

In case you wonder, on Arch both /lib and /lib64 are symlinked to 
/usr/lib; they also abandoned the distiction between /bin, /sbin, 
/usr/sbin and /usr/bin, and the former three are symlinked to the latter.



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

On 02.02.19 10:27, Knut Petersen wrote:

On 01.02.19 15:06, Alexander Kobel wrote:

On 01.02.19 14:51, Alexander Kobel wrote:

GUB-bing further down the road now...


Hrmpf, back here sooner than I hoped.
Guile barfed - see the attached log.

libtool: link: x86_64-linux-gcc -g -O2 -Wall -Wmissing-prototypes -o 
.libs/guile guile-guile.o  ./.libs/libguile.so 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/libgmp.so -lcrypt 
-lm /home/akobel/gub/gub/target/linux-64/root/usr/lib/libltdl.so -ldl 
-Wl,-rpath -Wl,/usr/lib -Wl,-rpath 
-Wl,/home/akobel/gub/gub/target/linux-64/root/usr/lib
/home/akobel/gub/gub/target/linux-64/root/lib64/libc.so.6: undefined 
reference to `_dl_out_of_memory@GLIBC_PRIVATE'
collect2: error: ld returned 1 exit status 


The argumens given are ok. As usual

mkdir -p STRACE
strace -v -f -ff -s 1 -o STRACE/TP bin/gub --fresh linux-64::guile

will help to identify the problem.


hm, that gives appx. 2 GB of traces, and I'm not sure which process' 
trace I should look at. Nothing segfaults, so I don't get a PID hint as 
for the previous problem.


Appx. 380 MB worth of traces contain the buzzwords out_of_memory; those 
compress to 4.6 MB, so I could send them off-list?



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

On 01.02.19 14:51, Alexander Kobel wrote:

GUB-bing further down the road now...


Hrmpf, back here sooner than I hoped.
Guile barfed - see the attached log.

libtool: link: x86_64-linux-gcc -g -O2 -Wall -Wmissing-prototypes -o 
.libs/guile guile-guile.o  ./.libs/libguile.so 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/libgmp.so -lcrypt -lm 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/libltdl.so -ldl 
-Wl,-rpath -Wl,/usr/lib -Wl,-rpath 
-Wl,/home/akobel/gub/gub/target/linux-64/root/usr/lib
/home/akobel/gub/gub/target/linux-64/root/lib64/libc.so.6: undefined 
reference to `_dl_out_of_memory@GLIBC_PRIVATE'

collect2: error: ld returned 1 exit status


Cheers,
Alex


guile.log.xz
Description: application/xz


smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

On 01.02.19 14:28, Knut Petersen wrote:
I wonder if we really need libopenjpeg ...  Yes, we need jpeg ... but  
we also link against our own libjpeg, and we talk about tools::poppler.


Note: libopenjpeg is (misnomed and) only required for JPEG 2000. 
Traditional JPEG is taken care of by libjpeg, which doesn't cause problems.



You could try to build with:

commit 751ac35d67764c9be22a887ad513b819d8ed101d (HEAD -> newStateOfArt)
[...]


Almost.

diff --git a/gub/specs/poppler.py b/gub/specs/poppler.py
index d8381f68..c8ec7063 100644
--- a/gub/specs/poppler.py
+++ b/gub/specs/poppler.py
@@ -11,8 +11,9 @@ class Poppler (target.AutoBuild):
 'libxml2-devel',
 ]
 configure_flags = (target.AutoBuild.configure_flags
-+ ' --disable-poppler-qt'
++ ' --disable-libopenjpeg'
 + ' --disable-poppler-qt4'
++ ' --disable-poppler-qt5'
 + ' --enable-xpdf-headers'
 + ' --disable-gtk-test')
 # FIXME: poppler, librsvg, cairo, gtk dependencies?
@@ -43,7 +44,8 @@ class Poppler__tools (tools.AutoBuild, Poppler):
 'libxml2',
 ]
 configure_flags = (tools.AutoBuild.configure_flags
-   + ' --disable-poppler-qt'
+   + ' --disable-libopenjpeg'
+ ' --disable-poppler-qt4'
+   + ' --disable-poppler-qt5'
+ ' --enable-xpdf-headers'
+ ' --disable-gtk-test')

did the job.

Note the 'lib' in ' --disable-libopenjpeg', and that I added it to 
Poppler__tools as well (just in case).
Also, '--disable-poppler-qt' is reportedly unknown, and should end with 
a '5' instead.

Finally, some solace from configure:

"Warning: Using libopenjpeg is recommended. The internal JPX decoder is 
unmaintained."


Which probably means that there's no loss in functionality, as the 
decoder at least used to work.



GUB-bing further down the road now...


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

On 01.02.19 14:09, Alexander Kobel wrote:

Hi,

On 01.02.19 13:51, Knut Petersen wrote:

On 31.01.19 16:04, Alexander Kobel wrote:



and I can cleanly compile the recent poppler 0.73 with openjpeg2 
backend from source, with a simple cmake + make.



is there an libopenjpeg1-devel package installed? If not: try to 
install and rerun gub ...


yes and no - Arch follows the principle that the packages provide both 
runtimes and development requirements at the same time, so there is no 
separation as in, e.g., Debian.
In particular, I have the headers on my system, and pkg-config is 
configured correctly:


Moreover, checking with poppler 0.49 as used in GUB, and loosely 
following the package build script for 0.49 from



https://git.archlinux.org/svntogit/packages.git/plain/trunk/PKGBUILD?h=packages/poppler=1626dc8989ffc95eab611e4bd47d54f9b0fcfde0

(nothing too fancy in Arch packaging, yay!), the build succeeds after

  ./configure <--enable-unrelated-stuff> --enable-libopenjpeg=openjpeg1
  make

Note the absence of any paths, flags, etc. - everything is detected 
automagically:


Building poppler with support for:
  font configuration:  fontconfig
  splash output:   yes
  cairo output:yes
  qt4 wrapper: yes
  qt5 wrapper: yes
  glib wrapper:yes
introspection: yes
  cpp wrapper: yes
  use gtk-doc: no
  use libjpeg: yes
  use libpng:  yes
  use libtiff: yes
  use zlib compress:   yes
  use zlib uncompress: no
  use nss: yes
  use libcurl: no
  use libopenjpeg: yes
  with openjpeg1
  use cms: yes
  with lcms2
  command line utils:  yes


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

On 01.02.19 13:51, Knut Petersen wrote:

On 31.01.19 16:04, Alexander Kobel wrote:



and I can cleanly compile the recent poppler 0.73 with openjpeg2 
backend from source, with a simple cmake + make.



is there an libopenjpeg1-devel package installed? If not: try to install 
and rerun gub ...


yes and no - Arch follows the principle that the packages provide both 
runtimes and development requirements at the same time, so there is no 
separation as in, e.g., Debian.
In particular, I have the headers on my system, and pkg-config is 
configured correctly:


% ls -1 /usr/include/openjpeg-*/*
/usr/include/openjpeg-1.5/openjpeg.h
/usr/include/openjpeg-2.3/openjpeg.h
/usr/include/openjpeg-2.3/opj_config.h
/usr/include/openjpeg-2.3/opj_stdint.h

% pkg-config --cflags --libs libopenjpeg 


-I/usr/include/openjpeg-1.5 -lopenjpeg

% pkg-config --cflags --libs libopenjpeg1
-I/usr/include/openjpeg-1.5 -lopenjpeg

% pkg-config --cflags --libs libopenjp2
-I/usr/include/openjpeg-2.3 -lopenjp2


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

On 31.01.19 16:15, Karlin High wrote:

On 1/31/2019 9:04 AM, Alexander Kobel wrote:

BTW, can we actually add images in Lily?


Encapsulated PostScript images are fair game with \epsfile

<http://lilypond.org/doc/v2.19/Documentation/notation/graphic.en.html>

I know I used that once, but I forget which program I used to make the 
EPS file containing the image. Perhaps it was GIMP.


Ah, of course. There's jpeg2ps (from CTAN) which IIRC wraps JPEG without 
recompression to ps or eps files; for anything else, I'd probably go for 
pdfjam or img2pdf, followed by pdftops -eps, or just ImageMagick's (or 
GraphicsMagick's) convert.
GIMP can do it, too, but I doubt you can specify the compression 
algorithm (in particular, choose between lossless and lossy, the latter 
possibly without recompression).


But in fact I'm fairly happy to leave PostScript behind the scenes, only 
touch PDF, and not to worry too much when buying printers... ;-)



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

On 31.01.19 13:25, Alexander Kobel wrote:

Indeed, LLVMgold.so pops up in the trace.
On my system, the symlink for liblto_plugin.so already exists, so I only 
had to remove (rename wasn't enough) LLVMgold.so.


Building tools::guile succeeds after that modification; I'll test the 
further progress of `make lilypond` later.


The build went on cleanly until poppler 0.49, which apparently is clever 
enough to figure out that it can't deal with my openjpeg installation ...


checking for LIBOPENJPEG... no
checking for opj_cio_open in -lopenjpeg... yes
checking openjpeg.h usability... no
checking openjpeg.h presence... no
checking for openjpeg.h... no

... but nevertheless insists on using it ...

Building poppler with support for:
  [...]
  use libopenjpeg: yes
  with openjpeg1
  [...]

... and, to no surprise, fails:

/home/akobel/gub/gub/target/tools/src/poppler-0.49.0/poppler/JPEG2000Stream.cc:20:10: 
fatal error: openjpeg.h: No such

 file or directory
 #include 
  ^~~~
compilation terminated.


FWIW, both openjpeg 1 and 2 are installed system-wide:

extra/openjpeg2 2.3.0-3 [installed]
An open source JPEG 2000 codec, version 2.3.0
extra/openjpeg 1.5.2-2 [installed]
An open source JPEG 2000 codec

and I can cleanly compile the recent poppler 0.73 with openjpeg2 backend 
from source, with a simple cmake + make.



Perhaps it's wise to disable openjpeg entirely for poppler within GUB? 
Note that, despite the name, openjpeg is only a concern for JPEG2000; 
plain old JPEG is supported by libjpeg. (BTW, can we actually add images 
in Lily?)



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Addendum:

On 31.01.19 15:39, Alexander Kobel wrote:
Whenever I can, I "correct" shebangs to python2 (without ever having 
looked up this PEP), and nobody ever complained that it breaks their 
workflow.


That is to say: I've yet to encounter a system where python points to 
python2.x, but at the same time there's no python2 -> python2.x 
symlink/hardlink/anylink/copy/wrapper. So I doubt that adding the "2" 
will cause any grief.




smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

On 31.01.19 15:21, David Kastrup wrote:

Knut Petersen  writes:


On 31.01.19 08:43, Alexander Kobel wrote:

Hi,

fails on Arch Linux (up-to-date, Intel Core i5-3317U).

First, all Python scripts seem to require Python2 (but python ->
python3 is the default on Arch).


I don't think that matches Python's own recommendation.  Has this
changed?


Kind of, yes, but then again, no, not really, it turns out. Lucky 
buzzwords for Google gave me PEP 394:

  https://www.python.org/dev/peps/pep-0394/

Relevant is the abstract, which in fact mentions that Arch, 
specifically, switched "early", broke the former practice (and, 
apparently, implicit and unwritten recommendation) and thus raised the 
discussion that led to PEP 394. It also says that "for the time being, 
all distributions should ensure that python, if installed, refers to the 
same target as python2, unless [...]".


*Also* relevant *now*, however, are the following point(s) from the 
recommendation:


"In order to tolerate differences across platforms, all new code that 
needs to invoke the Python interpreter should not specify python, but 
rather should specify either python2 or python3 (or the more specific 
python2.x and python3.x versions; see the Migration Notes). This 
distinction should be made in shebangs, when invoking from a shell 
script, when invoking via the system() call, or when invoking in any 
other context."


and

"In order to tolerate differences across platforms, all new code that 
needs to invoke the Python interpreter should not specify python, but 
rather should specify either python2 or python3 (or the more specific 
python2.x and python3.x versions; see the Migration Notes). This 
distinction should be made in shebangs, when invoking from a shell 
script, when invoking via the system() call, or when invoking in any 
other context."



I second the recommendation: as a happy year-long Archer, python 
shebangs are, by far, the number 1 of annoyances I encounter regularly. 
Whenever I can, I "correct" shebangs to python2 (without ever having 
looked up this PEP), and nobody ever complained that it breaks their 
workflow.
On the other hand, I still occasionally use systems with Python2 <2.7 
(strictly less than). Hence, I'd refrain from specifying a minor version 
if it can be avoided. AFAIK, 2.8 is promised to never appear, so it 
shouldn't matter for 2.x. And I don't have 3.y for y < 7 available on my 
system; yet, 3.3 scripts run perfectly albeit the author might not have 
thought about that version when writing the script.



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

strace according to Knut's instructions is attached.

On 31.01.19 12:54, Werner LEMBERG wrote:



Apart from that minor buzz, `make lilypond` does a good chunk of work,
but fails building tools::guile; log attached.


I see. libtools segfauls.



../libtool: line 950: 23645 Segmentation fault  (core dumped)
ar cru .libs/libguile.a [...]


This is probably the same bug I've encountered on my openSUSE box.
Try to remove the file (or link) `/usr/lib/bfd-plugins/LLVMgold.so'
and replace it with the gcc variant `liblto_plugin.so'.  On my system
I had to do

   cd /usr/lib/bfd-plugins
   ln -s /usr/lib64/gcc/x86_64-suse-linux/7/liblto_plugin.so .


Indeed, LLVMgold.so pops up in the trace.
On my system, the symlink for liblto_plugin.so already exists, so I only 
had to remove (rename wasn't enough) LLVMgold.so.


Building tools::guile succeeds after that modification; I'll test the 
further progress of `make lilypond` later.



FWIW:

# pacman -Qo /usr/lib/bfd-plugins/{LLVMgold.so,liblto_plugin.so}
/usr/lib/bfd-plugins/LLVMgold.so is owned by llvm-libs 7.0.1-2
/usr/lib/bfd-plugins/liblto_plugin.so is owned by gcc 8.2.1+20181127-1

So probably deinstalling llvm-libs (and clang, and some other packages 
that depend on it) might help... :-/


BTW, since gcc7 was mentioned couple of times in this thread:
/usr/lib/bfd-plugins/liblto_plugin.so points to 
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/liblto_plugin.so, but I also have 
the gcc7-libs variant under 
/usr/lib/gcc/x86_64-pc-linux-gnu/7.4.1/liblto_plugin.so; but the build 
succeeded with gcc8's liblto_plugin.so, so I did not test that.



I don't quite get why (IIUC, which I might not) gub apparently builds 
gcc, but then seems to use the system-wide gcc down the road?



Cheers,
Alex


TP.21085.xz
Description: application/xz


smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test new lilypond installers

[Alexander Kobel]

Hi,

On 29.01.19 10:19, Knut Petersen wrote:
Urs Liska provides installers for branch master of lilypond, generated 
by an updated version of our build system GUB:

[...]
    lilypond-2.21.0-1.linux-64.sh
    lilypond-2.21.0-1.linux-x86.sh


Work like a charm on Arch Linux.


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Alexander Kobel]

Hi,

fails on Arch Linux (up-to-date, Intel Core i5-3317U).

First, all Python scripts seem to require Python2 (but python -> python3 
is the default on Arch). I placed a symlink to python -> python2 in a 
high-priority $PATH as a workaround, but it might be a good idea to 
replace the shebang line by ".../env python2" for scripts which are not 
Python3-compatible.



Apart from that minor buzz, `make lilypond` does a good chunk of work, 
but fails building tools::guile; log attached.


FWIW, the gcc7 and gcc7-libs packages from the upstream repo (7.4.1) are 
installed (as well as the up-to-date gcc and gcc-libs 8.2.1), as well as 
all build and runtime dependencies for Lilypond on this architecture. At 
least, I successfully built 2.19.something from Git clones on this machine.
As far as I can remember, such a "standalone arch-specific" build of 
Lilypond doesn't compile guile, but relies on the guile1.8 package from 
the repos (the package maintainers don't seem to require any special 
precautions for building it, as can be seen in the packaging script at 
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/guile1.8).
Notable difference here: GUB tries to work with Guile 1.8.7, upstream is 
at 1.8.8.



The only other part of the log that caught my eye:

building package: linux-x86::cross/gcc-core
 *** [...]
 *** Stage: pkg_install (cross/gcc-core, linux-x86)

building package: linux-x86::glibc-core
 *** [...]
 *** Stage: pkg_install (glibc-core, linux-x86)

building package: linux-x86::cross/gcc
 *** [...]
 *** Stage: pkg_install (cross/gcc, linux-x86)
  cross/gcc-core conflicts with cross/gcc-doc
removing cross/gcc-core


Not sure whether that's intended; is gcc-core just required to build gcc 
and supposed to be replaced after that?



Cheers,
Alex


On 28.01.19 13:53, Knut Petersen wrote:

Hi everybody!

I created a branch in my gub repository  that contains 
https://github.com/gperciva plus pull requests 53-60. Therefore it is 
pretty easy to test if that version of gub succeeds to build current 
lilypond master on your machine.


All you need to do is to execute the following commands:

    git clone https://github.com/knupero/gub.git -b DevelHead
    cd gub
    mkdir regtests
    cd regtests
    wget 
http://lilypond.org/downloads/binaries/test-output/lilypond-2.19.82-1.test-output.tar.bz2 


    touch ignore
    cd ..
    time make lilypond

Even on a fast computer 'make lilypond' will take some hours to complete.

If downloading of a source archive fails because of some network problem 
restart 'make lilypond'.


You'll need some free disk space ... about 20 GB is a minimum.

Please report success / fails with os / version / cpu info.

Knut

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


guile.log.xz
Description: application/xz


smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LyricExtender suicide fix

[Alexander Kobel]

On 2017-06-14 12:07 PM, Kieren MacMillan wrote:

Hello all,

The attached file includes a hack/fix I sponsored a couple of years ago.

Any thoughts/discussion towards putting this in the codebase would be 
appreciated. Happy to shepherd it myself, if it's just a matter of adding this 
code somewhere [not in C++] and submitting a patch.


Hi Kieren,

without looking at your snippet any closer (don't have Lily available 
right here, right now): please see


https://sourceforge.net/p/testlilyissues/issues/4509/
https://codereview.appspot.com/313240043

This aims to be a full-stop solution to extender handling that most 
probably offers a superset of your proposal, thanks to Knut's hard work. 
Unfortunately, while the code is working, there are implications w.r.t. 
long-term maintainability of the feature and impact to clean backend 
design. David K. has (very valid) concerns there, and has it on his 
todo-list - but as you know, the time he can and should devote is fairly 
limited these days.


For a very easy-to-use, no-compile-time-patches-needed workaround that 
still offers plenty of automation and functionality, see the 
autoextenders.ily from

  http://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00536.html
(I hope I pointed you to the last version).


HTH,
Alex

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

Re: Leave of offliness

[Alexander Kobel]

Hi David,

On 2017-04-11 12:18 PM, David Kastrup wrote:

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


What /is/ slightly annoying and IMHO should be changed as soon as
possible is the extendersOverRests default value. (Note that I
didn't have /any/ time to care about Lilypond since March, so I
could very well have missed a revert of that default.)


The default has been the same for years, it's just that it was
ignored. What I did was to stop it from being ignored.


Yes, that's very welcome.


This change has not been reverted, but by now the default was changed
to be that what it effectively was by being ignored.

So this is more or less dealt with.


Ah, perfect.  I didn't spot that last change.  I guess that's a sensible 
way to deal with the unexpected (or, at least, undocumented) side 
effects of extendersOverRests for the time being.



Thanks a lot!
Alexander

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

Re: Leave of offliness

[Alexander Kobel]

On 2017-04-09 11:24 AM, David Kastrup wrote:

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

On 2017-04-07 11:24 AM, David Kastrup wrote:

Hi folks,

tomorrow morning I'll be leaving for my annual climbing trip in Italy
(not that I could afford it but there is no point in postponing all
living until death).


Sounds good. Have fun!


Well, doesn't sound good with regard to my getting the head around the
lyric/grace problem that blocked me with regard to automatic extenders.
I haven't forgotten about it, maybe the vacation will help getting my
head clear for it again.


Take your time - both for you and w.r.t. fixes/extensions. Better have 
something well-thought-out when it's ready than something that works 
right now, but becomes a maintainability burden after.


What /is/ slightly annoying and IMHO should be changed as soon as 
possible is the extendersOverRests default value. (Note that I didn't 
have /any/ time to care about Lilypond since March, so I could very well 
have missed a revert of that default.)
I understand that the name doesn't carry a great relation to what it 
actually does, but the current state seems to break expectations in many 
cases.



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: 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]

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: Building issues (lilypond and docs)

[Alexander Kobel]

On 2016-12-30 22:04, Jay Anderson wrote:

In response to this thread:
https://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00679.html
I'm attempting to build lilypond.


Hi Jay,

thanks for looking into this.


When building locally (an older version of mint linux) [...]


Sorry, I have no own experience with Mint, so I can only do some random 
guesswork. Which version of Mint are you using?



Cannot open /home/jay/programming/lilypond/build/mf/out/feta11.pfb
The requested file, feta11.pfb, does not exist
MergeFonts: Can't find font: feta11.pfb

Sure enough it looks like feta11.pfb wasn't built. What should I look
at to see why it wasn't built?


Can you call a `make out/feta11.pfb` in 
/home/jay/programming/lilypond/build/mf/? Maybe something is broken with 
the Metafont setup?


I guess you already checked the compilation requirements from

http://lilypond.org/doc/v2.18/Documentation/contributor/requirements-for-compiling-lilypond#linux-mint 
and


http://lilypond.org/doc/v2.19/Documentation/contributor/requirements-for-compiling-lilypond#linux-mint

AFAICS, the FontForge version that is used is recent enough (and I think 
it is even built with the --enable-double flag or its modern equivalent 
by default, and the package maintainers are unlikely to have changed 
this). Can you see anything suspicious when you manually perform the 
commands:



make[1]: Entering directory `/home/jay/programming/lilypond/build/mf'
/home/jay/programming/lilypond/build/scripts/build/out/gen-emmentaler-scripts
--dir=./out --design-size=11
cd ./out && /usr/bin/fontforge -script emmentaler-11.genpe


The .genpe files are automatically generated by scripts. Does your Mint 
installation default to some recent Python2?
On Arch Linux, the following environment settings are used for building 
Lilypond packages:

  export PYTHON=python2
  export PYTHON_CONFIG=python2-config
  export GUILE=/usr/bin/guile1.8
  export GUILE_CONFIG=/usr/bin/guile-config1.8
where python2 is actually python2.7.


Moving on from that I tried using lilydev and it builds fine in the
virtual machine, but when attempting `make doc` it ran for days on the
learning manual before I killed it. I gave the virtual machine 2gb to
work with. I'm going to try upping that to 4gb before trying again. Is
there anything else to look at here?


Again, no idea, sorry. Building the documentation is a huge time-sink, 
but that's way more than expected...



Cheers,
Alexander

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

Re: Free alternatives to Rietveld?

[Alexander Kobel]

Hi,

On 2017-01-02 11:50, Federico Bruni wrote:

Il giorno mer 28 dic 2016 alle 20:59, Graham Percival
 ha scritto:

On Wed, Dec 28, 2016 at 06:35:30PM +0100, Federico Bruni wrote:

 It would be possible to add a configuration option in git-cl so
 you can login in rietveld with a specific browser different from
 the default one?


Certainly!  In the source, I see:

-
If your browser is on a different machine then exit and re-run
upload.py with the command-line parameter

  --no_oauth2_webbrowser
-

IIRC that prints a URL string, which you can open with whatever
browser you want (on whichever computer you want).


Thanks! I'll try to remember when I need it.

There's a way to make it the default in my configuration? I see that
config values are saved in .git/config and there are some under
[rietveld]. I wonder if no_auth2_webbrowser=true may work...


Not sure about that; didn't spot anything from a (very) quick glance at 
the code. However, what you can do is to set up your own defaults:


alias git-cl-nooa="/path/to/git-cl --no_oauth2_webbrowser"
alias git-cl="BROWSER=/usr/bin/echo /path/to/git-cl"

Specifying the BROWSER environment variable instructs git-cl to use this 
application as browser - which I guess is what you actually wanted in 
the first place?



Cheers,
Alexander

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

Re: Automatic LyricExtenders (issue 313240043 by perpeduumimmob...@gmail.com)

[Alexander Kobel]

A happy new one, everybody!

On 2017-01-01 16:39, Knut Petersen wrote:

Hi everybody!

Attached find a new version of the autoextender patch set.


Thanks Knut. Just uploaded to Rietveld.

(In fact, sorry for double-posting it; I deleted my first upload a 
minute ago after I recognized that I based the patch on a more recent 
master than I should have, with unrelated changes in some files.)



@Alexander:

I cannot think of anything easier to type than "", so it's still there ;-)


No worries, I'm fine with that.


LGTM!


Cheers,
Alexander

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

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

[Alexander Kobel]

On 2016-12-27 21:25, Trevor Daniels wrote:

Alexander Kobel wrote Monday, December 26, 2016 1:00 AM

Oh well, it's late. I didn't spot measure 7, with the 8( 8) in alto.
Same there.
And, of course, you should have an extender there in the second verse,
and you should have extenders in measure 1 (was/was/shall) an measure 9
(shall/shall/was); but that's a limitation of the satb-template (or,
rather, a lack of voice assignment) that's beyond this patch to correct.


Well spotted!  In fact there are several other places where the lyric
alignment was wrong.  At the time I posted it it was a work-in-progress
(for Christmas 2017, in fact), but thank you for helping with the final
tweaks :)  For interest, I attach the latest version, hopefully now almost
correct, albeit several messy tweaks!  Can you spot any other improvements?


To be honest, I'm not sure whether I should be proud of spotting some - 
after this year's last rehearsal, six beers and two schnapps, and an 
obscene level of alcohol blocking my mind. But still, opening the PDF on 
my smartphone, the first thing that came to my mind is: there must be 
something wrong with the kerning of Lily's extenders. And the 
antialiasing of the Android PDF reader sucks, the lines have different 
thickness...

But no, there's fake extenders.

Not sure if it's any good to become too aware of certain details... ;-)


It will make a useful test as the various improvements to LP which you
outline below take effect.  One day maybe all the tweaks can be removed.


In fact, to solve this, one would need a simultaneous assignment of the
lyrics to all four voices they apply to. Basically, a \addlyrics
\lyricsto ChoirStaff.


That would indeed be a great improvement - once it can be made to work!


Yes. Unfortunately, that'll be the only cure to the workarounds, or 
really annoying manual voice-switching within the lyrics.



(Note 1 to whom it may concern, including myself: once this works, the
satb and ssaattbb templates should be changed to associate the Verse*
lyrics with the entire ChoirStaff, and *Lyrics with the corresponding
Staff per default.)


I'd be happy to make this change as soon it it becomes available.


Great to hear. I've never used the templates, mostly to circumvent that 
restriction. I think I'll be a happy user once the extender is fixed...



(Note 2 to whom it may concern, including myself: we should have auto
extender regtests for \lyricsto ctx = name, for at least ctx = Voice,
Staff, ChoirStaff.)


Yes.


Essentially, my recent bug report should be enough for a regtest.


Cheerio, Miss Sophie! (Sorry, can't help. Not sure if you share our 
nation's yearly half-an-hour of British humour with "Dinner for One" on 
the isles - it's Germany's traditional New Year's Eve TV entertainment...)

Alexander

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

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

[Alexander Kobel]

On 2016-12-26 01:01, Alexander Kobel wrote:

On 2016-12-26 00:38, Trevor Daniels wrote:

I attach a recent example - very Christmassy!


Nice one, thanks.
Note that, due to the fixed voice association to soprano in the SATB
template, you should manually left-align the syllables where the bass
has 8.( 16).
And I love the fact that lyrics assigned to a Staff instead of a Voice
(news around 2.19.50) easily allow to align the { King. __ } and {
mould. __ } to the left e' note of the alto instead of the shifted one
in soprano...
Sorry, I meant to write { King. } and { mould. }, of course. ;-)


Oh well, it's late. I didn't spot measure 7, with the 8( 8) in alto. 
Same there.
And, of course, you should have an extender there in the second verse, 
and you should have extenders in measure 1 (was/was/shall) an measure 9 
(shall/shall/was); but that's a limitation of the satb-template (or, 
rather, a lack of voice assignment) that's beyond this patch to correct.


In fact, to solve this, one would need a simultaneous assignment of the 
lyrics to all four voices they apply to. Basically, a \addlyrics 
\lyricsto ChoirStaff.


... Wait, wasn't there recent news that the "\addlyrics function now 
works with *arbitrary contexts* incuding Staff" [emphasis mine]?!


Unfortunately: see the attached version.

Yes, \lyricsto ChoirStaff actually works to some degree - however, no 
extenders at all are printed with this construct. Extenders /are/ shown 
when lyrics are assigned to a Staff; not sure what the difference is, 
and what needs to be adjusted internally to make it work.
Note that the automatic extender patch is not the culprit; output is 
similar in 2.19.50 except for tiny extenders that are deleted due to 
collapse-length.


Too late now to condense this to a proper bug report - good night...

(Note 1 to whom it may concern, including myself: once this works, the 
satb and ssaattbb templates should be changed to associate the Verse* 
lyrics with the entire ChoirStaff, and *Lyrics with the corresponding 
Staff per default.)


(Note 2 to whom it may concern, including myself: we should have auto 
extender regtests for \lyricsto ctx = name, for at least ctx = Voice, 
Staff, ChoirStaff.)



Cheers,
Alexander
\version "2.19.54"

#(set-global-staff-size 17)

\header {
  title = "As Joseph was A-Walking"
  subtitle = ""
  subsubtitle = ""
  composer = "Trad."
  arranger = "arr. R.R.Terry"
  poet = ""
  revisionDate = \markup {
"4 Dec 2016"  % first draft
  }
}

TwoVoicesPerStaff = ##t

SopranoMidiInstrument = "voice oohs"
AltoMidiInstrument = "voice oohs"
TenorMidiInstrument = "choir aahs"
BassMidiInstrument = "choir aahs"

sd = \once \slurDashed
td = \once \tieDashed

Time = {
  \set melismaBusyProperties = #'()  % turn off auto-melismata
  \time 6/8
  \key ees \major
  \tempo "Andante" 4. = 56
  \repeat volta 2 {
\partial 8
s8 |
s2.*7 |
s4. s4
  }
  \break
  \repeat volta 2 {
s8 |
s2.*7 |
s4. s4
  }
}

SopranoMusic = \relative {
  ees'8 |
  g4 bes8 c4 d8 |
  \sd ees4\=1(\=2( bes8\=1) g4\=2) bes8 |
  c4 ees8 d4 c8 |
  bes4.~ 4 c16( d) |
  \sd ees4( d8) c( d) ees |
  \sd bes4\=1(\=2( g8\=1) ees4\=2) f8 |
  \sd g8\=1(\=2( f\=1) ees\=2) \sd bes'4( g8) |
  ees4.~ 4

  ees8 |
  g4 bes8 c4 d8 |
  \sd ees4( bes8) g4 bes8 |
  c4 ees8 d4 c8 |
  bes4.~ 4 c16( d) |
  \sd ees4( d8) c( d) ees |
  \sd bes4\=1(\=2( g8\=1) ees4\=2) f8 |
  \sd g8\=1(\=2( f\=1) ees\=2) \sd bes'4( g8) |
  ees4.~ 4
}

AltoMusic = \relative {
  bes8 |
  ees4 8 4 f8 |
  \sd g4\=1(\=2( f8\=1) ees4\=2) 8 |
  ees4 8 aes4 8 |
  aes4.( g4) ees8 |
  \td ees4~ 8 ees( f) g |
  \sd f4\=1(\=2( d8\=1) ees4\=2) 8 |
  \td ees4~ 8 \sd d\=1(\=2( c\=1) d\=2) |
  ees4( c8 bes4)

  bes8 |
  ees4 8 4 f8 |
  \sd g4( f8) ees4 8 |
  ees4 8 aes4 8 |
  aes4.( g4) ees8 |
  \td ees4~ 8 ees( f) g |
  \sd f4\=1(\=2( d8\=1) ees4\=2) 8 |
  \td ees4~ 8 \sd d\=1(\=2( c\=1) d\=2) |
  ees4( c8 bes4)
}

TenorMusic = \relative {
  g8 |
  bes4 8 aes 4 8 |
  \td bes4~ 8 4 g8 |
  aes4 g8 aes4 c8 |
  f8.( d16 bes8 ees4) c8 |
  \td bes4~ 8 aes4 bes8 |
  \sd \td bes4~( 8 g4) c8 |
  \sd bes4( g8) \sd aes4( bes8) |
  g4( aes8 g4)

  g8 |
  bes4 8 aes 4 8 |
  \td bes4~ 8 4 g8 |
  aes4 g8 aes4 c8 |
  f8.( d16 bes8 ees4) c8 |
  \td bes4~ 8 aes4 bes8 |
  \sd \td bes4~( 8 g4) c8 |
  \sd bes4( g8) \sd aes4( bes8) |
  g4( aes8 g4)
}

BassMusic = \relative {
  ees8 |
  ees8.( f16) g8 aes8.( g16) f8 |
  \sd ees4( d8) ees4 8 |
  aes,4 c8 f4 ees8 |
  d4.( ees4) aes8 |
  \td g4~ 8 aes4 ees8 |
  \sd d4\=1(\=2( bes8\=2) c4\=1) aes8 |
  \sd bes4( c8) \td bes4~ 8 |
  c8.( bes16 aes8 ees'4)

  ees8 |
  ees8.( f16) g8 aes8.( g16) f8 |
  \sd ees4( d8) ees4 8 |
  aes,4 c8 f4 ees8 |
  d4.( ees4) aes8 |
  \td g4~ 8 aes4 ees8 |
  \sd d4\=1(\=2( bes8\=2) c4\=1) aes8 |
  \sd bes4( c8) \td bes4~ 8 |
  c8.( bes16 aes8 ees'4)
}

VerseOne = \lyricmode {

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

[Alexander Kobel]

On 2016-12-26 00:38, Trevor Daniels wrote:

Alexander Kobel wrote Sunday, December 25, 2016 2:19 PM


But: I cannot imagine a situation where I would not use automatic
extenders, so I'm a really bad person to judge the need and requirements
for a manual mode.


One obvious and fairly common situation is when there are several
verses set beneath a melody line, but with different melismata.  In
this situation is is far easier to disable the automatic detection
of melismata and indicate them in the lyrics with "_".  That will
still work fine, AFAIUI, but equally the extender lines will differ
between the verses and will also need to be indicated manually.  Or
have I misunderstood something?


No need for manual indication. That's just a matter of adding the 
necessary _ for moments without a syllable on their own. Extenders are 
added automatically if and only if necessary.



I attach a recent example - very Christmassy!


Nice one, thanks.
Note that, due to the fixed voice association to soprano in the SATB 
template, you should manually left-align the syllables where the bass 
has 8.( 16).
And I love the fact that lyrics assigned to a Staff instead of a Voice 
(news around 2.19.50) easily allow to align the { King. __ } and { 
mould. __ } to the left e' note of the alto instead of the shifted one 
in soprano...

Sorry, I meant to write { King. } and { mould. }, of course. ;-)


How would this be coded in future?


Find attached the output of 2.19.54 with Knut's patch after
  sed -i -e 's/__ //g' As\ Joseph\ was\ A-Walking.ly
:-)


Cheers,
Alexander
\version "2.19.52"

#(set-global-staff-size 17)

\header {
  title = "As Joseph was A-Walking"
  subtitle = ""
  subsubtitle = ""
  composer = "Trad."
  arranger = "arr. R.R.Terry"
  poet = ""
  revisionDate = \markup {
"4 Dec 2016"  % first draft
  }
}

TwoVoicesPerStaff = ##t

SopranoMidiInstrument = "voice oohs"
AltoMidiInstrument = "voice oohs"
TenorMidiInstrument = "choir aahs"
BassMidiInstrument = "choir aahs"

sd = \once \slurDashed
td = \once \tieDashed

Time = {
  \set melismaBusyProperties = #'()  % turn off auto-melismata
  \time 6/8
  \key ees \major
  \tempo "Andante" 4. = 56
  \repeat volta 2 {
\partial 8
s8 |
s2.*7 |
s4. s4
  }
  \break
  \repeat volta 2 {
s8 |
s2.*7 |
s4. s4
  }
}

SopranoMusic = \relative {
  ees'8 |
  g4 bes8 c4 d8 |
  \sd ees4\=1(\=2( bes8\=1) g4\=2) bes8 |
  c4 ees8 d4 c8 |
  bes4.~ 4 c16( d) |
  \sd ees4( d8) c( d) ees |
  \sd bes4\=1(\=2( g8\=1) ees4\=2) f8 |
  \sd g8\=1(\=2( f\=1) ees\=2) \sd bes'4( g8) |
  ees4.~ 4

  ees8 |
  g4 bes8 c4 d8 |
  \sd ees4( bes8) g4 bes8 |
  c4 ees8 d4 c8 |
  bes4.~ 4 c16( d) |
  \sd ees4( d8) c( d) ees |
  \sd bes4\=1(\=2( g8\=1) ees4\=2) f8 |
  \sd g8\=1(\=2( f\=1) ees\=2) \sd bes'4( g8) |
  ees4.~ 4
}

AltoMusic = \relative {
  bes8 |
  ees4 8 4 f8 |
  \sd g4\=1(\=2( f8\=1) ees4\=2) 8 |
  ees4 8 aes4 8 |
  aes4.( g4) ees8 |
  \td ees4~ 8 ees( f) g |
  \sd f4\=1(\=2( d8\=1) ees4\=2) 8 |
  \td ees4~ 8 \sd d\=1(\=2( c\=1) d\=2) |
  ees4( c8 bes4)

  bes8 |
  ees4 8 4 f8 |
  \sd g4( f8) ees4 8 |
  ees4 8 aes4 8 |
  aes4.( g4) ees8 |
  \td ees4~ 8 ees( f) g |
  \sd f4\=1(\=2( d8\=1) ees4\=2) 8 |
  \td ees4~ 8 \sd d\=1(\=2( c\=1) d\=2) |
  ees4( c8 bes4)
}

TenorMusic = \relative {
  g8 |
  bes4 8 aes 4 8 |
  \td bes4~ 8 4 g8 |
  aes4 g8 aes4 c8 |
  f8.( d16 bes8 ees4) c8 |
  \td bes4~ 8 aes4 bes8 |
  \sd \td bes4~( 8 g4) c8 |
  \sd bes4( g8) \sd aes4( bes8) |
  g4( aes8 g4)

  g8 |
  bes4 8 aes 4 8 |
  \td bes4~ 8 4 g8 |
  aes4 g8 aes4 c8 |
  f8.( d16 bes8 ees4) c8 |
  \td bes4~ 8 aes4 bes8 |
  \sd \td bes4~( 8 g4) c8 |
  \sd bes4( g8) \sd aes4( bes8) |
  g4( aes8 g4)
}

BassMusic = \relative {
  ees8 |
  ees8.( f16) g8 aes8.( g16) f8 |
  \sd ees4( d8) ees4 8 |
  aes,4 c8 f4 ees8 |
  d4.( ees4) aes8 |
  \td g4~ 8 aes4 ees8 |
  \sd d4\=1(\=2( bes8\=2) c4\=1) aes8 |
  \sd bes4( c8) \td bes4~ 8 |
  c8.( bes16 aes8 ees'4)

  ees8 |
  ees8.( f16) g8 aes8.( g16) f8 |
  \sd ees4( d8) ees4 8 |
  aes,4 c8 f4 ees8 |
  d4.( ees4) aes8 |
  \td g4~ 8 aes4 ees8 |
  \sd d4\=1(\=2( bes8\=2) c4\=1) aes8 |
  \sd bes4( c8) \td bes4~ 8 |
  c8.( bes16 aes8 ees'4)
}

VerseOne = \lyricmode {
  \set stanza = "1."
  As Jo -- seph was a -- walk -- _ ing,
  He heard an an -- gel sing, _
  This _ night _ shall _ be born _ _
  Our hea -- _ ven -- ly _ King. _

  \set stanza = "4."
  He nei -- ther shall be ro -- _ cked
  In sil -- ver or in gold, _
  But _ in a woo -- _ den cra -- _ dle
  That rocks _ _ on the mould. _
}

VerseTwo = \lyricmode {
  \set stanza = "2."
  He nei -- ther shall be born _ _
  In hous -- sen nor in hall, _
  Nor _ in the place _ of Pa -- ra -- dise,
  But in _ an ox 's stall. _

  \set stanza = "5."
  He nei -- ther shall be chri -- sten -- ed
  In white wine or in red, _
  But _ 

Re: PATCHES - Countdown for December 24th

[Alexander Kobel]

On 2016-12-25 23:19, Thomas Morley wrote:

2016-12-25 22:46 GMT+01:00 Alexander Kobel <a-ko...@a-kobel.de>:

Hang on - I think you'll need the output of `git format-patch` rather than
`git diff -u`. Here it is...



Indeed, thanks.
Pushed now.


Thanks.


Some tasks todo:
(1) please edit the labels on sourceforge:

labels: --> Fixed_2_19_54
status: Started --> Fixed
Patch: push -->

(2) please close the Rietveld-issue


Done.


Little remark: Please insert the sourseforge-issue-number somewhere in
the commit-message(s). Makes it easier for the bugsquad verifying the
patch(es) and for later research,


Makes sense. I'll try to remember next time.


Cheers,
Alexander

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

Re: PATCHES - Countdown for December 24th

[Alexander Kobel]

On 2016-12-25 19:48, Urs Liska wrote:

Am 25.12.2016 um 14:22 schrieb Alexander Kobel:

Hi all,

On 2016-12-24 17:32, James wrote:

Push:
[...]
5010 add choral and choral-cautionary accidental style - Alexander Kobel
https://sourceforge.net/p/testlilyissues/issues/5010
http://codereview.appspot.com/311430043


Does this require any action from my side? I doubt that I have write
access to the repo...


You could just try out ..


Well, sure; let me rephrase that "question". ;-)

[...] Bogus stuff about my anonymously made clone, not knowing how to 
authenticate if my recently made Allura account comes with push rights, 
etc... [...]


Whoops, found it - CG 3.4.9. So no, I don't have a Savannah account, 
even less one that is granted any rights. No reason to change that; my 
activity will remain scarce.



But if you don't have push access the "action" required by you is
basically stating that and asking for someone to push your patch.
Which I would do if I could reliably say I'll manage to do so before I
will have forgotten about the task.

So I have to pass the task on to someone else.


No worries - I sent it to Harm.


Thanks!
Alexander

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

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

[Alexander Kobel]

Hi all.

On 2016-12-25 13:14, Noeck wrote:

As extender events are generated automatically now it probably is a
good idea to tell yacc / bison to recognize but ignore "__" tokens.


I don't know at which level the __, \overrides and the automatic
extenders interact. But would it make sense to use __ now, to force an
extender e.g. on a single long note?
__ would probably look nicer than the much longer \override.


I just had the same idea.  That'd essentially mean that "manual mode" 
(\autoExtendersOff) falls back to the old behaviour (+/- collapse-length 
vs. minimum-length).


On the other hand, if __ were to be interpreted both as standard 
extenders in manual mode and as forced extenders in both modes, we'd 
have to re-decide whether forced ones should be subject to 
collapse-length (if they occur on natural melismata).
If yes, lyrics in both modes are compatible, but there can be explicitly 
written extenders that are not printed.  (This could be remedied by 
setting the collapse-length default to 0 in manual extender mode, but 
I'm not sure if there is a sane way to do this.)


Also, if __ forces extenders, it might impact the re-usability of manual 
mode-lyrics for different voices (melisma on some syllable in voice A, 
but not in voice B).  And I'm not sure whether I like different meanings 
of __ in manual and auto mode.  How do we want the following to be 
interpreted?


raw = \lyricmode { Foo bar __ baz! __ }
{ c'8~ 8 8~ 8 2 }
\addlyrics \raw
\addlyrics { \autoExtendersOff \raw }

Would this even be a valid use of \autoExtendersOff?  Should both lyric 
lines be the same or not?


But: I cannot imagine a situation where I would not use automatic 
extenders, so I'm a really bad person to judge the need and requirements 
for a manual mode.



One drawback might be, that old scores have forced extenders then (if
not treated by convert-ly - but without convert-ly other things are
wrong, too).


Old scores will be either mostly okay or severely "harmed":

If extenders have been used everywhere they belong, nothing will change 
- except that some really small ones might not be printed due to the new 
rules for collapse-length (which actually fix the previous behavior of 
minimum-length to match its definition).
If extenders have not been used, they will be added, but only in places 
where they should have been used in the first place (fine), or across 
large regions where the should not appear (divisi lyrics situation; bad).


The latter should be immediately obvious and is easy to fix both 
manually or by convert-ly.  I expect that most scores will be of the 
former type.


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

Re: PATCHES - Countdown for December 24th

[Alexander Kobel]

Hi all,

On 2016-12-24 17:32, James wrote:

Push:
[...]
5010 add choral and choral-cautionary accidental style - Alexander Kobel
https://sourceforge.net/p/testlilyissues/issues/5010
http://codereview.appspot.com/311430043


Does this require any action from my side? I doubt that I have write 
access to the repo...



Cheers,
Alexander

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

Re: Delete new LSR-snippet?

[Alexander Kobel]

On 2016-12-23 20:48, Trevor Daniels wrote:

I seem to remember a post or maybe an LSR entry for placing
divisi arrows at the end of a staff.  Maybe this could be
adapted to achieve the same effect more reliably?

Found it  - LSR 650.  It modifies the barline stencil.


IIRC: How come that a bunch of people digs out my ancient snippets these 
days? ;-)



Hope it helps!
Alexander

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

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

[Alexander Kobel]

Dear all,

I just uploaded Knut's patch (with minor reformatting, to obey the 
80-char-per-line limit) to Rietveld; see

  https://codereview.appspot.com/313240043
The corresponding issue can be found at
  https://sourceforge.net/p/testlilyissues/issues/5018/

Thanks again Knut for this great contribution!


Since I assume that most of you will devote the next 72 or so hours to 
other stuff than Lily: merry holidays to all of you!



Cheers,
Alexander


On 2016-12-22 15:26, Alexander Kobel wrote:

On 2016-12-22 14:53, Knut Petersen wrote:

Hi Alexander et al.!

how about putting the patch on Rietveld?


I agree that this should go into a normal patch review process
now. Knut, are you familiar with the git cl proceedings? If not,
it’s explained in the CG 1.3 and 2.3.


+1. Let us know if you need help. I went through the procedure just
a few days ago, so my knowledge is scarce, but fresh.


As I will not do it anybody is invited to put that patch on
Rietveld. You might call me pigheaded, but I don't accept to be
forced to use a google account. Of course I will react to any
reasonable change request.


I get your point. I dislike it as well, but gave in to the pressure (not
here, but elsewhere) long ago. I try to keep contact data and calendar
away from the big G as much as possible, and only use the mail address
to forward to another, but still. Go{d,ogle} alone knows what they
harvest...

Anyway, I can take care of uploading the patch. Will do so in the
evening, most probably.


Cheers,
Alexander

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


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

Re: [PATCH] Automatic lyric extenders

[Alexander Kobel]

On 2016-12-22 14:53, Knut Petersen wrote:

Hi Alexander et al.!

how about putting the patch on Rietveld?


I agree that this should go into a normal patch review process
now. Knut, are you familiar with the git cl proceedings? If not,
it’s explained in the CG 1.3 and 2.3.


+1. Let us know if you need help. I went through the procedure just
a few days ago, so my knowledge is scarce, but fresh.


As I will not do it anybody is invited to put that patch on
Rietveld. You might call me pigheaded, but I don't accept to be
forced to use a google account. Of course I will react to any
reasonable change request.


I get your point. I dislike it as well, but gave in to the pressure (not 
here, but elsewhere) long ago. I try to keep contact data and calendar 
away from the big G as much as possible, and only use the mail address 
to forward to another, but still. Go{d,ogle} alone knows what they 
harvest...


Anyway, I can take care of uploading the patch. Will do so in the 
evening, most probably.



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-21 17:05, tisimst wrote:

On Wed, Dec 21, 2016 at 5:22 AM, Alexander Kobel-2 [via Lilypond] <
ml-node+s1069038n198284...@n5.nabble.com> wrote:

On 2016-12-20 17:21, Abraham Lee wrote:

Maybe the question I really have is this: what does "given this
length _if possible_" mean and what governs this possibility? I
can totally understand how they work individually, I'm just
trying to understand how I can use them well together since it
seems that forced-length contradicts collapse-length.


You won't really use them together; at least, not both will be effective
at the same time:
(1) If the natural length (essentially: the distance from the right end
of the syllable to the right end of the last note in the corresponding
melisma) is less than collapse-length, this extender will not be printed.
(2) If you /force/ an extender, that is, you explicitly add one for a
syllable that does not belong to a melisma, there is no "natural length"
- simply because there is no "natural extender". The "faked" length of
such an extender will be given by the minimum of forced-length and the
available space to the next syllable. Again, this will not affect the
space between the notes.

Forced extenders should only be necessary under extraordinary
circumstances, such as an extender reaching into a alternative ending of
a repeat, re-extending after rests, or even more obscure design studies.


Ah! I understand now. Thank you for explaining that. So, it's "Force an
extender to appear if there is sufficient space (i.e., at least as much as
"collapse-length"), even in places they wouldn't normally be used."


No, it's just "force an extender to appear even in places they wouldn't 
normally be used".



Is that right? If so, then I think "forced-length" is not the right name for it.
Perhaps just "force" or "force-all"? Or is forced appearance not subject to
"collapse-length"?


The latter. It is well possible (and reasonable, given that you need 
forced extenders at all) to set collapse-length > forced-length. You 
explicitly ask for an extender to be printed, so you would not want it 
to be collapsed again.



Cheers,
Alexander

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

Re: [PATCH] Automatic lyric extenders

[Alexander Kobel]

On 2016-12-22 13:03, Simon Albrecht wrote:

On 22.12.2016 02:17, Thomas Morley wrote:

2016-12-22 1:33 GMT+01:00 Knut Petersen:

Hi everybody!

Attached find a new version of the patch.
Please test. Read the updated manuals.

Feel free to provide corrections and translations!

cu,
  Knut


Hi Knut,

how about putting the patch on Rietveld?


I agree that this should go into a normal patch review process now.
Knut, are you familiar with the git cl proceedings? If not, it’s
explained in the CG 1.3 and 2.3.


+1. Let us know if you need help. I went through the procedure just a 
few days ago, so my knowledge is scarce, but fresh.


That being said, I have a question left: is it possible to automatically 
checkout a Rietveld patch set to a new branch (via git and/or git-cl), 
or does one have to manually download and apply the patch set?



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-20 14:16, Knut Petersen wrote:

I still have one problem:

\score {
%\displayMusic
  <<
\new Voice = "singleVoice" {
\relative {
  a'4 a a a
  \repeat volta 3 { b4 b b b }
  c4 c c c
   }
}
\displayMusic \new Lyrics \lyricsto "singleVoice" {
  Not re -- peat -- ed.
  <<
{ The first time words.}
\new Lyrics { \set associatedVoice = "singleVoice" Sec -- ond
time  words. #(make-music (quote CompletizeExtenderEvent)) }
\new Lyrics { \set associatedVoice = "singleVoice" The third
time words. #(make-music (quote CompletizeExtenderEvent)) }
  >>
}
  >>
}

I would like to see a CompletizeExtenderEvent automatically generated at
the places indicated above ... I think that this could be possible in the
add-lyrics code defined at the end of scm/ly-syntax-constructors.scm.
Any ideas how to change the code there?


Hi Knut,

not really an idea here. I was not even aware that a 
CompletizeExtenderEvent exists...


W.r.t. the << >> issue, not sure whether this is an intended and 
supported functionality. I'm afraid that it might just work "by 
accident". Note that
a) the music expressions for second and third repeat in your example are 
not of type LyricCombineMusic,
b) that the \set associatedVoice does not seem to do what you think it 
does (try to add a different voice with a different rhythm, and you'll 
find that the lyrics still align to "singleVoice"), and

c) that, consequently, there is a difference between
  \new Lyrics { \set associatedVoice = "..." { ... }
and
  \new Lyrics \lyricsto "..." { ... }
inside << >>.

Given enough time, I should be able to figure out a Scheme workaround 
that involves promoting the level of the inner expressions. But I'm 
afraid it will be ugly and probably not very robust; I can translate the 
expression from one form to the other, but without understanding its 
meaning and implications entirely.
Is there anyone who can comment on the side effects of using this 
construct, and whether and how it is supposed to work?



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-20 17:21, Abraham Lee wrote:

Yes, thanks for making this possible! It will be a great addition.


Thanks Abraham.


One question I have about having the two properties is how will the two be
reconciled in actual use? In other words, if collapse-length is larger than
forced-length, will there still be the same amount of space between
syllables even without the extender (to the amount of forced-length)?


One thing remains identical to the current situation: Extenders never 
ever influence horizontal spacing.



Maybe the question I really have is this: what does "given this length _if
possible_" mean and what governs this possibility? I can totally understand
how they work individually, I'm just trying to understand how I can use
them well together since it seems that forced-length contradicts
collapse-length.


You won't really use them together; at least, not both will be effective 
at the same time:
(1) If the natural length (essentially: the distance from the right end 
of the syllable to the right end of the last note in the corresponding 
melisma) is less than collapse-length, this extender will not be printed.
(2) If you /force/ an extender, that is, you explicitly add one for a 
syllable that does not belong to a melisma, there is no "natural length" 
- simply because there is no "natural extender". The "faked" length of 
such an extender will be given by the minimum of forced-length and the 
available space to the next syllable. Again, this will not affect the 
space between the notes.


Forced extenders should only be necessary under extraordinary 
circumstances, such as an extender reaching into a alternative ending of 
a repeat, re-extending after rests, or even more obscure design studies.



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-16 19:13, Knut Petersen wrote:

[...] Have a look at the attached ly and the generated pdf ... and
comment on the chosen names and syntax. It should be
self-explanatory. [...]


One more idea (and I feel a bit bad for asking, since I dump the hard 
work on you again - not sure if I'm able to help):


W.r.t. the extenders to the second repeat alternative: spanners have the 
to-barline property that alleviates the need for manual length tweaks in 
such situations. Do you think it's possible with reasonable effort (in 
particular, reusing the code and/or strategy from spanners) to achieve 
the same effect for extenders? Such that, e.g., in your last example


\repeat volta 2 { b'4 b ~}
\alternative { { b b } { b \repeatTie c } } c4 c

\lyricsto "melody" { Here's a verse. "" "" }
\lyricsto "melody" { Here's \once \override LyricExtender.to-barline = 
##t one "" \earlyExtender #-6 more to sing }


would mean that the extender after "one" (that usually extends to the 
first note in the first alternative) would be stopped earlier, exactly 
at the barline? (Of course, in an ideal world, the "early extender" 
would have a corresponding from-barline property, but I don't think we 
have any example of such a functionality that we can rely on.)



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]

Hi all,

On 2016-12-16 19:13, Knut Petersen wrote:

Hi Paul, Alexander et. al!

I need to be very short as a rehearsal is waiting.


same here - I was and still am busy with pre-christmas performances.


I'd advocate to keep minimum-length.


I second the vote for collapse-length.

(I agree with you that minimum-length is not a bad name per se, but the 
meaning is different for spanners and extenders. For spanners, the 
description of the property and its functionality matched way better in 
the past, and users are more aware of that meaning. Now that extenders 
will be auto-generated, it's even more crucial than before that we avoid 
confusion.)



I also need some way to force an extender and to inhibit extender
generation.
Forcing an individual extender should overrule a general inhibition of
extenders.
Details can be hidden by some music functions ... but there's not time
to generate a patch now.

Have a look at the attached ly and the generated pdf ... and comment on the
chosen names and syntax. It should be self-explanatory.


It is to me. Thanks.

Nevertheless, I guess we are at a point where we get an evaluation of 
the syntax and behavior by some people that have not been as involved in 
the feature development as we've been. I have a blind spot for any 
decisions on syntax as soon as I internalized what the engraving result 
will be.



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]

Hi Paul.

On 2016-12-16 16:02, Paul wrote:

Hi Knut and everyone,

Great to see your work which seems like a nice improvement.  I just have
some thoughts on the implementation / use of properties.

We are just talking about grob properties and not context properties
right?  In that case no need to also create context properties as you do
in your patch, since the grob properties are sufficient.


Yes, I think that's a general agreement now. AFAICS, the idea of context 
properties quickly vanished after we recognized that we can get rid of 
__ (or ExtenderEvents) entirely, at least as far as the user is 
concerned. They are now more like an implementation detail for no-extender.



What about a way to do this with fewer than 3 separate grob properties?

LyricExtender.minimum-length
LyricExtender.no-extender
LyricExtender.force-extender

If I understand correctly, only 1 of 3 kinds of behavior can be in
effect at a given point:

1. no extensions
2. forced extensions
3. automatically added extension depending on a 'minimum-length' number


Not quite. I can imagine that no-extender and force-extender could be 
combined. E.g., as create-extender = { one of #'auto, #'never, #'always }:


#'auto means the default: create extenders on melismata and nowhere else.
#'never means: create no extenders, period.
#'always means that extenders are enforced even on non-melismata (where, 
by definition, there should not be an extender; but there are situations 
where it makes sense to overwrite it; e.g., for a continuation of an 
extender in a second volta repeat, or in divisi lyrics).


Minimum-length [2] is orthogonal - it is more concerned with the layout. 
With some reasonable minimum-length, extenders that reduce to mere 
flyspecks are hidden. This happens often in somewhat dense choral 
settings: the extender is not printed if the syllable text is almost as 
wide (or even wider) than the distance between the respective noteheads. 
It's a threshold value that tells which existing extenders will be 
printed and visible. [1]
But this decision entirely depends on horizontal spacing, and will vary 
with line breaks, other voices, etc. IMHO, that's a whole different 
quality of a variable than the previous one (existence vs. appearance). 
And the general design principle throughout Lilypond is to separate 
semantics from layout as much as possible.


[1] One exception: on forced extenders on non-melismata (which do not 
have any natural length, obviously), minimum-length will not serve as a 
threshold, but to /set/ the length.


[2] Side Note: other proposed names for minimum-length so far:

(1) minimum-space
(2) show-length
(3) hide-below-length
(4) hide-if-shorter-than
(5) minimum-visibility
(6) visibility-threshold
(7) printing-threshold
(8) extender-threshold



So why not one grob property (name to be determined) that can be a
boolean or a number:

LyricExtender.extenders = ##f   % no extensions
LyricExtender.extenders = ##t   % forced extensions
LyricExtender.extenders = 2% a number, auto extensions

For example, it could be set to a number and then use \once to set it to
##t to force (or ##f to suppress) a given extender.


See [1] above; we need to be able to specify a length for forced 
extenders (that do not have a natural length because there's only one 
note). Yes, something like extenders = #'(forced? length) with a boolean 
for forced? and a number for length would be sufficient (note that #'(#f 
+inf.0) amounts to #'never...), but that's quite opaque.



Another possibility (2 properties) might be:

LyricExtender.stencil = ##f% no extensions
LyricExtender.force-extender = ##t  % forced extensions
LyricExtender.minimum-length = 2% auto extensions (if force-extender
is not ##t and stencil is not ##f)


Yes, that'll work: stencil = ##f means #'never; stencil = ##t and 
force-extender = ##t means #'always; and stencil = ##t and 
force-extender = ##f means #'auto.
However, I personally dislike to touch stencil. That's my last resort, 
but it feels hacky; IMHO stencil is a more or less internal layout 
procedure, and I should not have to abuse it for semantic purposes 
(i.e., #'never).



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-16 15:20, Urs Liska wrote:

Am 16. Dezember 2016 15:11:59 MEZ, schrieb David Nalesnik 
:

On Fri, Dec 16, 2016 at 8:07 AM, Knut Petersen [...]

(define-public (forceExtender)
  (once (overrideProperty '(LyricExtender force-extender) #t)))

into scm/music-functions.scm, lilypond does know \forceExtender ...
but it complains about a "non-music expression" if it is used ...


Ah, this one. You explicitly have to create a music function. Maybe

https://scheme-book.ursliska.de/scheme/music-function-primer.html

helps you?


Oh, that looks nice... I need to spend some time on that one.


But you can say

(define forceExtender (define-musi-function ...


(define forceExtender
 (define-music-function () ()
  (once (overrideProperty '(LyricExtender force-extender) #t

should work, yes. But I think David's suggestion is even easier and 
recommended. Note that

  fgrep define-music-function scm/*
gives a pretty short list of 4 hits, and 2 of which are in the 
definition of define-music-function itself. And

  fgrep define-music-function ly/* | wc -l
shows a count of 131...


If you are defining a music function, do it in
ly/music-functions-init.ly,


In a .ly file (which is processed with all the syntactic sugar that 
Lilypond has to offer) you can simply write

  forceExtender = \once \override LyricExtender.force-extender = ##t
and that's it.
By the way, for the sake of consistency with other commands (except, 
maybe, \hideNotes and \unHideNotes): My preferred choice of names would be

  forcedExtendersOn  = \override LyricExtender.force-extender = ##t
  forcedExtendersOff = \override LyricExtender.force-extender = ##f
and a user can prefix a \once if necessary. (Unless someone comes up 
with an apt antonym of "force" here - free, release, permit don't sound 
sound...)



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]

Hi all.

I second Werner's opinion that the goal should not necessarily be an 
identical score, but a reasonable one. This time, we could even hope for 
improvements: there will be some valid extenders that users simply did 
not bother (or did not know how) to add, and I think convert-ly should 
not try to hide them.


On 2016-12-15 23:41, Knut Petersen wrote:

Am 15.12.2016 um 19:29 schrieb Werner LEMBERG:

We have convert-ly exactly for such changes.

I doubt that all corner cases like the Issue 1006 update given in
lyrextest.ly can be handled automatically ...

???

s/LyricExtender.minimum-length/LyricExtender.whatever-you-want/


Yes, that would be easy.


I also second Werner's though that minimum-length is not the best 
description. In the context of spanners, it means "widen the score such 
that this spanner has length at least x"; quite different from the new 
meaning "suppress below length x" (remember that extenders never 
influence spacing).
However, I dislike both minimum-space (it's not about widening so that 
there is enough space, either; plus this term is already used with a 
different meaning) and show-length (which sounds like a debug option 
that prints or annotates the length).

What about hide-below-length or hide-if-shorter-than?


What I meant is that I do believe that it is impossible to
mechanically translate an old score to give exactly the same result
with the new code. Let's try to start.


See above; I don't think this was Werner's point.


We do not need "__", so eliminate it:  sed -e "s/__//g"


Not sure if we should do that. Any __ in the lyrics don't do harm, and 
it keeps the source somewhat backwards compatible.



Ok, that looks good. But wait: There is a melisma,


Which convert-ly is unable to detect, unless there are _ in the lyrics. 
Other than that, melismata detection requires full parsing and 
interpretation, which is beyond the scope (and intention) of convert-ly.



[...] Is convert.ly intelligent enough to handle that problem
correctly? I doubt that although I admit that I never had a look at
the code.


AFAICS, it's a slighly more fancy grep. Pure pattern substitution. So I 
share your doubts.



There is one way we could stay compatible: Keep the old code and use it for
every score with a \version < X , enable the new code for \version >= X.


My KISS proposal:
(1) Keep lyrics sourcecode as-is in general (don't remove __),
(2) replace LyricExtender.minimum-length by 
LyricExtender.whatever-it-will-be, and

(3) replace all 'pattern _ ' by 'pattern "" ' where pattern != _ or __.
The latter rule will miss out opportunities to create some forgotten 
extenders for manual melismata, but it is crucial to leave non-trivial 
divisi lyrics in a reasonable shape (see my mails from 2016-12-14 2:39pm 
and 2016-12-15 1:04am UTC+1).



Gute Nacht!
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

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: 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]

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: music function to be included somewhere in scm/*

[Alexander Kobel]

On 2016-12-14 19:46, Knut Petersen wrote:

Am 14.12.2016 um 18:03 schrieb Simon Albrecht:

On 14.12.2016 14:54, Knut Petersen wrote:

With a music function \autoextenders that adds extender events to
every syllable you
- can be sure never to forget extenders,
- can be sure never to generate too short extenders
- can use the same lyrics definition for voices that require
extenders at different places.

Nobody is forced to use \autoextenders, manual definition is still
possible.


Would it be possible/wanted to have this triggered by a context
property as well? I for one would prefer that, it’s easier to use.


LyricEvents are generated by the following code in music-functions.scm:

(define-public (make-lyric-event string duration)
  (make-music 'LyricEvent
  'duration duration
  'text string))

Here only a few lines of code are enough to add LyricExtender events for
every syllable by default.


Yes. In fact, it's more straightforward to add it here than with the 
extra music function.
Not sure how a context property would come into play here; I guesss 
that'd mean that make-lyric-event branches on a variable named, say, 
autoAddExtenders, and adds an ExtenderEvent if and only if it is set to 
#t? Not sure how to code that part, but it seems plausible that we can 
make that work.



Of course we  would need to disable the warning about more than one
extender event.


And we might need to offer a way to remove a LyricExtender event. Unless 
we go the radical route and ...



But do we want to enable lyric extenders by default?


... have them enabled by default, get rid of ExtenderEvent entirely, and 
just assume it's there for every syllable, unless there is a HyphenEvent 
(any use case for hyphen + extender?). If a user doesn't want it, we 
need to provide a function \extenderOff (that translates, e.g., to 
\override LyricExtender.stencil = ##f).
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.



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]

On 2016-12-14 23:13, thomasmorle...@gmail.com wrote:

Worth an entry in changes?


Maybe. Doesn't need a lot, I guess; something like
"Accidental rules can now be defined across ChoirStaff contexts. Two new 
rules choral and choral-cautionary are available that combine the 
characteristics of modern-voice and piano or their equivalents with 
cautionary accidentals."



Some wording-nitpicks, otherwise
LGTM


Thanks.


https://codereview.appspot.com/311430043/diff/1/Documentation/notation/pitches.itely#newcode2210

Documentation/notation/pitches.itely:2210: style. It is intended for
editions that are used both by singers that only
The wording feels not very elegant.
Though, I'm a non-native speaker...


Not a native speaker here, either, so I'm open to proposals.


https://codereview.appspot.com/311430043/diff/1/scm/music-functions.scm#newcode1847

scm/music-functions.scm:1847: ;; that the first alteration within a
voice (as opposed to on the
wording again, maybe:
Similar to piano, except that the first alteration within a voice is
always printed (as opposed to within a staff).


Agreed, that sounds better.


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-14 21:36, Noeck wrote:

Hi Alexander,

in your example, the last line is just a mockup, isn't it? It is not
done by the proposed function? The extender after "We" in the last line
is unexpected for me.


Hi,

not a mockup, but not the real thing either. I sent this from a PC with 
the "official" unstable version, without Knut's modification, and I did 
not fake the effect of the patch.

With Knut's proposed addition, it looks as attached (and as you expect).


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 (issue311430043 by perpeduumimmob...@gmail.com)

[Alexander Kobel]

Hi Trevor,

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.



Cheers,
Alexander


On 2016-12-14 16:28, Trevor Daniels wrote:


Alexander, you wrote Wednesday, December 14, 2016 12:32 PM


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


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.


AFAICS you don't have developer status at SourceForge.  Have you
ever asked to be added as a developer?  That would explain
the failure.

To fix it please send me (or post to the list) your SourceForge
identifier and I'll add you.

Trevor



___
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: 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 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: 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: 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 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 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: 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: 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: 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: 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: 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: 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: 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: 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

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: 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

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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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

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: 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