Re: unsafe caching of .fmt files
Hi Han-Wen - neither fmt generation nor any other runtime generation has ever been parallel-safe. Even if I added locking to mktexfmt (I guess you are making use of the dynamic fmt creation), something I am not at all anxious to do, the failed simultaneous runs that would result doesn't sound like a good outcome for you. Instead, I think you need to generate the formats you need before starting the parallelism, either with multiple mktexfmt foo.fmt calls or fmtutil-user (or fmtutil-sys, but if you want ~/.texlive2019 to be used instead of /usr/local/texlive/... or whatever, that sounds like fmtutil-user), depending on your needs. Indeed, in this situation, I also suggest that you explicitly disable any mktex* creation. MKTEXFMT=0; export MKTEXFMT; MKTEXTFM=0; export MKTEXTFM; MKTEXMF=0; export MKTEXMF; MKTEXPK=0; export MKTEXPK Alternative: you could set TEXMFVAR or TEXMFSYSVAR to a per-process directory. But then every TeX run will need to create its own .fmt, which sounds like an awful waste of time. --best, karl.
Re: Using/requiring Cairo
David Kastrup: ... > I don't see myself able to deal with all potential icky graphics code in > LilyPond, and I don't see anybody else stepping up either. ... Just for the record, I'm interested in icky graphics code. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Using/requiring Cairo
David Kastrup: ... > Han-Wen Nienhuys writes: ... > > I would be much more supportive if you could show some numbers where > > memory/CPU is used right now, and could show some data how much Cairo > > would improve on things. It's quite possible that you are right, but > > then it should be easy to come up with some supporting data. > > I'm at a loss here how to arrive at such data without doing the actual > work. ... There is a project that did a similar switch in nov. 2013, and they use c + guile, so there are some similarities: http://git.geda-project.org/geda-gaf/ in commit be4ed1c509e9cd808222f7e32e6ee2e602f58662 Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB Ghostscript 9.21
Phil Holmes: ... > /usr/bin/ld: cannot find -lfreetype ... ld cannot find libfreetype.so Do you have it installed ? Try this: $ locate libfreetype.so ... /usr/lib/i386-linux-gnu/libfreetype.so /usr/lib/i386-linux-gnu/libfreetype.so.6 /usr/lib/i386-linux-gnu/libfreetype.so.6.8.1 ... Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Using/requiring Cairo
David > k...@aspodata.se writes: > > Werner: ... > >> > And my interest was in reading pdf's, so I can write programs to > >> > extract the info I want from pdf's. > >> > >> Have you tried `pdftk' to uncompress a PDF file? It's then almost as > >> readable as a plain PS file (see attachments). > > > > No, it looks promising, thanks, now I have to find out how it does > > that. Found out that there is no public source: https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/ it is based in iText lib, which (or OpenPDF) I could use if I want to use java. I could possible use svn co http://svn.code.sf.net/p/podofo/code/podofo/trunk podofo or try to desciffre libpoppler. > Depending on what "Extract the info you want from PDFs" means, pdf2dsc > can be quite handy. Thanks, but it is not helping. I want to find lines and text in pdfs, to basically identify tables. Since pdf is not much more structered than ps I have to use clever thinking. If you really want to help have a look at: http://aspodata.se/git/openhw/pdftosym/pdfextr.pl My point was: > > Though, my conclusion was that pdf is not better than ps regarding > > postprocessing, and yes I know that pdf (depending on pdf version) has > > some features that ps don't have. > > But nobody is talking about PDF. You seem to have a short memory, from your initial message: last time I looked at Cairo, its PDF generation was not really suitable ... We might also be able to forego creating PostScript as an intermediate stage to creating PDF and create bitmap formats without using PostScript as well (again, this should really speed up things). > The difference in question is > Cairo-generated PostScript vs the PostScript generated by Scheme > programming and LilyPond's music-drawing-routines.ps and encodingdefs.ps > . The Cairo-generated ps is much less readable than lilyponds. If you wanted to get rid of the lilyponds own generation of PS, I offered my help to get it up to speed instead, but you didn't understand that since: > >> "taking care of PostScript" is not related to converting LilyPond's > >> graphics internals to Cairo since LilyPond's graphics internals are > >> not written in PostScript. You are obviously not understanding my offer and your mind is set on using cairo instead. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Using/requiring Cairo
Werner: > >> "taking care of PostScript" is not related to converting LilyPond's > >> graphics internals to Cairo since LilyPond's graphics internals are > >> not written in PostScript. > > > > Ok, forget it then, you are not listening. [...] > > Why such a hostile tone, Karl? There is no reason for this. No, that is not a hostile tone, it's a tired tone. > I have to agree with David: While having well readable PS is nice, > this is just a by-product of the conversion process from a .ly to a > .pdf file. Essentially, the formatting of the PS stuff is of *no > importance* to a vast majority of users. I don't argue about that, save if you just want the ps file. > > I use the PS as is, [...] > > So tell us what you are doing with the PS stuff. Mostly the same thing you do with your pdf's, I guess, like psnup, psselect, pstops, a patched version of psbook (so the paper curves the right way when I fold them out of the printer), includegraphics from latex, and probably some more. And my printers doesn't take pdf. > > And my interest was in reading pdf's, so I can write programs to > > extract the info I want from pdf's. > > Have you tried `pdftk' to uncompress a PDF file? It's then almost as > readable as a plain PS file (see attachments). No, it looks promising, thanks, now I have to find out how it does that. Though, my conclusion was that pdf is not better than ps regarding postprocessing, and yes I know that pdf (depending on pdf version) has some features that ps don't have. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Using/requiring Cairo
David Kastrup: > k...@aspodata.se writes: > > David Kastrup: ... > "taking care of PostScript" is not related to converting LilyPond's > graphics internals to Cairo since LilyPond's graphics internals are not > written in PostScript. Ok, forget it then, you are not listening. ... > When processing in general will get moved to Cairo, ... You make it sound like it is already decided. ... > > PostScript is a programming language suited for printing and other > > things. Why youldn't I like to have that readable and understandable > > like any other code ? > > Because it is employed as an intermediate format not intended for human > consumption and manipulation? It's similar to the role of LilyPond in a > Denemo workflow. It's nice for debugging when it's somewhat readable, > but the files created in it are ephemeral. ... Fine, I also want them to be easy to debug. PS is not ephemeral for me. ... > You are not supposed to get started at writing PDF. Instead the PDF > gets written by programs. You are fine with letting your PDF be written > by Ghostscript rather than LilyPond and not looking at it. What is the > difference with PostScript in your workflow that makes it different? You don't listen, I use the PS as is, not doing any conversion to pdf unless someone else wants them. And my interest was in reading pdf's, so I can write programs to extract the info I want from pdf's. I took up the subject to show that the goal of computer-readability and processability is not reached. > > I have tried to find some free lib to use to read pdf's, if you know > > of one please tell me, preferable for perl. > > libpoppler? Yes, but it is barely documented, makes it hard to use. > > Currently I'm using "pdftohtml --xml", but there is a few things > > missing with that solution. > > > > I know about poppler, citing: > > https://freedesktop.org/wiki/Software/poppler/ > > // > > Documentation > > > > There is currently very little documentation. > > // > > > > Soo, the computer-readability is a nice goal, but not so much > > attained. > > Well, there isn't a free lib for reading PostScript, is there? I do have an editor. > I mean, how much is ps2pdf documented? ... Ok, you don't know then, so much for computer-readability and processability. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Using/requiring Cairo
David Kastrup: > k...@aspodata.se writes: > > > Han-Wen Nienhuys: > >> On Sat, Jun 24, 2017 at 12:43 PM, David Kastrup wrote: ... > > If no one else like to care for postscript, I can step in to handle it. > > I don't know what that means. It's like english, I am willing to take care of something related to the programming language PostScript, so we don't need to convert to cairo. > My proposed migration plan would not have > changed the PostScript backend at first, but it certainly would have > been slated for eventual retirement. And I more or less said that I didn't like the retirement thing. If you already decided to switch to cairo, then fine, tell us so we can stop this discussion. > >> > We might also be able to forego creating PostScript as an > >> > intermediate stage to creating PDF and create bitmap formats > >> > without using PostScript as well (again, this should really speed > >> > up things). > > > > I use PS as the final format. Cairo can export to postscript but it's > > PS is not nice to read, lilypond PS is much better in that respect. > > PostScript is not intended to be human-readable rather than > human-writable and streamable, PostScript is a programming language suited for printing and other things. Why youldn't I like to have that readable and understandable like any other code ? > two characteristics PDF no longer cares > about in return for better computer-readability and processability. PDFReference16.pdf is 1236 pages long and is no easy read. The first version of the green/blue/red book was good at getting you started at postscript, do you have any similar doc to get you started at pdf ? Yes, they say that pdf it is for better computer-readability and processability, but it isn't a stable interface, things are being added which breaks some viewers, and fonts are still missing in some cases, which was a point going from ps to pdf. In contrast to ps which has a stable interface/reference, PLRM3 is first printed 1999 and still in effect. I have tried to find some free lib to use to read pdf's, if you know of one please tell me, preferable for perl. Currently I'm using "pdftohtml --xml", but there is a few things missing with that solution. I know about poppler, citing: https://freedesktop.org/wiki/Software/poppler/ // Documentation There is currently very little documentation. // Soo, the computer-readability is a nice goal, but not so much attained. ... > That makes it a lot less likely to be > suitable for mechanical processing (like using "Tailor") than PostScript > generated from a general-purpose representation with commonly used > toolkits. ... Ok, stop bullshitting. Both ps and pdf are a "general-purpose representaion", both have "commonly used toolkits", and both are suitable for "mechanical processing" (by e.g. a printer). What is "Tailor" in this context, I don't understand what you mean by that ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Using/requiring Cairo
Han-Wen Nienhuys: > On Sat, Jun 24, 2017 at 12:43 PM, David Kastrup wrote: > > What does that mean? Mainly a viable migration strategy where we might > > be able to drop catering for a whole lot of graphics programming > > ourselves by introducing a dependency on Cairo. I am not overly > > what "catering for graphic programming" mean? There is graphical > programming, but a lot of it is done already. Moving towards a new > library will be a big undertaking, so it could use more justification. ... > > It would be a large amount of work to bring LilyPond's graphics > > programming up to scratch. Moving to Cairo's data structures alone > > would be quite advantageous and would likely speed up backend operations > > significantly. > > which ones? In terms of graphics, the backend just does interval > unions and offsets (floating point comparisions and additions) through > the Stencil object. Unless you also restructure how objects are > grouped, it's going to be similar. If no one else like to care for postscript, I can step in to handle it. > > We might also be able to forego creating PostScript as an intermediate > > stage to creating PDF and create bitmap formats without using PostScript > > as well (again, this should really speed up things). I use PS as the final format. Cairo can export to postscript but it's PS is not nice to read, lilypond PS is much better in that respect. ... > > Drawbacks? Like other things, being on Guile-2.x would make for > > synergies with existing projects (not least of all guile-cairo though I > > haven't checked its suitability in general, with the new PDF-level > > features, and possible compatibility with Guile-1: I think it supported > > Guile-1 at some point of time). http://git.savannah.nongnu.org/cgit/guile-cairo.git/tree/README Build dependencies == * Guile 1.8.0 or newer http://www.gnu.org/software/guile/ * Cairo 1.2.0 or newer http://cairographics.org/ ... > I would suggest trying make a GUILE binding of sorts for Cairo, adding > that in parallel to existing GS support, and hacking untili you have > feature parity. Then drop the GS support, and migrate the cairo data > structures more towards the core of the program as needed. There already are guile bindings for cairo: https://savannah.nongnu.org/projects/guile-cairo Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Using/requiring Cairo
David Kastrup: ... > The main question mark would concern font handling > but I think it integrates with FreeType as well as Pango. ... cairo has support for freetype https://cairographics.org/manual/cairo-FreeType-Fonts.html pango has support for cairo: https://developer.gnome.org/pango/stable/pango-Cairo-Rendering.html /// Citating https://www.cairographics.org/manual/cairo-text.html Description The functions with text in their name form cairo's toy text API. The toy API takes UTF-8 encoded text and is limited in its functionality to rendering simple left-to-right text with no advanced features. That means for example that most complex scripts like Hebrew, Arabic, and Indic scripts are out of question. No kerning or correct positioning of diacritical marks either. The font selection is pretty limited too and doesn't handle the case that the selected font does not cover the characters in the text. This set of functions are really that, a toy text API, for testing and demonstration purposes. Any serious application should avoid them. The functions with glyphs in their name form cairo's low-level text API. The low-level API relies on the user to convert text to a set of glyph indexes and positions. This is a very hard problem and is best handled by external libraries, like the pangocairo that is part of the Pango text layout and rendering library. Pango is available from http://www.pango.org/. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: help with bash script to translate @ref{} items in translated manuals
Federico Bruni:
> Il giorno ven 21 apr 2017 alle 7:08, Federico Bruni
> ha scritto:
> > I guess I'll have to revert to my almost manual replacement I've used
> > so far.
>
> Or I may try a different approach and script a replacement from a file
> like:
>
> @ref{Different editions from one source},@ref{Edizioni diverse da un
> unico sorgente}
> @ref{Dimensions},@ref{Dimensioni}
> @ref{Direction and placement},@ref{Direzione e posizionamento}
>
> that replace first instance of @ref with the second instance (after the
> comma)
Well, that is about the same as putting the translation in the po file
and running the attached script. Then if and when gettext is working
again for doc., as someone said it has been, then you don't have to
convert your replacement file to po style.
$ read_po.pl Documentation/po/it.po .itely | head
File: Documentation/essay/engraving.itely
@ref{Music engraving} -> @ref{}
@ref{The LilyPond story} -> @ref{}
@ref{Engraving details} -> @ref{}
@ref{Music fonts} -> @ref{}
@ref{Optical spacing} -> @ref{}
@ref{Ledger lines} -> @ref{}
@ref{Optical sizing} -> @ref{}
@ref{Why work so hard?} -> @ref{}
@ref{Automated engraving} -> @ref{}
$
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
#!/usr/bin/perl -w
use strict;
use Data::Dumper;
my %file_list;
sub read_po() {
my $po_file = $ARGV[0];
my @arr;
open(FH, $po_file) || die("cannot open $po_file");
my $nxt = [ [], "", "" ];
while () {
chomp;
s/^\s*//;
s/\s*$//;
if (m/^$/) {
my %file;
my @lst;
for my $r (@{$$nxt[0]}) {
next if ($r =~ m|Documentation/cs/|);
if ($r =~ m| in (Documentation/.*\.itely)$|) {
$file{$1} = 1;
}
push @lst, $r;
}
my @Keys = sort keys %file;
if (@Keys) {
$$nxt[0] = [ @lst ];
push @arr, $nxt;
for my $f (@Keys) {
if (!defined($file_list{$f})) {
$file_list{$f} = [];
}
my $r = [ $$nxt[1], $$nxt[2] ];
push @{$file_list{$f}}, $r;
}
}
$nxt = [ [], "", "" ];
next;
}
if (m/^\#/) {
push @{$$nxt[0]}, $_;
next;
}
if (m/^msgid\s*\"(.*)\"$/) {
my $str = $1;
$$nxt[1] = $str;
next;
}
if (m/^msgstr\s*\"(.*)\"$/) {
my $str = $1;
$$nxt[2] = $str;
next;
}
if (m/^\"(.*)\"$/) {
my $str = $1;
if ($$nxt[2] eq "") {
$$nxt[1] .= $str;
} else {
$$nxt[2] .= $str;
}
next;
}
warn("unhandled data: <$_>");
}
close(FH);
@arr;
}
sub print_arr(@) {
my @arr = @_;
for my $r (@arr) {
print join("\n", @{$$r[0]}), "\n";
print "msgid \"$$r[1]\"\n";
print "msgstr \"$$r[2]\"\n";
print "\n";
}
}
sub mk_subst(@) {
my @arr = @_;
#print Dumper(\%file_list);
my @k = sort keys %file_list;
for my $k (@k) {
my @val = @{$file_list{$k}};
print "File: $k\n";
for my $r (@val) {
print " \@ref{$$r[0]} -> \@ref{$$r[1]}\n";
}
print "\n";
}
}
sub main() {
my @arr = read_po();
#print_arr(@arr);
mk_subst();
}
main();___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: help with bash script to translate @ref{} items in translated manuals
Federico Bruni:
> Il giorno ven 21 apr 2017 alle 7:08, Federico Bruni
> ha scritto:
> > I guess I'll have to revert to my almost manual replacement I've used
> > so far.
>
> Or I may try a different approach and script a replacement from a file
> like:
>
> @ref{Different editions from one source},@ref{Edizioni diverse da un
> unico sorgente}
> @ref{Dimensions},@ref{Dimensioni}
> @ref{Direction and placement},@ref{Direzione e posizionamento}
>
> that replace first instance of @ref with the second instance (after the
> comma)
You already have such an replacement file in Documentation/po/it.po:
$ fgrep -C2 'Different editions from one source' Documentation/po/it.po
#. @node in Documentation/notation/input.itely
#. @subsection in Documentation/notation/input.itely
msgid "Different editions from one source"
msgstr ""
Maybe that could be put to use.
I don't know if it is up to speed yet, but have a look at
http://po4a.alioth.debian.org/man/man7/po4a.7.php
There is some talk about texinfo and gettext in:
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Internationalization-of-Document-Strings.html
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: help with bash script to translate @ref{} items in translated manuals
Frederico Bruni:
> Il giorno gio 20 apr 2017 alle 11:22, k...@aspodata.se ha scritto:
> > Frederico Bruni:
> > ...
> >> Enter Documentation/it/notation and run this:
> >>
> >> #!/bin/bash
> >> LIST="$(grep -oh -e @ref{.*} *.itely | sort -u)"
> >> for i in $LIST; do
> >> echo $i
> >> #echo -n "Replace" $i "with the translated node: "
> >> #read NODE
> >> #if $NODE=""; then exit
> >> #else
> >> #sed "s|$i|$NODE|g" *.itely
> >> #fi
> >> done
...
> > $ cat tt
> > #!/bin/sh
> >
> > # for some reason mapfile doesnt work on pipes, hence the tmpfile
> > grep -oh -e "@ref{.*}" *.itely | sort -u > tmpfile
> > mapfile -t org < tmpfile
> >
> > len=${#org[@]}
> > for (( ix=0; ix < $len; ix++ ))
> > do
> > read NODE
> > printf "%4d: %s %s\n" $ix "${org[ix]}" "$NODE"
> > done
>
> Unfortunately this script hangs forever.
...
It is expecting something from stdin. You didn't tell us where the
replacement data comes from, so I guessed you run your script as
cat repl.txt | your_script
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: help with bash script to translate @ref{} items in translated manuals
Frederico Bruni:
...
> Enter Documentation/it/notation and run this:
>
> #!/bin/bash
> LIST="$(grep -oh -e @ref{.*} *.itely | sort -u)"
> for i in $LIST; do
> echo $i
> #echo -n "Replace" $i "with the translated node: "
> #read NODE
> #if $NODE=""; then exit
> #else
> #sed "s|$i|$NODE|g" *.itely
> #fi
> done
This doesn't work:
$ LIST="$(grep -oh -e @ref{.*} *.itely | sort -u)"
$ echo $LIST
This is better but messes with newlines:
$ LIST=$(grep -oh -e "@ref{.*}" *.itely | sort -u)
$ echo $LIST
@ref{Accidentals} @ref{Align} @ref{Aligning lyrics to a melody [...]
The "for i in $LIST" also messes with newlines.
This will rid you of the newline problem:
$ grep -oh -e "@ref{.*}" *.itely | sort -u | while read i; do echo $i; done
@ref{Accidentals}
@ref{Align}
...
but now "read NODE" won't read from script stdin. Trying with
/dev/stdin doesn't help since stdin is from the pipe, not the script
stdin.
$ grep -oh -e "@ref{.*}" *.itely | sort -u |
> while read i; do echo $i; read NODE < /dev/stdin; echo $b; break; done
@ref{Accidentals}
@ref{Align}
you culd solve that with arrays:
$ cat tt
#!/bin/sh
# for some reason mapfile doesnt work on pipes, hence the tmpfile
grep -oh -e "@ref{.*}" *.itely | sort -u > tmpfile
mapfile -t org < tmpfile
len=${#org[@]}
for (( ix=0; ix < $len; ix++ ))
do
read NODE
printf "%4d: %s %s\n" $ix "${org[ix]}" "$NODE"
done
$ ./tt | head -5
a d
0: @ref{Accidentals} a d
cd g
1: @ref{Align} cd g
gv
2: @ref{Aligning lyrics to a melody} gv
xcvb rge
3: @ref{Aligning objects} xcvb rge
rtdfg gr
4: @ref{Ambitus} rtdfg gr
2
$
you could also do the for loop like:
for i in "${org[@]}"
do
read NODE
echo $i $NODE
done
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Offer to help development: Convert MIDI to Lilypond
Graham: > On Wed, Dec 28, 2016 at 08:21:58PM +0100, k...@aspodata.se wrote: > > > At that point, an interested person -- perhaps yourself? -- could > > > offer further patches which improved the quality of the lilypond > > > code. > > > > Well, I'm working on theese: > > http://turkos.aspodata.se/git/musik/bin/miditoly.pl > > http://turkos.aspodata.se/git/musik/bin/midi_to_lilypond.tex > > Hmm. At the moment, there is no perl used in user scripts in > lilypond, and thus we do not distribute a perl interpreter as part > of our application bundle. Adding perl would be a significant > complication. Yes, I know, that is why I haven't offered it for inclusion. > That said, I'm quite willing to believe that your experience with > miditoly.pl could help inform the conversion process in midi2ly.py > -- what types of quantization work best, or how to decide which > accidental to use, etc. Once we have the basics working, Joe may > want to investigate more advanced techniques. That is why I started on the tex file, so that someone else could grasp the issues and implementation choises. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Offer to help development: Convert MIDI to Lilypond
Graham: ... > At that point, an interested person -- perhaps yourself? -- could > offer further patches which improved the quality of the lilypond > code. Well, I'm working on theese: http://turkos.aspodata.se/git/musik/bin/miditoly.pl http://turkos.aspodata.se/git/musik/bin/midi_to_lilypond.tex Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Offer to help development: Convert MIDI to Lilypond
Graham: > On Mon, Dec 26, 2016 at 11:44:15AM -0500, Joseph Austin wrote: > > I am offering to help with the project of converting midi2ly > > from C to Python, or more generally converting MIDI to Lilypond. > > Excellent! I'd be delighted to serve as your mentor. > > > I'm not sure if this is a good place for someone new to Lilypond > > internals to start, but it seems this should be a relatively > > independent utility so I shouldn't need a significant background > > in the internals. > > That is correct; the python midi2ly conversion is quite > independent of the rest of LilyPond. As a result, it is an > excellent place to begin! :) If you want it as an exercise, that's fine, but if you want a better midi to lilypond converter you better start looking at what kind of output you want since the output that midi2ly produces could be much better than what it is today. So I propose that a better course of action would be to research . what kind of lilypond code output you want to produce . the net for a suitable lowlevel midi lib . the net for alternative converters that are presently availble and let that steer your direction. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Offer to help development: Convert MIDI to Lilypond
Joe Austin: > I am offering to help with the project of converting midi2ly from > C to Python, or more generally converting MIDI to Lilypond. ... midi2ly is part python and part c, you can find them in git repo.: scripts/midi2ly.py python/midi.c midi2ly has been in the repository since 2001 according to logs. If external dependances are ok, you can find midi support for python below the header "MIDI Mania" in https://wiki.python.org/moin/PythonInMusic https://github.com/vishnubob/python-midi can possible be of help. /// Midi file spec. are available at: http://www.music.mcgill.ca/~ich/classes/mumt306/midiformat.pdf https://www.midi.org/specifications/item/standard-midi-files-smf The midi-file spec. and RP-017 could be of help. /// If you are interested, I'm working on a similar tool, in perl though: http://turkos.aspodata.se/git/musik/bin/miditoly.pl I'm using perls midi module https://metacpan.org/pod/MIDI, a simple midi dump program is available at http://turkos.aspodata.se/git/musik/bin/midi.pl /// I have just started writing a paper to discuss implementions and huristics in the conversion: http://turkos.aspodata.se/git/musik/bin/midi_to_lilypond.tex I'd be happy if you want to contribute to that paper and any possible developments around midi -> lilypond in any programming language. From the top of my head, on my wishful agenda is: collect midi files generated from different notation programs together with pdf outputs from same programs examine and establish huristics how to identify lyrics character encodings try to reserach and define a few conventions on how the lilypond code should be written and structured and write a output module/function for each convention e.g. relative and absolute pich output, names of music variables to match the users preferences research how polyfonic settings are written to midi file, how do you identify voices from a track with multiple voices research and define huristics to guess voice and instrument names support note scaling, i.e. duble, half note values and such among other things. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile-2.0 and debian
Jan-Peter Voigt:
> Am 24.11.2016 um 16:10 schrieb Antonio Ospite:
> > And about the choice between guile 1.8 or 2.0.12/13, it should be
> > possible to have both guile-1.8 and guile-2.0 packages installed in the
> > same image and then let lilypond choose which one to pick up at
> > configure-time, shoudln't it?
> I doubt that. You can install guile 1.8 and 2.0 in one system, but not
> guile-dev 1.8 and 2.0 AFAICS. So one needs to separate systems for each
> version of guile.
>
> Or am I wrong?
I get this on a gentoo system:
# emerge lilypond
[...]
checking for guile-config... ./configure: line 7604: 11151 Aborted
$exe --version > /dev/null 2>&1
no
checking guile compile flags... ;;; note: source file
/usr/share/guile/1.8/ice-9/boot-9.scm
;;; newer than compiled /usr/local/lib/guile/2.0/ccache/ice-9/boot-9.go
Throw without catch before boot:
Throw to key syntax-error with args ("memoization" "In file ~S, line ~S: ~A
~S." ("/usr/share/guile/1.8/ice-9/boot-9.scm" 101 "Bad define placement"
(define (toplevel-env? env) (or (not (pair? env)) (not (pair? (car env))
#f)Aborting.
checking guile link flags... ;;; note: source file
/usr/share/guile/1.8/ice-9/boot-9.scm
;;; newer than compiled /usr/local/lib/guile/2.0/ccache/ice-9/boot-9.go
Throw without catch before boot:
Throw to key syntax-error with args ("memoization" "In file ~S, line ~S: ~A
~S." ("/usr/share/guile/1.8/ice-9/boot-9.scm" 101 "Bad define placement"
(define (toplevel-env? env) (or (not (pair? env)) (not (pair? (car env))
#f)Aborting.
[...]
# /usr/bin/guile-config --version
guile-config - Guile version 1.8.8
# /usr/local/bin/guile-config --version
guile-config - Guile version 2.0.9
and putting v1.8.8 before v2.0.9 in the search patch doesn't help.
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond issue tracker account request
On Tue, 22 Mar 2016 08:25:05 - "Phil Holmes" wrote: > - Original Message ----- > From: "Karl O. Pinc" > To: > Sent: Tuesday, March 22, 2016 3:47 AM > Subject: Lilypond issue tracker account request > > I'd like an account in the lilypond issue tracker. > > > > I'm thinking about someday contributing to lilypond > > in the area of harp related notation. > I believe you can contribute to the tracker without an account: it's > just that the contributions require moderation. Could I suggest you > start like that and see how you progress? Sure. Sounds good. Thanks. FYI. I wrote because it was suggested here: http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl#configuring-git_002dcl Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein P.S. Is the nettiqute here to reply-all or just reply to the list? (Or, I suppose, just reply to the sender?) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond issue tracker account request
On Tue, 22 Mar 2016 12:14:37 - "Trevor Daniels" wrote: Hi Trevor, > Karl O. Pinc wrote Tuesday, March 22, 2016 3:47 AM > > I'd like an account in the lilypond issue tracker. > > Happy to add you to the Issue Tracker as a Member. > That allows you to comment on Issues without moderation. > That's the way to start. > > You'll need to post or send me your SourceForge Username > so I can set that up. I am "kpinc" at sourceforge. > > > I'm thinking about someday contributing to lilypond > Great! The first step is to post specific issues that > you have identified to the bug list: > http://lists.gnu.org/archive/html/bug-lilypond/ > for discussion and to have an Issue created. Ok. Thanks. I take it that this is not required for a doc patch? I'm thinking I'll send in something simple like that (through the development pipeline) to get started. > When you are ready to contribute to a specific Issue, > post a patch to the bug list. Ok. > The first few patches are usually sheparded through the > system by one of the Devs before you are elevated to > Developer status. I am at present way too ignorant of music to be comfortable with Developer status. Regards, Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond issue tracker account request
Hi, I'd like an account in the lilypond issue tracker. I'm thinking about someday contributing to lilypond in the area of harp related notation. I'd probably start with the fingering notation. FYI. I don't know much music or much harp. Or much lilypond. Harp fingering notation seems to be like \startGroup ... \stopGroup, or, after \set Staff.pedalSustainStyle = #'bracket \sustainOn ... \sustainOff. Except that the line can be slanted. And in some styles the finger numbers are written so their midpoint falls on the line and the line is broken. There seems to be 2 more variations, one where the line segments on the ends remain at right angles to the overall line, and are therefore slanted. And another style where the line segments at the end are vertical, independent of the slope of the overall line. Fingering runs from 1 to 4 with 1 being the thumb. See also: http://www.harpspectrum.org/harpworks/composing_for_harp/images/sacred_harp_notation.gif from http://www.harpspectrum.org/harpworks/composing_for_harp/composing_for_harp.shtml for "lots 'o harp notation", most of which seems to be missing from lilypond. In the latter link you can find an example of finger placement notation in "Writing for the Harp", section 1, "Notation". I've no idea if I'll every get around to contributing but am reading through the developer docs and it can't hurt to get setup for it. FWIW I've done FOSS development work with FOSS tools. Regards, Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: text-replacements: add ä and the like (issue 281470043 by simon.albre...@mail.de)
Simon Albrecht: > On 22.01.2016 13:00, Simon Albrecht wrote: > > On 22.01.2016 11:12, David Kastrup wrote: > >> Simon Albrecht writes: > >>> On 22.01.2016 02:13, Dan Eble wrote: > >>>>> text-replacements: add ä and the like > >>>>> Provides aliases auml,Auml,ouml,Ouml,uuml,Uuml > >>>>> They were wanted by a user, so why not provide them? > >>>> I don’t want my observation to hold back this change if everyone > >>>> else likes it, but this looks like a slippery slope. > >>> What’s the danger that you see? > >> There is a whole lot of character entities in Unicode. Several hundreds > >> of thousands I think. > > Of course, but 99,9% of them are much less common than äöü. The > > current set provided seems somewhat arbitrary anyway. > >>> The alternative would be to deprecate using this input method. > >> Why? > > Well, if a user wants to use ä in his lyrics, but there is no > > text-replacements alias, then text-replacements won’t be an option > > anymore. Currently, it’s in no usable state for languages like > > Swedish and German. And if somebody without ü on their keyboard wants > > to type in German lyrics, then ü is probably the easiest way to > > get it, unless they use an IDE like Frescobaldi, with a ‘Special > > characters’ panel, where it might only require one click. But then > > they wouldn’t need text-replacements anyway. > > How should I (and James) interpret the silence here? Any more opinions? I'd welcome this smallish addition. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Musicians prefer LilyPond scores, study finds
Francisco Vila: > I just gained my PhD. My humble thesis tells the design and results of > an experiment with a number of musicians, comparing lilypond scores > with the originals which those scores were copied from. ... > A 20Mb PDF (in Spanish) is privately available for those who ask for it. ... Isn't that a good reason to learn spanish ? But maybe this on is to heavy for a beginner. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond-mode in Emacs
Laura Conrad: > >>>>> "David" == David Kastrup writes: > > David> That means that without additional care, XEmacs+LilyPond will fall > David> victim to bitrot. > > David> However, that's preferable to LilyPond-mode falling victim to > David> bitrot on all platforms. > > David> Is that ok with people? > > Fine with me. ... Fine with me too. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Peterson: ... > Retyping by far. I pretty much write exclusively a cappella SATB, and I > have developed a very specific template/workflow for the part combining and > layout. I've tried a few different ways of getting the music from these > formats into LP, and in each case, I found myself spending longer in > cleaning up the resulting LilyPond code than if I had just transcribed it > manually from the other program. ... What if the midi->lilypond conversion could be made better? I'm currently looking into that. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Urs Liska: > Am 10.01.2014 22:23, schrieb k...@aspodata.se: > > Carl Peterson: ... > >> There's a visual component and a matter of input error reduction, because I > >> have been known to enter incorrect octaves or durations and not realize it > >> until I've finished typing and have compiled the entire score. > > > > A quick-n-dirty test mode would probably solve your need, just to > > check for typing errors and such (as you write above). > > > > What should such a mode need/disregard, what speedups are possible for > > such a test mode ? > > > > Well, > compiling a few measures of a single staff feels nearly instantaneous, > and when you're editing an orchestral score this makes a huge difference. Denpends on the computer you are using, http://turkos.aspodata.se/git/musik/ALotti/missa_a3_la_minore/04_agnus.ly is 17bars, 3voices with lyrics, and it still takes 5s on my box, > Generally I'd think it would be a good idea to have such an interface in > Frescobaldi. UI-wise it wouldn't be too hard to add that. However, there > is one thing I've thought about several times and that doesn't make the > issue so easy: > If you have a short segment of a score, say in a variable, how can you > guarantee that LilyPond has the right context for that (I'm not talking > of \context, but of things like key, time signature, transposition etc.)? If you are only interested in checking octaves and durations, the context doesn't matter too much. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Peterson: ... > I know someone suggested just turning off the PDF conversion to speed > things up, but it's not just a matter of instantaneous aural feedback. Ok. > There's a visual component and a matter of input error reduction, because I > have been known to enter incorrect octaves or durations and not realize it > until I've finished typing and have compiled the entire score. A quick-n-dirty test mode would probably solve your need, just to check for typing errors and such (as you write above). What should such a mode need/disregard, what speedups are possible for such a test mode ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
Carl Peterson:
...
> Now, consider an IDE/GUI setup
> (perhaps an extension of Frescobaldi) that would allow me to define a
> variable for a voice, then pop up a musical staff to enter and play
> back the notes for that variable without dealing with the whole
> compilation process. No manual tweaking of notes, just the entry of
> the entry and playback of the notes, and I don't have to insert the
> notes into the music itself yet or deal with whatever may or may not
> be wrong with the rest of my file. I realize that this would not
> necessarily work for all use cases, but I think for a large number of
> them, this could be beneficial. It would reduce a number of my
> transcription errors without me having to compile, scan for errors,
> potentially figure out where the errors are (depending on workflow),
> correct, recompile, etc.
Sounds like a performance problem, you want to hear (quickly) how the
things you entered sounds. That can be done with lilypond as is, just
skip the ps/pdf generation, us a test file like:
ma = { your_music }
targetpitch = c
midi_tempo = { \tempo 2 = 100 }
\score {
\unfoldRepeats \transpose c \targetpitch <<
\new Staff \ma
>>
\midi {
\midi_tempo
}
}
///
As an example take:
http://turkos.aspodata.se/git/musik/ALotti/missa_a3_la_minore/
Compiling it takes 15s on my box.
$ time lilypond 01_kyrie.ly
GNU LilyPond 2.19.0
Processing `01_kyrie.ly'
real0m14.844s
user0m10.914s
sys 0m0.291s
Skipping the to-pdf conversion saves me 2s
$ time lilypond --ps 01_kyrie.ly
...
real0m12.674s
user0m9.368s
sys 0m0.220s
And doing only midi is fast, 2.5s:
$ time lilypond 01_kyrie.ly
GNU LilyPond 2.19.0
Processing `01_kyrie.ly'
Parsing...
Interpreting music...
MIDI output to `01_kyrie.midi'...
Success: compilation successfully completed
real0m2.437s
user0m1.652s
sys 0m0.140s
So running
$ lilypond file.ly && timidity file.midi
would probably solve your stated need.
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
midi control done twice
Using tt.ly:
\version "2.19.0"
\score {
\new Staff {
\set Staff.midiInstrument = #"electric bass (finger)" % 34
\set Staff.midiPanPosition = #0
a'1
}
\midi { }
}
and midi.pl:
#!/usr/bin/perl -w
use strict;
use MIDI;
my $file;
foreach $file (@ARGV) {
my $opus = MIDI::Opus->new({ 'from_file' => $file });
$opus->dump({ "dump_tracks" => 1 });
}
gives me:
$ lilypond tt.ly
$ midi.pl tt.midi
MIDI::Opus->new({
'format' => 1,
'ticks' => 384,
'tracks' => [ # 2 tracks...
# Track #0 ...
MIDI::Track->new({
'type' => 'MTrk',
'events' => [ # 5 events.
['track_name', 0, 'control track'],
['text_event', 0, 'creator: '],
['text_event', 0, 'GNU LilyPond 2.19.0 '],
['time_signature', 0, 4, 2, 18, 8],
['set_tempo', 0, 100],
]
}),
# Track #1 ...
MIDI::Track->new({
'type' => 'MTrk',
'events' => [ # 10 events.
['patch_change', 0, 0, 33],
['control_change', 0, 0, 10, 64],
['control_change', 0, 0, 42, 0],
['patch_change', 0, 0, 33],
['instrument_name', 0, 'electric bass (finger)'],
['control_change', 0, 0, 10, 64],
['control_change', 0, 0, 42, 0],
['control_change', 0, 0, 7, 100],
['note_on', 0, 0, 69, 90],
['note_on', 1536, 0, 69, 0],
]
}),
]
});
$
As seen by the output, patch_change and control messages for panning
(10 is pan MSB, 42 is LSB pan) are done twice.
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building Lilypond documentation
Sven Axelsson: > It appears as if texi2html needs word-writeable folders to work. Thus I > took the simple route of running make doc (and make test) under sudo. Is > that how others does it too? Nope, git clone, pull, ./autogen.sh, make all, make doc all as the same user, no problems like the one you state. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guile 2 support
David Kastrup: > Sven Axelsson writes: ... > > I know that there have been plans of bumping to Guile 2 for a long > > time now. Is this something that is planned for the next release? > > Oh, definitely. It's not like it wasn't planned for 2.16 and 2.14. But > somebody has to do the heavy lifting. There don't seem to be many guides how to do the upgrade 1.8 -> 2.0, the only thing I found was the 1990 first lines of: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=NEWS;h=b53386a0bcfa3e67acf5f63e501ccf84c8242557;hb=958a28e9fec33ebb4673294308a82ccd18cc6071 and the problems reported by: http://code.google.com/p/lilypond/issues/list?can=2&q=guile+2.0&colspec=ID+Type+Status+Stars+Owner+Patch+Needs+Summary&cells=tiles from which I get the picture that 1.8 and 2.0 is basically the "same" but 2.0 have a stricter adherence to R5RS and it also have a byte compiler which makes lazy binding troublesome. /// Peter Brett has a guide how to work with mult. guile versions: http://blog.peter-b.co.uk/2011/06/geda-and-guile-compiling-against.html Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
Urs Liska: > Am 17.09.2013 18:21, schrieb David Kastrup: > > Janek Warchoł writes: > > > >> 2013/9/16 David Kastrup: > >>> So the question is what we should be telling the Savannah operators > >>> to make working on GNU projects using Git more feasible. > >> Here you go: > >> A web interface with online editor, allowing to create commits from a > >> web browser, on any branch (as well as creating branches), integrated > >> with pull requests and automatic forking (so that when someone without > >> write access tries to modify a file, Savannah automatically forks the > >> repository for him and when he's done making the change, a pull > >> request is sent to the original repository). Also, being able to post > >> comments on commits, and integration of pull requests with code > >> review. And the ability to update a pull request with new commits. > >> > >> As far as i know Savannah doesn't have these features. When it will > >> have, i'll be happy to switch, but i don't expect it will happen today > >> or tomorrow, so i'm going to use Github for now. > > Now basically we have to split these into two different sets of > > requirements: Savannah does not provide accounts or services to the > > general public; its services will be restricted to actual developers. > > > > But what you list above mostly is _not_ related to participating with > > the project but rather with managing one's own repository using a > > graphical interface that just happens to be provided as a web service, > > in a similar vein to Gmail providing a web interface to handling a mail > > account. > > I think that's not quite true. > IIUC Janek lists options that allow people to contribute to LilyPond > without officially applying to be developers. > > You are doing code reviews through a web interface already, isn't it? > And this is because that's a quite natural way to communicate, comment > on code etc. What's natural is different for different people. Web interfaces are not natural for me, to the contrary, for me they appear constrained. > You can't do _that_ with plain Git. Github isn't plain git either. I'm perfectly fine with git and email, your requirments might differ from mine. /// I don't know about github, but I wouldn't be surprised if their rules would be something that I wouldn't accept. You might be more liberal in what you tolerate from 3rd parties. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: website suggestion: live Lilypond preview
Janek: > when i was talking with MuseScore developers some time ago, they > mentioned that it would be great to have a "try lilypond in your > browser" thing on our website, similar to these: > http://tryhaskell.org/ > http://try.github.io/levels/1/challenges/1 > > I have no idea how difficult that would be, but i agree that it would > be great! At the very least we could perhaps have a prominent link to > tunefl/weblily/lilybin/mediawiki score extension live preview. > (should we have an issue for this?) tunefl is the top item on http://www.lilypond.org/easier-editing.html perhaps you could simply add the others to that page. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Suggestions for participating institutions?
Trevor Daniels: > Han-Wen Nienhuys wrote Tuesday, March 26, 2013 10:52 AM > > On Tue, Mar 26, 2013 at 9:52 AM, David Kastrup wrote: > > > >> I met a former colleague in the bus to Chemnitz, and he is at least > >> knowledgeable about EU research programmes. Do people here have ideas > >> about possible institutions who could be made to participate? I think > > > > Take in mind that EU research programmes come with an incredible > > amount of burocracy and require both academic and industry partners, > > the more the merrier. The projects that get funded are buzzword > > compliant, but often nobody knows what they set out to do, except > > divert EU money into the partnering institutions. Have a look at > > Indeed. When I was involved in bidding for EU research funding in > what now seems to be a previous life the process involved many meetings > with potential and later actual partners, who have to come from, I believe > at least 3 separate countries, plus presentations in Brussels, all involving > lots of international travel. And at the end of that expense of time, effort > and money we were unsuccessful. This is not like bidding for an Arts > grant. I think we can meet the 3 seperate countries requirement. I would like to try to set up something here with possible the University in Uppsala and/or the Church. I don't know if I qualify as an "industry" (note. eu defines an industry as something that manuf. phycical goods, no I don't have the ref. handy) partner, tought I have a company that have been involved in typesetting for pay. And I don't know if I can get any interest from the Univ. (they used Sibelius a few years ago) or the Church. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ice-9/psyntax.scm:1417:32: Syntax error:
David: > k...@aspodata.se (Karl Hammar) writes: > > Do anyone have a clue what to do about this error: ... > > $ ./autogen.sh > http://turkos.aspodata.se/tmp/log.autogen.sh ... > Guilev2 is not supported yet. What does autoconf tell? $ grep -iC2 guile log.autogen.sh checking for working metafont mode... ljfour checking for kpsewhich... kpsewhich checking for guile-config... guile-config checking guile-config version... 2.0.5 checking guile compile flags... -pthread -I/usr/include/guile/2.0 checking guile link flags... -lguile-2.0 -lgc checking libguile.h usability... yes checking libguile.h presence... yes checking for libguile.h... yes checking for scm_boot_guile in -lguile... no checking for scm_boot_guile... yes checking for scm_t_hash_fold_fn... yes checking for scm_t_hash_handle_fn... yes checking for scm_t_subr... yes checking for usable C++ demangler... yes checking GUILE rational bugfix... ok checking for python-config... python-config checking Python.h usability... yes -- checking for -windres... no checking for windres... no checking for guile... guile checking for guile... /usr/bin/guile checking for perl... perl checking for perl... /usr/local/bin/perl $ Ok, I'll try to downgrade guile then, thanks. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
ice-9/psyntax.scm:1417:32: Syntax error:
Do anyone have a clue what to do about this error: $ git describe release/2.15.33-1-4-gb04051d $ ./autogen.sh > http://turkos.aspodata.se/tmp/log.autogen.sh $ make all > http://turkos.aspodata.se/tmp/log.make 2>&1 $ tail log.make ;;; compiling /var/home/karl/Net/git/lilypond/out/share/lilypond/current/scm/part-combiner.scm ;;; WARNING: compilation of /var/home/karl/Net/git/lilypond/out/share/lilypond/current/scm/part-combiner.scm failed: ;;; ERROR: Syntax error: ;;; unknown location: source expression failed to match any pattern in form when ice-9/psyntax.scm:1417:32: In procedure expand-macro: ice-9/psyntax.scm:1417:32: Syntax error: unknown location: source expression failed to match any pattern in form when make[1]: *** [out/internals.texi] Error 1 make[1]: Leaving directory `/var/home/karl/Net/git/lilypond/Documentation' make: *** [all] Error 2 $ Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Moving away from make
David Kastrup: ... > The main problem I see is that dependencies don't work out, and that > presumably is mostly because the temporary/work files of lilypond-book > are not in the rules and get stomped over by parallel make. ... I have given up on lilypond-book and make. Instead I've made two scripts depend_ly and depen_tex [1] which finds out what depends on what (think gcc -M), and make [2] takes care of the rest. Would it be good to make lilypond print out a files dependancies like gcc? Regards, /Karl Hammar [1] http://turkos.aspodata.se/git/musik/bin/ [2] http://turkos.aspodata.se/git/musik/include/Makefile --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with String_convert::reverse?
Reinhold:
> Am Tuesday, 23. August 2011, 22:30:24 schrieb David Kastrup:
...
> > Is this used anywhere?
> A git grep didn't show any usage, but maybe I'm missing something.
Make does not complain about this patch (on my box).
$ git diff |cat
diff --git a/flower/include/string-convert.hh b/flower/include/string-convert.hh
index 55c1486..0675384 100644
--- a/flower/include/string-convert.hh
+++ b/flower/include/string-convert.hh
@@ -49,7 +49,7 @@ public:
static string i64_string (I64, char const *fmt = 0);
static string to_lower (string s);
static string to_upper (string s);
- static string reverse (string s);
+ static string reverseX (string s);
};
#endif // __STRING_CONVERT_HH //
diff --git a/flower/string-convert.cc b/flower/string-convert.cc
index d46426e..01cf3e5 100644
--- a/flower/string-convert.cc
+++ b/flower/string-convert.cc
@@ -362,7 +362,7 @@ String_convert::to_lower (string s)
}
string
-String_convert::reverse (string s)
+String_convert::reverseX (string s)
{
return (char *) memrev ((unsigned char *)s.data (), s.length ());
}
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Comand token too long?
Reinhold Kainhofer: > Am Sunday, 14. August 2011, 03:36:05 schrieb Karl Hammar: > > Works here: > Doesn't work here on a German Kubuntu system: ... > > $ echo $LANG > > C > $ echo $LANG > de_AT.UTF-8 $ LANG=de_AT.UTF-8 $ echo 'z:/' | egrep '^(/|[A-z]:/)' egrep: Das Ende des angegebenen Intervalls ist nicht gültig $ echo 'z:/' | egrep '^(/|[A-Za-z]:/)' z:/ $ export LC_ALL=C $ echo 'z:/' | egrep '^(/|[A-z]:/)' z:/ $ So that means that this bug is due to collation order, and as you wrote yesterday the interval should be changed to A-Za-z. The egrep thing is there to detect if a filename is absolute, i.e. starting with "/" as in "/usr/bin/true" (unix style), or "C:/" (or another device letter) as in "C:/WINDOWS/SYSTEM32/FILE.DLL" (Dos/Windows style). As written in "man grep": To obtain the traditional interpretation of bracket expressions, you can use the C locale by setting the LC_ALL environment variable to the value C. we can go around this bug by setting LC_ALL to C. This bug is fixed in [1]: - echo "$command_line_filename" | $EGREP '^(/|[A-z]:/)' >&6 \ + echo "$command_line_filename" | LC_ALL=C $EGREP '^(/|[A-Za-z]:/)' >&6 \ We might go around the bug with the attaced patch (texi2dvi is called from texi2pdf), but I have not had time to test it. Regards, /Karl Hammar [1] http://ftp.gnu.org/gnu/texinfo/texi2dvi --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 diff --git a/make/doc-i18n-root-rules.make b/make/doc-i18n-root-rules.make index f510ded..83f2ee6 100644 --- a/make/doc-i18n-root-rules.make +++ b/make/doc-i18n-root-rules.make @@ -18,7 +18,7 @@ $(top-build-dir)/Documentation/$(outdir)/%.$(ISOLANG).html: $(outdir)/%.texi $(X $(top-build-dir)/Documentation/$(outdir)/%.$(ISOLANG).pdf: $(outdir)/%.texi cd $(outdir) && \ - texi2pdf $(TEXI2PDF_FLAGS) $(TEXINFO_PAPERSIZE_OPTION) $*.texi && \ + LC_ALL=C texi2pdf $(TEXI2PDF_FLAGS) $(TEXINFO_PAPERSIZE_OPTION) $*.texi && \ mkdir -p $(dir $@) && mv $*.pdf $@ $(outdir)/version.%: $(top-src-dir)/VERSION___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Comand token too long?
Francisco Vila: > 2011/8/13 Francisco Vila : > > Hello, does anybody what this error means? > > > > cd Documentation/ > > cd ./out-www; texi2pdf -I ./out-www -I ../out -I .. -I .. --quiet > > notation.texi > > egrep: Invalid range end > > This is caused by line 1713 of /usr/bin/texi2dvi (GNU Texinfo 4.13) > 1.135 in my system, > > # If the COMMAND_LINE_FILENAME is not absolute (e.g., --debug.tex), > # prepend `./' in order to avoid that the tools take it as an option. > echo "$command_line_filename" | $EGREP '^(/|[A-z]:/)' >&6 \ > || command_line_filename="./$command_line_filename" > > and [A-z] is an invalid range. Works here: $ echo '/usr/' | egrep '^(/|[A-z]:/)' /usr/ $ echo 'B:/' | egrep '^(/|[A-z]:/)' B:/ $ echo 'z:/' | egrep '^(/|[A-z]:/)' z:/ $ echo 'bin/' | egrep '^(/|[A-z]:/)' $ egrep --version | head -1 GNU grep 2.6.3 $ echo $LANG C $ [A-z] is a valid range in the C locale. Maybe you have a locale with a sorting order where z comes before A. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Postscript printer errors with rounded barlines?
Han-Wen Nienhuys: > On Thu, Jul 21, 2011 at 12:31 PM, Karl Hammar wrote: ... > > After "dup" there is two "blot"s, "gt" consumes one and "setlinewidth" > > the other. > > I'm sorry - I misunderstood; I thought you saw a problem with the code > rather than the comments. No problem. I see no problem with the code, it was just the comment that didn't match the code. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Postscript printer errors with rounded barlines?
Han-Wen Nienhuys:
> On Thu, Jul 21, 2011 at 8:11 AM, Karl Hammar wrote:
> > Han-Wen Nienhuys:
> >> Werner, can you have a look at http://codereview.appspot.com/4819041 ?
> > There is no blot on the stack below (as indicated by the comment),
> there is; the dup puts it on the stack. The comment indicate the
> state after the call.
/draw_round_box % width height x y blot
{
w h x y b
dup
w h x y b b
0.0 gt
w h x y b a_bool % the a_bool it consumed by the ifelse below
{
w h x y b
setlinewidth % w h x y
w h x y
0 setlinecap
1 setlinejoin
w h x y
rmoveto % b w h
w h
currentpoint % b w h x1 y1
4 2 roll % b x1 y1 w h
4 copy
rectfill
rectstroke
} {
pop % w h x y
rmoveto % w h
currentpoint % w h x1 y1
4 2 roll % x1 y1 w h
rectfill
} ifelse
} bind def
After "dup" there is two "blot"s, "gt" consumes one and "setlinewidth"
the other.
///
Also if there were a "blot" at "rmoveto" time due to a "dup", it would
be at top of stack, not below "w h" as indicated by the comment.
///
If it would behave as the comment indicate, then
w h x y 0draw_round_box => -
w h x y blot draw_round_box => blot
e.i. it would leave a lone "blot" at the top of the stack if it's > 0.
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Postscript printer errors with rounded barlines?
Han-Wen Nienhuys:
...
> Werner, can you have a look at http://codereview.appspot.com/4819041 ?
/draw_round_box % width height x y blot
{
- setlinewidth % w h x y
- 0 setlinecap
- 1 setlinejoin
+dup
+ 0.0 gt {
+ setlinewidth % w h x y
+ 0 setlinecap
+ 1 setlinejoin
+
There is no blot on the stack below (as indicated by the comment),
it was swallowed by setlinewidth.
+ rmoveto % b w h
+ currentpoint % b w h x1 y1
+ 4 2 roll % b x1 y1 w h
+ 4 copy
+ rectfill
+ rectstroke
+ } {
+ pop % w h x y
+ rmoveto % w h
+ currentpoint % w h x1 y1
+ 4 2 roll % x1 y1 w h
+ rectfill
+ } ifelse
+} bind def
You don't seem to use this, why defining it?
+/draw_box % width height x y
+{
rmoveto % w h
currentpoint % w h x1 y1
4 2 roll % x1 y1 w h
4 copy
rectfill
- rectstroke
} bind def
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 3 - C++ formatting (probable decision)
Graham: ... > ** Eliminate tabs > > I'm going to make the bold step of assuming that we will eliminate > tabs in all C++ files. ... That implies that tabs in strings should be replaced with \t, is that what you want? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: No more releases: savannah sometimes does not like git fetch --depth
Trevor: > I've attached an email which explains a similar problem ... Path-mtu-discovery is described in rfc-1191 and some problems with it in rfc-2923. The symtoms described in is matches "black hole" in rfc-2923. It should be wholly agnostic to the "git fetch --depth 1" vs. "git clone" choise. The "black hole" problem happens only for large packets. ** If it is the "black hole": The best fix is to correct your router, setting the mtu in the router might be a solution for that, but your router should return a proper icmp error response (ICMP Destination Unreachable messages with a code meaning "fragmentation needed and DF set") if the packet is too large. Make sure the router and your host don't filter out thoose icmp packets. /// The second best is to send smaller packets from your host going through that route. This can be set with route del default gw route add default gw mss where mss = maximum segment size. A good first try is MTU - 80, see rfc-879 for details. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: No more releases: savannah sometimes does not like git fetch --depth
Graham: ... > mkdir new-lilypond-dir > cd new-lilypond-dir > git init > git config core.bare false > git remote add -t master origin git://git.sv.gnu.org/lilypond.git > git fetch --depth 1 > > fails every time. Until this is fixed, > *** I CANNOT MAKE ANY MORE LILYPOND RELEASES. *** ... Works here (turkos.aspodata.se): $ mkdir new-lilypond-dir $ cd new-lilypond-dir $ git init Initialized empty Git repository in /var/home/karl/new-lilypond-dir/.git/ $ git config core.bare false $ git remote add -t master origin git://git.sv.gnu.org/lilypond.git $ git fetch --depth 1 remote: Counting objects: 4236, done. remote: Compressing objects: 100% (4031/4031), done. remote: Total 4236 (delta 643), reused 1669 (delta 191) Receiving objects: 100% (4236/4236), 15.06 MiB | 206 KiB/s, done. Resolving deltas: 100% (643/643), done. >From git://git.sv.gnu.org/lilypond * [new branch] master -> origin/master $ Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 1: python formatting
Graham: > On Mon, Jun 06, 2011 at 10:58:11AM +0200, Karl Hammar wrote: > > Graham: > > > (this proposal will be rushed because nobody will argue against > > > it. Initial discussion 6 June, summary and tentative decision 8 > > > June, implementation 10 June) > > Having set a policy about policy discussions and then breaking it > > the first thing you do is not a good policy. ... > I felt a bit of a rush because the mix of indentation is delaying > some much-needed improvements to our build system, but I agree ... Well then, say so. I wouldn't argue against that. ... > > Presenting rules without rationales, gives no ground for decisions. > > One could the feeling that this is pure nonsense. If you really > > care about this, provide a pretty printer instead, and stipulate > > that all code should go through that. > I am not aware of any pretty printers for python code -- remember A quick search did not turn up anything useful either, well, sorry for that then. For the simple case of removing tabs, "col -b -x" could be one. Manually finding/expanding tabs is a pain. > that unlike C++ or scheme, indentation in python is the way that > one indicates code blocks. (this makes mixing tabs and spaces > particularly horrible!) ... There is your rationale. There is a check the python code should pass "python -tt", maybe it could be run as part of some make process... Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 1: python formatting
Graham: > (this proposal will be rushed because nobody will argue against > it. Initial discussion 6 June, summary and tentative decision 8 > June, implementation 10 June) Having set a policy about policy discussions and then breaking it the first thing you do is not a good policy. If there is no rush, don't break the rules. On the contrary, how can I feel confidence in the rules if they are beeing broken. > Proposal: letâs follow PEP-8. > http://www.python.org/dev/peps/pep-0008/ > > * use 4 spaces per indentation level > * never max tabs and spaces In the code I presume, in strings this wouldn't apply. > * Code indented with a mixture of tabs and spaces should be > converted to using spaces exclusively Presenting rules without rationales, gives no ground for decisions. One could the feeling that this is pure nonsense. If you really care about this, provide a pretty printer instead, and stipulate that all code should go through that. I propose instead: . Don't ever provide patches whith white space changes (in the code) unless the patch is only about white space changes Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Openoffice import?
David: > Offlist http://www.haumacher.de/svg-import/> has been suggested to > me. The JAR file mentioned in there works for converting lilypond-book > images placed into PDF, extracted with preview.sty, converted with > pdf2svg to SVG to .odg files (OpenOffice Draw Graphics?) as OLE links > into an OpenOffice document from where they will export to scalable PDF > again. So there is a reasonable hope they might also export to scalable > DOC contents. ... I found http://sk1project.org/modules.php?name=Products&product=uniconvertor which claims to be able to do eps -> svg, can that be of any help... Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Black mensural notation
James Lowe: ... > Lukas (although for some reason I am getting bounces from your email address > so I hope you are reading this on the lists)! Lukas cannot do anything about this except changing mail provider. The mailing list should be fine. You can do something by making sure the sending mailserver ip-number and dns name points back to each other, ask your mail- and dnsadmin. > Is anyone else getting > > > 10.mx.freenet.de rejected your message to the following e-mail addresses: > > Lukas Pietsch (lukas.piet...@freenet.de)<mailto:lukas.piet...@freenet.de> > > 10.mx.freenet.de gave this error: > inconsistent or no DNS PTR record for 173.221.96.141 (see RFC 1912 2.1) Yes, freenet.de only accepts mail from mail-servers with a valid reverse pointer. If I like to find out who 172.221.96.141 is, I can do: $ host -t ptr 173.221.96.141 141.96.221.173.in-addr.arpa domain name pointer cas-ftl1.datacore.com. $ But cas-ftl1.datacore.com doesn't poin back to the same number: $ host cas-ftl1.datacore.com. cas-ftl1.datacore.com has address 205.237.192.88 $ Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Black mensural notation
Lukas: > Hi, I'm quite new to Lilypond programming, but I thought I'd jump in at what > seemed to me to be pretty much the deep end, and try if I could get black > mensural notation implemented. Here's what I've come up with so far: > http://lukas-pietsch.de/Music/blackmensural.ly (source file) > http://lukas-pietsch.de/Music/blackmensural.pdf (doc) > > It's all just scheme functions and embedded postscript, and works for me under > the current stable 2.12.3. > > The biggest stumbling block turned out to be black ligatures, which I found no > other way of doing than rewriting from scratch in a rather hackish way, > sidestepping the normal ligature engraver completely; and horizontal spacing, > for which I had to figure out some rather ugly workarounds (probably far from > optimal). > > If anybody finds it useful, please feel free to use or modify. On line 22 in the ly-file: %% Accidentals are valid only once (same as Shouldn't the accidental be valid for the next note and any same repeted note, this has bothered me with the current white mesural support. E.g. if you say "bes bes bes", it should be only one b-flat sign? And the b-flat sign could be displaced horisontally to the left as in gregorian chant? The rests looks a little thick in section 1.4 in the pdf. Wery nice, I'm very happy to see this!!! Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Graham: > On Sat, Jan 01, 2011 at 09:10:49AM +0100, Werner LEMBERG wrote: ... > > But maybe there is a group of LilyPond philanthropists who can afford > > this and are willing to do so... > I'm not optimistic about that; I think a more realistic > opportunity would be to get some grant money from some artistic > organization. ... > > Of course, writing artistic and research grants is a non-trivial > amount of work, and it's hardly guaranteed to have any results. > But I think that with the right angle -- be that "collaborative > folk music archival", or "high-quality, specialized music > notation", or "educational software for cheap 3rd-world donated > computers", I could imagine getting a grant. In Uppsala there is one person at the music institution who is interested in Schenker analysis. Could that be a lead? Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sustainable development in LilyPond
Graham: ... > http://percival-music.ca/blog/2010-08-01-sustainable-development.html ... Thank you for the slides, I liked them. Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 881 Arpeggios may collide with laissezVibrer ties (was Re: Critical issues)
And here comes the test-baseline file. Regards, /Karl Hammar <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 881 Arpeggios may collide with laissezVibrer ties (was Re: Critical issues)
- This is a multipart MIME message. Karl Hammar: > Carl Sorensen: > ... > > I've posted a patch on Rietveld. Can you do the > > regression test? > > http://codereview.appspot.com/1195044 > > After a make test-redo I get: > > . the "mandatory" output-distance. > . a diff of tree.gittext, showing Carls patch > . 314 below threshold > . 2062 unchanged > > From this I assume Carls patch does not affect any present regression > test. Sorry to bring this up again, but this conclusion is still unproven, since the test was done with "test-redo". As I have found out in the thread for the issue 915, "test-redo" does not test the things we wanted to test. *** $ git-status # On branch master # Untracked files: # (use "git add ..." to include in what will be committed) # # issue1195044_1_2.diff # issue1195044_1_3.diff # issue931041_1.diff nothing added to commit but untracked files present (use "git add" to track) $ git-log | head -1 commit 22d889f4d27469864c31db81445e9de49774ae23 $ cat issue1195044_1_[23].diff | patch -p1 patching file scm/define-grobs.scm patching file scm/output-lib.scm $ make check > log 2>&1 ... And I get a distance of 18.406667 in the attached output. The difference seems to be because the c and the b are horizontally closer to each other. Regards, /Karl Hammar <><>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
contributors manual
>From the debacle with "Issue 915" I have learned that . "make test-redo" does not catch regression due to program changes . rest-collision-beam-note.ly changes is more or less expected . section 8 "Regression tests" is related to section 3.6.3.1 Does "make check" after test-baseline serve any purpose ? What is the purpose for "test-redo", is it there to test changes in the regression test files themselves, and only that ? Regards, /Karl Hammar ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
Karl Hammar: > Neil Puttock: ... > > I basically do what Carl outlined in the other thread: > > > > make test-baseline > > > > git apply issue931041_1.diff > > > > make check > > The contributor manual says (3.6.3.1): > >* Initial test: > > make [-jX] > make test-baseline > make [-jX CPU_COUNT=X] check > >* Edit/compile/test cycle: > > _## edit source files, then..._ > > make clean_## only if needed (see below)_ > make [-jX]_## only if needed (see below)_ > make test-redo_## redo files differing from > baseline_ > make [-jX CPU_COUNT=X] check _## CPU_COUNT here?_ > >* Reset: > > make test-clean After yet another run: make clean > /dev/null patch -p1 < issue931041_1.diff make > log 2>&1 make check > log 2>&1 I get the "expected" output (i.e. Neil's output). Regards, /Karl Hammar ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
Neil Puttock: > On 15 May 2010 14:37, Karl Hammar wrote: > > git-pull > > wget http://codereview.appspot.com/download/issue931041_1.diff > > patch -p1 < issue931041_1.diff --dry-run > > patch -p1 < issue931041_1.diff > > make > log 2>&1; make test-redo >> log 2>&1 > > I very rarely use `make test-redo'. The difference between test-redo and check is small: $ grep -A 6 ^test-redo: GNUmakefile test-redo: for a in `cat $(RESULT_DIR)/changed.txt` ; do \ echo removing $$a* ; \ rm -f $$a* ;\ done $(MAKE) check $ grep RESULT_DIR GNUmakefile | head -1 RESULT_DIR=$(top-build-dir)/out/test-results $ cat out/test-results/changed.txt; echo # missing final newline input/regression/out-test//test-output-distance input/regression/out-test//rest-collision-beam-note input/regression/out-test//tree $ Does it matter, if not, why is in the contributor manual ? > I basically do what Carl outlined in the other thread: > > make test-baseline > > git apply issue931041_1.diff > > make check The contributor manual says (3.6.3.1): * Initial test: make [-jX] make test-baseline make [-jX CPU_COUNT=X] check * Edit/compile/test cycle: _## edit source files, then..._ make clean_## only if needed (see below)_ make [-jX]_## only if needed (see below)_ make test-redo_## redo files differing from baseline_ make [-jX CPU_COUNT=X] check _## CPU_COUNT here?_ * Reset: make test-clean It has an "make check" after the test-baseline which you don't have, is it redundant? git-apply and patch -p1 produces the same result, so that is not the cause of our different output: $ cd .. $ cp -a lilypond/ lilypond.b $ cd lilypond.b/ $ git-apply -v issue931041_1.diff Applied patch lily/bar-line.cc cleanly. Applied patch lily/include/bar-line.hh cleanly. Applied patch lily/include/note-spacing.hh cleanly. Applied patch lily/include/paper-column.hh cleanly. Applied patch lily/multi-measure-rest.cc cleanly. Applied patch lily/note-spacing.cc cleanly. Applied patch lily/paper-column.cc cleanly. Applied patch scm/define-grob-properties.scm cleanly. Applied patch scm/define-grobs.scm cleanly. $ cd ../lilypond $ patch -p1 < issue931041_1.diff patching file lily/bar-line.cc patching file lily/include/bar-line.hh patching file lily/include/note-spacing.hh patching file lily/include/paper-column.hh patching file lily/multi-measure-rest.cc patching file lily/note-spacing.cc patching file lily/paper-column.cc patching file scm/define-grob-properties.scm patching file scm/define-grobs.scm $ cd .. $ diff -Naur lilypond* $ > > Also, it would be much easier to look throuht the patch if it did not > > contain so many whitespace changes. In the first 100lines, I see: > > Why would you want to look at the bare diff? Isn't the diff a complete statement of what you want to change? Also you *did* cite the diff. > The whole point of > uploading the patchset to Rietveld is to make it easier to see the > changes in each file. Well, it might help someone else, but not me -- I have mail and git. Putting things on web sites and getting things from them makes it take more time. *** If I take it from the beginning: $ git-log | head -1 commit 22d889f4d27469864c31db81445e9de49774ae23 $ git-status # On branch master # Untracked files: # (use "git add ..." to include in what will be committed) # # issue1195044_1_2.diff # issue1195044_1_3.diff # issue931041_1.diff # log nothing added to commit but untracked files present (use "git add" to track) $ make clean > /dev/null 2>/dev/null $ make > log 2>&1 $ make test-baseline > log1 2>&1 Processing ./snippet-map-1678077630 ... Processing 41/lily-67666737 Failed files: () $ make check > log2 2>&1 Processing ./snippet-map-1678077630 ... Processing 90/lily-015675ea Failed files: () $ patch -p1 < issue931041_1.diff $ make > log3 2>&1 $ make test-redo > log4 2>&1 Processing ./snippet-map--1837524129 ... Failed files: () $ fgrep ' $ # above file attached $ make check > log5 2>&1 Processing ./snippet-map-170730255 ... Failed files: () $ # the same output is produced $ ls -1 input/regression/out-test/multi-measure-rest-multi-staff-center* input/regression/out-test/multi-measure-rest-multi-staff-center-1.eps input/regression/out-test/multi-measure-rest-multi-staff-center-1.signature input/regression/out-test/multi-measure-rest-multi-staff-center-systems.count input/regression/out-test/multi-measure-rest-multi-staff-center-systems.tex input/regression/out-test/multi-measure-rest-multi-staff-center-systems.texi input/regression/out-
Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
Neil Puttock:
> On 15 May 2010 09:58, Karl Hammar wrote:
> > Patching with [3] (see [2]) still gives something (see attachment)
> > more like rest-2.12.png in [1], i.e. it was not fixed.
>
> You must've done something wrong when applying the patch/rebuilding.
>
> I wouldn't post a patch on Rietveld without first confirming the
> regression is fixed.
I don't think so either, you are more than welcome to point out what I
did wrong:
git-pull
wget http://codereview.appspot.com/download/issue931041_1.diff
patch -p1 < issue931041_1.diff --dry-run
patch -p1 < issue931041_1.diff
make > log 2>&1; make test-redo >> log 2>&1
> > Â Allow user override of left/right spacing of full-bar rests relative
> > Â to barlines or prefatory material.
> >
> > implies that one has to do an override. The comment gives no help for
> > what override to use.
>
> The patched files should make it clear:
>
> + (spacing-pair ,pair? "A pair of booleans which set the spacing for a
> +multi-measure rest relative to its left and right @code{BreakAlignment}s.
> +If true, the rest is spaced to the bar line, ignoring prefatory items such
> +as clefs and time signatures; if false, it is spaced relative to the
> +BreakAlignment, which includes prefatory items. ")
>
> + (spacing-pair . (#f . #t))
>
> ^ default value for MultiMeasureRest
Yes, I can see the lines (last in the patch) when you point the out for me.
But, nevertheless I got the result I got.
Also, it would be much easier to look throuht the patch if it did not
contain so many whitespace changes. In the first 100lines, I see:
+bool
+Bar_line::non_empty_barline (Grob *me)
+{
+ return has_interface (me) && !me->extent (me, X_AXIS).is_empty ();
+}
+
and the rest is whitespace changes. That makes the reader tired.
Regards,
/Karl Hammar
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 915 Multi-measure rests dependent on prefatory matter in other staves
Patching with [3] (see [2]) still gives something (see attachment) more like rest-2.12.png in [1], i.e. it was not fixed. The comment for the fix: Allow user override of left/right spacing of full-bar rests relative to barlines or prefatory material. implies that one has to do an override. The comment gives no help for what override to use. Since this regression is considered "critical", should not the default be for 2.11.27 behaviour instead of 2.11.28 or later ? Regards, /Karl Hammar [1] http://code.google.com/p/lilypond/issues/detail?id=915 [2] http://codereview.appspot.com/931041/show [3] http://codereview.appspot.com/download/issue931041_1.diff 3.pdf Description: 3.pdf ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 881 Arpeggios may collide with laissezVibrer ties (was Re: Critical issues)
Carl Sorensen:
...
> I've posted a patch on Rietveld. Can you do the
> regression test?
> http://codereview.appspot.com/1195044
After a make test-redo I get:
. the "mandatory" output-distance.
. a diff of tree.gittext, showing Carls patch
. 314 below threshold
. 2062 unchanged
>From this I assume Carls patch does not affect any present regression
test.
***
But I also notice that there are no test for the present problem.
Perhaps one should be added?
The one presented in the report[1] could be a candidate, comments?
\version "2.12.1" % regression: 2.10.33 and 2.8.8 are ok
{
\laissezVibrer \arpeggio
\laissezVibrer \arpeggio \mark "never"
\laissezVibrer \arpeggio
\laissezVibrer \arpeggio
\bar "||"
\laissezVibrer \arpeggio
\laissezVibrer \arpeggio \mark "sometimes"
\laissezVibrer \arpeggio
\laissezVibrer \arpeggio
\bar "||"
\laissezVibrer \arpeggio
\laissezVibrer \arpeggio \mark "always"
\laissezVibrer \arpeggio
\laissezVibrer \arpeggio
}
***
I also note that input/regression/laissez-vibrer-ties.ly has a bar
check failure:
\relative c' {
\laissezVibrer r4
\laissezVibrer r
\laissezVibrer r
4.\laissezVibrer r % here we get a bar check failure
In Documentation/snippets/laissez-vibrer-ties.ly we have a r8 at that
point, otherwise thoose two are basically the same.
What was the point of having a bar check failure in the regression
test?
Regards,
/Karl Hammar
[1] http://code.google.com/p/lilypond/issues/detail?id=881
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 881 Arpeggios may collide with laissezVibrer ties (was Re: Critical issues)
Carl Sorensen: > On 5/14/10 7:01 AM, "Karl Hammar" wrote: > > Carl Sorensen: ... > You also need to redefine the 'stencil for laissez-vibrez tie in > scm/define-grobs.scm. ... I can help with doning the regression test. Second-guessing what Niels patch was about was not included in that offer. Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
Carl Sorensen: > On 5/13/10 1:11 PM, "Karl Hammar" wrote: ... > make test-baseline ... > make check ... Ok, done that. With the guidance from http://code.google.com/p/lilypond/issues/detail?id=881: I can't explain why, but making the print function pure by redefining ly:tie::print just for LaissezVibrerTie seems to fix this (I haven't done a regtest check, so it might end up breaking something else): (define-public (laissez-vibrer::print grob) (ly:tie::print grob)) (then add laissez-vibrer::print to pure-print-callbacks) I tried this: diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm index 176debd..35186f8 100644 --- a/scm/define-grobs.scm +++ b/scm/define-grobs.scm @@ -2345,8 +2345,12 @@ (interval-union '(0 . 0) (cons smaller larger))) '(0 . 0 +(define-public (laissez-vibrer::print grob) + (ly:tie::print grob)) + (define pure-print-callbacks (list + laissez-vibrer::print fret-board::calc-stencil note-head::brew-ez-stencil print-circled-text-callback $ make test-redo > out/test-results/index.html > > that shows the results of the regression tests. ... I got (except the test-output-distance.ly) an distance of 0300030 and "HEAD is: 22d889f4d27469864c31db81445e9de49774ae23" to the right and left plus the git-diff to the rigth. So I assume it was the wrong patch try. Does anybody have Neil's proposed fix available ? Regards, /Karl Hammar ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
Carl Sorensen: > On 5/13/10 2:08 PM, "Karl Hammar" wrote: ... > > In http://code.google.com/p/lilypond/issues/detail?id=1080 there is a > > grace-start-good.png . ... > IIUC, Neil's patch was already demonstrated to meet issue 1. But issue 2 > was not yet checked. Are you mixing this up with http://code.google.com/p/lilypond/issues/detail?id=881 Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
Carl Sorensen: > On 5/13/10 1:11 PM, "Karl Hammar" wrote: ... > > But if I already have a known good result from the code tracker, > > how do I compare it with the new result? > > What do you mean by "if I already have a known good result from the code > tracker"? In http://code.google.com/p/lilypond/issues/detail?id=1080 there is a grace-start-good.png . > make test-baseline > > followed by > > make check ... I understand that I could possible go back to 2.13.17, do the make's, jump to current git and make test-redo. But if the "old good" png is already available, then I see the possibility to skip the "go back to..." step. Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
Graham: > On Thu, May 13, 2010 at 10:06:45AM +0200, Karl Hammar wrote: > > How do one do a regtest? > > Regression check; by compiling stuff. > > > 8.1 Introduction to regression tests > > > > The regression tests are automatically compiled using special `make' > > targets. The output of the regression tests is also automatically > > > > So, what targets? > > They might be "make baseline-test", followed by applying a patch, > followed by "make check", but I'm not certain. It's explained > somewhere in Contributing 2. Ok, found something in "3.6.3 Testing LilyPond" (though nothing in the chapter on regression tests). * Initial test: make [-jX] make test-baseline make [-jX CPU_COUNT=X] check * Edit/compile/test cycle: _## edit source files, then..._ make clean_## only if needed (see below)_ make [-jX]_## only if needed (see below)_ make test-redo_## redo files differing from baseline_ make [-jX CPU_COUNT=X] check _## CPU_COUNT here?_ Hmm, the make check seems redundant since test-redo already does it: $ find . -name GNUmakefile | xargs grep -A 10 test-redo ... ./GNUmakefile:test-redo: ./GNUmakefile- for a in `cat $(RESULT_DIR)/changed.txt` ; do \ ./GNUmakefile- echo removing $$a* ; \ ./GNUmakefile- rm -f $$a* ;\ ./GNUmakefile- done ./GNUmakefile- $(MAKE) check ... ./scripts/build/out/output-distance seems to be the workhorse of the regression tests. I cannot find any useful documentation of it with: find . -type f | xargs grep output-distance except the source code itself. But if I already have a known good result from the code tracker, how do I compare it with the new result? Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
Issue 815: Enhancement: AJAX-powered search auto-completion for the online documentation Issue 1038: more technical website items Theese two seem to be related to the web site, not to the released software. I can understand that it can be critical for the official site, but how can that be critical for the release ? Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
Issue 881: Arpeggios may collide with laissezVibrer ties According to the bug tracker, v2.11.19's output is what to aim for. Neil gave the fix: (define-public (laissez-vibrer::print grob) (ly:tie::print grob)) (then add laissez-vibrer::print to pure-print-callbacks) But he has not done a regtest check. /// How do one do a regtest? I remember there were discussion about this a while ago, but doing a quick search (regtest check lilypond) did not turn up anything useful, except [1] and [2]. [1] http://lilypond.org/doc/v2.13/Documentation/contributor/checking-and-verifying-issues [2] http://lilypond.org/test/ Perhaps it should be documented, maybe it already are. Doing "info ./Documentation/out/lilypond-contributor.info-1" I find: 8.1 Introduction to regression tests The regression tests are automatically compiled using special `make' targets. The output of the regression tests is also automatically So, what targets? The targets test* seems to have something with the regression directory to do, but I don't understand how to do a comparision to a known good set. . Do we have a known good set? . If so, how do I compare current output with it? Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Where is the bug tracker?
Wouldn't it be nice to have a link to the bug tracker from http://lilypond.org/devel/ Regards /Karl Hammar ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Critical issues
Graham complaind about 10 critical issues in the last lilypond report.
***
Issue 815: Enhancement: AJAX-powered search auto-completion for the online
documentation
Why is this a critical issue for the lilypond release?
***
Issue 1080: Regression: bar lines in double bar are positioned too close
together
"pnorcks" mentions commit 27a4d9354effb09c696925881ec4df007da8a0db
as a possible cause. Reverting part of that commit:
diff --git a/lily/bar-line.cc b/lily/bar-line.cc
index d3f21e5..85b2e52 100644
--- a/lily/bar-line.cc
+++ b/lily/bar-line.cc
@@ -196,11 +196,9 @@ Bar_line::compound_barline (Grob *me, string str, Real h,
/*
should align to other side? this never appears
on the system-start?
+ */
m.add_at_edge (X_AXIS, RIGHT, thin, 0);
m.add_at_edge (X_AXIS, RIGHT, thin, thinkern);
- */
- m.add_at_edge (X_AXIS, LEFT, thin, thinkern / 2);
- m.add_at_edge (X_AXIS, RIGHT, thin, thinkern / 2);
}
else if (str.find ("S") != NPOS || str == "|._.|")
{
gives me the attached grace-start result which resembles the 2.13.17
result presented in the bug tracker.
What should we do about it?
***
Issue 989: ensure that no information is only in the regtests
Though Graham complain about this issue in the "report",
this seems to be taken by Valentin. He has a list at
http://wiki.lilynet.net/index.php/Regtests
What to do about it?
Shall we discuss individual items on the list?
***
Issue 915: Multi-measure rests dependent on prefatory matter in other staves
There seems to be a fix: http://codereview.appspot.com/931041/show
Do you need help testing the fix?
***
Issue 1031: constantly-changing input/regression/rest-collision-beam-note.ly
If it is changes every time, what is the correct output?
grace-start.pdf
Description: grace-start.pdf
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Aligning single systems?
James Bailey:
> On 07.05.2010, at 21:53, David Kastrup wrote:
> > "Boris Shingarov" writes:
> >>> for theoretical work it often is necessary to write several short
> >>> systems in one line, interspersed with text.
...
> > \markuplines {
> > \justified-lines {
> > some text
> > \score { e''' \layout {} }
> > more text
> > \score { c \layout {} }
> > }
> > }
> > Nothing lines up. Text is in the sky, music systems are skewed.
> While not completely ideal, frequently, markup has to be aligned. So
> the original snippet:
[Bailey: attachment, above with \vcenter added]
One can add "placeholders" to define vertical extent (how do one make
it zero length?):
\version "2.13.0"
\paper {
indent = 0\mm
}
range = {
\hideNotes
4
\unHideNotes
}
\markuplines {
\justified-lines {
"some text"
\vcenter
\score { { \range e''' } \layout { } }
"more text"
\vcenter
\score { { \range c } \layout { } }
}
}
Regards,
/Karl Hammar
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Aligning single systems?
David:
> Hi, for theoretical work it often is necessary to write several short
> systems in one line, interspersed with text.
>
> I don't manage to have
> a) new systems continue aligned to the previous system in a line, like
> when doing
...
> b) to have interspersed text appear at useful height with relation to
> the surrounding score.
>
> An additional problem is when using lilypond-book: there is no baseline
> info for the included images, leading to additional nuisances when
> images are to be placed in-line.
With latex, I've done (see [1], for my tries):
\newcommand{\INL}[1]{\raisebox{-0.8ex}{\includegraphics[height=3ex]{#1}}}
...
The limit of the \emph{Medium} register in all female voices varies
from \INL{op31_fig4.eps}; as a general rule, however,
\INL{op31_fig5.eps} should be looked as the highest note.
...
But I have to hand-tune the \raisebox and the height.
> Would it be possible to have some Staff property, say, baseline-height
> that specifies a Staff line to be aligned with the baseline of
> surrounding constructs? If it were #f, we'd get the old behavior, and
> of course only one Staff's baseline-height could be heeded within a
> StaffGroup. This might not be easy to make work in lilypond-book, but
> at least for interspersed text and staffs all within Lilypond, it might
> help.
Good idéa!
What I would need is the total height, and the amount of space
below the staff,
The values are available in some form, since the notation manual
(for v2.13), sec. "4.6.1 Displaying spacing" demonstrates
\paper { annotate-spacing = ##t }, where one can find numbers for
bottom-of-extent and extent-estimate.
As a workaround one could, if possible, set thoose two heights (with
margins) to fixed values, then you'd only have to hand-tune it once.
Regards,
/Karl Hammar
[1] git://turkos.aspodata.se/musik.git
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
Kieren:
> > It's not obvious to me whether
> > c\chord #'(1 7)
> > should produce "c b" or "c bes". Musically speaking, I'd look at
> > the key signature; if it were c major, I would assume it meant
> > "c b" since "b" is the seventh note of the scale.
> >
> > This may be a problem for the numeric syntax. I suppose we could
> > define each number as being a perfect, major, or minor interval;
> > users can adjust those intervals with + or - as required.
>
> Or... we could use dodecaphonic intervals, i.e.
>
> c\chord #'(1 11) is a minor seventh
> c\chord #'(1 12) is a major seventh
>
> Of course, none of these ideas support systems with
> other-than-12-tones-per-octave
=(
I propose we skip the "number" things and go for a local translate,
see below last in mail.
One could misuse floating poing values:
c\chord_float #'(1 6.5) % minor seventh
c\chord_float #'(1 7.0) % major seventh
To explain that eis == f is doable, but how would one explain
that 3.5 == 4 ??
(That flaw was present in my inital proposal )
Rationals:
c\chord_rational #'(1 5/4 3/2) % "perfect" 3rd and 5th
% replace 5/4 etc. with the proper scheme expression
Cents:
c\chord_cent #'(0 386 702) % just intonation
Or other variants.
One could also define a shorthand translating thing, something like
(though I'm not shure what syntax to use):
"cis\chord_barre " ->
//
If we are discussing shortcuts to notate music (chordal notation are
shortcuts, is it not?), consider the similarity of:
<-> d\chord #'(1 3 5) % "parallell" music
{d fis a} <-> d\seq #'(1 3 5) % "sequential" music
There are two things here:
. replacing a note name with a number, eg. "e" -> 3
. naively replacing 3 for the interval third, gives use the enharmonic
problem of 3.5 == 4, and what does 7 mean, a minor or major 7th?
. using dodecaphonic, cents, retionals or the like somehow misses the
"shortcut"-idéa
. a local transposition, eg. d\chord... == \translate c d { c\chord... }
this would be a "better" \translate, since it would put the music
in the "current" octave
The chords are easily defined, we don't need any special
syntax for that (like \chordmode):
chord_major = \relative c { }
\translate below does not work since the "d" is not relative the
previous music:
... music ...
\translate c d \chord_major
... music ...
Could something like this (or some other syntax) be useful:
... music ...
d\tr\chord_major % --> in the current octave
... music ...
Going this route, one could define whatever complex chord expressable
in an ordinary <...>
Regards,
/Karl Hammar
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
Graham: ... > OTOH, what about doing something like this: > c\maj > c\dim > c\chord #'(1 4 5) > c\chord #'(1 3 5 7 11) I like this. Regards, /Karl Hammar ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why don't we get rid of \chordmode?
David Kastrup:
> Graham Percival writes:
...
> And what if you see \chordmode { c,4:1/c c g,:1/g c } in the input
> (which is basically how you put bass notes in now if you really must)?
...
For the simple chords c\maj c\dim c\maj7 etc. could suffice.
For more complex chords one could extend the syntax to .
Regards,
/Karl Hammar
-
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Solution for including a file only once
Reinhold Kainhofer: ... > In my view there are two different kinds of include uses: > 1) To include package-like .ily files, which define additional functionality. > There many utility functions really might/should be in their own namespace, > but many definitions (and in particular all \header, \paper or \layout > blocks) > need to be at toplevel. I would be interested in conditionally including files with \paper and \header blocks, so can with a command line flag get output for "choirbook" booklets or plain a4 sheets. The common thing with this thread would be the ability to \include thoose blocks. > 2) ... ... > I think it should be as easy and straightforward to use to a non-programmer > as > possible, while allowing more complex use without making easy things harder > than necessary for easy things. Ack. Regards, /Karl --- Karl HammarAspö Data k...@aspodata.se Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting --- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
...
> > or when there are lyrics to assign.
> What do you mean here?
> Do you mean lyrics to assign to the *second voice* (since the first
> voice assignment would be automagic)?
Try:
\version "2.13.0"
\score {
\new Staff {
\time 4/4
\relative g' { g4 << g \\ d >> g2 }
}
\addlyrics{ a b c }
}
No voice in the << \\ >> section gets any lyrics here.
Regards,
/Karl
---
Karl HammarAspö Data k...@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar +46 173 140 57 Computers
Sweden +46 70 511 97 84 Consulting
---
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: texinfo supports non-English hyphenation
it already partially It used English hyphenation patterns in all cases (and still does, if the real patterns aren't there). I didn't notice any hyphenation difference after updating texinfo.tex, but I guess TeXlive 2008 is needed to see improvements More precisely, what you need (besides texinfo.tex and txi-LL.tex) is an "etex" (or "pdftex") .fmt that includes the patterns. And indeed, this is the case by default in TL08 and was not the case by default in TL07. Although in principle you could change things around in TL07, I suspect it would be far less work for everyone to simply install TL08 if you want the new hyphenation. (The native install won't interfere with your system installation.) karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ly files as a MIMEtype?
Valentin wrote: > sometimes I wonder what it would take to register .ly files as an > official "text/lilypond" MIMEtype (for instance at IANA, on > http://www.iana.org/cgi-bin/mediatypes.pl ) Very nice idéa! But it seems you have to read a lot of rfc's for that. An easier way might be to file a "bug" report in debian like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379838 and other distributions. Or the lilypond installation might add it. ... > (if you don't know which icon I'm referring to, have a look at > http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob_plain;f=Documentation/pictures/ly.xpm > ) > > Therefore, I have taken the liberty to draw some icons (attached > here), based on the "note" icon. > - one follows the Apple human interface guidelines > - one follows the MS Vista guidelines (yeah, no comment) > - one follows the Tango guidelines (GNOME, XFCE and GTK) > - one follows the Oxygen guidelines (the official theme for KDE4) Wery nice examples, but I must say my first reaction is the it looks like a stand, a claw, or something, but not a note. > I don't know what to do with these, maybe you guys will have an idea. > It would be just great if GNOME or KDE included a default lilypond > MIMEtype Icon for .ly files (the Windows/Apple ones could just be > provided with the binary program). Great work. /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build requires t1asm
> It's a bit of a halfbaked solution. If you don't want to compile lily, > why not use the pre-rolled binary. > > Also, it would be nice if some of these perverse hackers could just > add an autoconf check for said program. Hmm, something like [1] (s/inkscape/t1asm/) ? [1] http://lists.gnu.org/archive/html/lilypond-devel/2007-10/msg2.html > On Fri, Jul 18, 2008 at 8:37 AM, Werner LEMBERG <[EMAIL PROTECTED]> wrote: > > > >> FWIW I also like the idea of having less dependencies, but not at > >> the price of being unable to hack the source. Even if that is the > >> source to a font. > > > > Well, adding pre-compiled fonts to the tarball just remove a > > dependency. As soon as you remove the fonts, they are rebuilt. > > Where's the problem? Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \once \macro
Graham:
> [EMAIL PROTECTED] (Karl Hammar) wrote:
> > > 1) Does anybody else remember if this worked in the past? (ie am
> > > I going crazy?)
> > {
> > c'4
> > \once \override Stem #'direction = #DOWN
> > %\stemDown
> > c'4
> > c'
> > }
> Yes, I know that works. I'm asking a general question about the
> way we handle tweaks, for documentation purposes. If I had an
> actual question about actually writing music, I'd sent it to the
> -user list.
I forgot to answer the question, I see. I tested 2.6.5 and 2.11.33 and
it did not work with them.
Regards,
/Karl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \once \macro
> I could have sworn that
>
> {
> c'4
> \once \stemDown
> c'4
> }
>
> worked, but it clearly doesn't.
> 1) Does anybody else remember if this worked in the past? (ie am
> I going crazy?)
...
Try
{
c'4
\once \override Stem #'direction = #DOWN
%\stemDown
c'4
c'
}
Regards,
/Karl
---
Karl HammarAspö Data [EMAIL PROTECTED]
Lilla Aspö 2340Networks
S-742 94 Östhammar +46 173 140 57 Computers
Sweden +46 70 511 97 84 Consulting
---
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incipits
Till:
> Juergen Reuter schrieb:
> > as far as I understand, all problems with incipits boil down to the
> > following two major issues:
> >
> > (1) horizontal spacing, and
I did not focus on that, it is an ancient notation issue, it is not
specific to incipits.
> > (2) the system start delimiter.
> >
> > Karl's solution unfortunately leaves horizontal space between the
> > incipit and the actual score; hence it does *not* solve issue (2).
> > Rather, the score lines should not stop inbetween.
If you don't like the space, then remove the \stopStaff \startStaff
thing. But then, whats wrong with the \bar "||" variant as Till suggests
below. (cont. below)
> Well, I am not so sure about that. I agree, the space is a bit too big
> here, but I personally like Nocolas' solution where the space mainly
> covers the distance between the choirstaff brace and the beginning of
> the staff. I know that much incipits are engraved with the double line
> method that is now used in the templates, but it feels logical to me
> that the "real" staff with the brace start only after the incipit. I
> somehow recall this would be also "hand engraved convention", but I
> might be wrong. There is an example pdf on the list sent by Stefan
> Slapeta that shows a broad range of incipits which show mainly the staff
> lines going through all the way. So it might be my personal opinion only
> that it would be nice to have the incipit seperated by a little white space.
Getting less space is simple, us less space between \stop-\startStaff.
See attached pdf.
$ diff -u c.ly.old c.ly
--- c.ly.old2008-02-11 19:41:54.923054408 +0100
+++ c.ly2008-02-11 19:42:34.417301808 +0100
@@ -34,8 +34,8 @@
\stopStaff
\once \override Score.TimeSignature #'print-function = ##f
\nor
- \time 3/8
- s4.
+ \time 1/16
+ s16
\revert Score.SpanBar #'print-function
\revert Score.BarLine #'print-function
\startStaff
@@ -74,7 +74,7 @@
\score {
\new ChoirStaff \with {
% a pain to set? Thats Right!!!
-\override SystemStartBracket #'extra-offset = #'( 38.8 . 0 )
+\override SystemStartBracket #'extra-offset = #'( 30.2 . 0 )
} {
<<
\new Staff {
>
> Till
> >
> > IMHO, all other features have been quite well demonstrated in template
> > A.5.1 for a while now. Hence, you probably should concentrate on
> > solving these two remaining issues.
> >
> > Regarding issue (2), maybe the "right" solution is to extend the
> > system start delimiter implementation in such a way, that
> >
> > (a) automatic printing at the system start may be suppressed for a
> > specific range of the score with kind of
> > "\turnSystemStartDelimiterOff" and "\turnSystemStartDelimiterOn"
> > commands, and
> >
> > (b) a kind of "\bar #'system-start-delimiter" command prints an
> > additional system start delimiter whereever you want. (But if this
> > bar should happen to appear at the system start, the delimiter
> > should not be printed twice.)
That would be nice, but you can use the workaround with the
extra-offset as shown above.
> > Regarding issue (1), I am not sure what the "right" solution is.
> > Please note that the note durations in the incipit are typically much
> > larger than in the actually score. Karl and Nicolas, did you check
> > what happens with the horizontal spacing in your incipit solutions, if
> > you double or quadruple the note durations in the incipit (and only
> > there)? In your examples, in the incipts you are unfortunately using
> > the same durations as in the actual score. I may be wrong, but I
> > suspect that your solutions do *not* solve issue (1).
No I did not try. Try this (\men \nor as in previous mail)
cold = { \clef "petrucci-c4" }
cnew = { \clef "treble_8" }
\new Voice \relative c {
\men\cold d\breve*1/8 e\longa*1/16 f\maxima*1/32 g\breve*1/8
\nor\cnew | d4 e2 f4~ | f2. g4 |
}
I tried with
B = #(ly:make-duration -1 0 1 8)
...
d\B e\L f\M
but it didn't work.
Maybe someone have know how to write a function \foo:
breve -> breve*1/8
...
I tried with
% as a first test
#(define-public (nop music)
(if (ly:duration? music)
(let music (ly:make-duration -1 0 1 8
foo = #(define-music-function (parser location music)
(ly:music?)
(let ((new-music (ly:music-deep-copy music)))
(music-map nop new-music)
new-music))
but it didn't work.
%%%
You can use the lsr snippet 305 to scale down the note values (and a
modern lilypond version). There is the proble
Re: Incipits
Han-Wen:
> Sorry for looking at this so late.
>
> General comments:
>
> - you're adding an enormous bunch of code to the instrument name
> engraver. That's a bad idea. If this idea merits an engraver, it
> should be a separate one.
...
> - If I'm reading this correctly, this is all a grand hack to add a
> little staff to an instrument name. I don't see the essential
> difference between this and
>
> \set instrumentName = \markup { \score { .. } the-real-name }
>
> except that this is longer, more error prone and less flexible. Again,
> what problem are you trying to solve?
>
> 2008/2/9, Nicolas Sceaux <[EMAIL PROTECTED]>:
> > > Here is draft patch: the Instrument_name engraver is used to create an
> > > Incipit grob before the first line when an incipit has been specified.
> > > There are several problems in it:
...
> > Both these problems are solved in the following patch.
> > Do core developpers see a problem with it?
Inicipits can be done with the code below.
Regards,
/Karl
%---
\version "2.6.4"
men = {
\override Accidental #'style = #'mensural
\override NoteHead #'style = #'petrucci
\override Rest #'style = #'neomensural
\override Staff.TimeSignature #'style = #'mensural
\override Stem #'flag-style = #'mensural
\override Stem #'thickness = #0.8
% \set Score.timing = ##f
\set Staff.defaultBarType = ""
#(set-accidental-style 'forget)
}
nor = {
\override Accidental #'style = #'default
\override NoteHead #'style = #'default
\override Rest #'style = #'default
\override Staff.TimeSignature #'style = #'default
\override NoteHead #'font-size = #'0
\override Stem #'flag-style = #'default
\override Stem #'thickness = #1.9
\override TimeSignature #'style = #'default
#(set-accidental-style 'default)
% \set Score.timing = ##t
}
staa = {
\override Score.SpanBar #'print-function = ##f
\override Score.BarLine #'print-function = ##f
\men
}
jump = {
\stopStaff
\once \override Score.TimeSignature #'print-function = ##f
\nor
\time 3/8
s4.
\revert Score.SpanBar #'print-function
\revert Score.BarLine #'print-function
\startStaff
\once \override Score.TimeSignature #'print-function = ##f
\time 1/16
s16
\override Score.SpanBar #'print-function = ##f
\once \override Staff.Clef #'full-size-change = ##t
\set Staff.forceClef = ##t
\clef bass
\time 4/4
\bar ""
}
%
% Music and lyrics
clefic = { \clef "petrucci-c1" }
vic = \relative c' { c1 c }
lic = \lyricmode { A B }
clefmc = { \clef soprano }
vmc = \relative c' { \vic d }
lmc = \lyricmode { \lic c d e f g }
clefib = { \clef "petrucci-f" }
vib = \relative c { a1 a }
lib = \lyricmode { A B }
clefmb = { \clef bass }
vmb = \relative c { \vib g }
lmb = \lyricmode { \lib c d e f g }
%
\score {
\new ChoirStaff \with {
% a pain to set? Thats Right!!!
\override SystemStartBracket #'extra-offset = #'( 38.8 . 0 )
} {
<<
\new Staff {
\set Staff.instrument = \markup { "Cantus" }
\context Voice = vc { \clefic \staa \vic \jump \clefmc \vmc }
}
\context Lyrics = lc \lyricsto vc { \lic \lmc }
\new Staff {
\set Staff.instrument = \markup { "Bassus" }
\context Voice = vb { \clefib \staa \vib \jump \clefmb \vmb }
}
\context Lyrics = lb \lyricsto vb { \lib \lmb }
>>
}
\layout {
\context {
\Score
\consists Span_bar_engraver
\remove System_start_delimiter_engraver
}
}
}
c.pdf
Description: c.pdf
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
Reinhold Kainhofer:
> Am Freitag, 1. Februar 2008 schrieb Nicolas Sceaux:
> > When typesetting ancient music, one may want to produce two editions:
> > eventually one with original clefs, as found in the manuscripts, and an
> > other one with new fashioned clefs. It is also custom in the later case
...
> Actually, we're already two ;-)
> I'm transcribing some old pieces by Schubert, who wrote the vocal voices
> using
> soprano/alto/tenor clef, while modern typesetting practice uses only the
> treble clef for these voices. Now, I want to make two editions, one with the
> original clefs, the other with modern clefs (but the original clefs as
> incipits). So, you see, I'm having exactly the same problem.
...
There is two problems here,
1, should the clef look ancient or modern, e.g.
{ \clef "petrucci-f" } or { \clef "bass" }
2, should we exchange a C clef for a G clef
For problem 1 one can look at what theese do
\displayMusic { \clef "petrucci-f" c1 c }
\displayMusic { \clef "bass" c1 c }
(make-music
'SequentialMusic
'elements
(list (make-music
'ContextSpeccedMusic
'context-type
'Staff
'element
(make-music
'SequentialMusic
'elements
(list (make-music
'PropertySet
'value
"clefs.petrucci.f"
'symbol
'clefGlyph)
(make-music
'EventChord
...
(ly:make-pitch -1 0 0
(make-music
'EventChord
...
(ly:make-pitch -1 0 0))
Where the difference is "clefs.petrucci.f" vs. "clefs.F".
So an \ancientToModernClef should traverce the list and exchange
ancient "clefs.xx" to a modern variant.
===
Problem two is similar
\displayMusic { \clef "petrucci-c2" c1 c }
\displayMusic { \clef "petrucci-c3" c1 c }
gives this diff
$ diff -u b.log b2
--- b.log 2008-02-02 20:46:38.888477652 +0100
+++ b2 2008-02-02 20:47:08.884108561 +0100
@@ -12,19 +12,19 @@
(list (make-music
'PropertySet
'value
-"clefs.petrucci.c2"
+"clefs.petrucci.c3"
'symbol
'clefGlyph)
(make-music
'PropertySet
'value
--2
+0
'symbol
'middleCPosition)
(make-music
'PropertySet
'value
--2
+0
'symbol
'clefPosition)
(make-music
and
\displayMusic { \clef "petrucci-c2" c1 c }
\displayMusic { \clef "petrucci-g" c1 c }
this
$ diff -u b.log b2
--- b.log 2008-02-02 20:48:23.373258918 +0100
+++ b2 2008-02-02 20:48:44.370200812 +0100
@@ -12,13 +12,13 @@
(list (make-music
'PropertySet
'value
-"clefs.petrucci.c2"
+"clefs.petrucci.g"
'symbol
'clefGlyph)
(make-music
'PropertySet
'value
--2
+-6
'symbol
'middleCPosition)
(make-music
To make a generic \changeClef one has to find the part between a-b below (a
list), and exchange it for something else
(make-music
'SequentialMusic
'elements
(list (make-music
'ContextSpeccedMusic
'context-type
'Staff
'element
(make-music
'SequentialMusic
'elements
a
(list (make-music
'PropertySet
'value
"clefs.petrucci.g"
'symbol
'clefGlyph)
(make-music
'PropertySet
'value
-6
'symbol
'middleCPosition)
(make-music
'PropertySet
'value
-2
'symbol
'clefPosition)
(make-music
'PropertySet
'value
0
'symbol
'clefOctavation
b
...
(ly:make-pitch -1 0 0))
=
Or what do you think.
/Karl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
Nicolas Sceaux:
...
> \tag does not solve the first-clef detection problem, but the two
> editions problem, about which the proposed patch is not about.
> I know about \tag,
...
I also find \tag messy and there is no "else" part either.
> > Anyway, wouldn't it be nicer to have some kind of scheme macro that
> > expands to code that prints an incipit? Your "first clef" could
> > then be just part of the incipit that the macro creates. And maybe
> > the clef's name either could passed as argument to the scheme
> > macro. Or, alternatively, you set an, say, "original-clef" property
> > that the macro recognizes and accordingly acts upon.
>
> As I understand it, incipits are hackingly achieved using the
> instrument name. I want instrument names to be defined separately
> from incipit (they are not the same thing, there is no serious
> reason to bind them, beside purely technical ones):
>
> \new Staff <<
>\global
>\set Staff . instrumentName = \markup { The instrument name }
>\clef "xyz" %% automagically set the incipit clef
>{ ... the notes ... }
> >>
>
> How could you make the mix of the two?
>
> Now, seeing the incipt examples, I realize that my patch is a hack
> too, for it would be nice to have also the time and key signatures,
> not only the ancient clef.
For the time and key signatures you can have to varialbles like
mensural = {
\override Accidental #'style = #'mensural
\override NoteHead #'style = #'petrucci
\override Rest #'style = #'neomensural
\override Staff.TimeSignature #'style = #'mensural
\override Stem #'flag-style = #'mensural
\override Stem #'thickness = #0.8
\set timing = ##f
\set Staff.defaultBarType = ""
#(set-accidental-style 'forget)
}
normal = {
\override Accidental #'style = #'default
\override NoteHead #'style = #'default
\override Rest #'style = #'default
\override TimeSignature #'style = #'default
\override NoteHead #'font-size = #'0
\override Stem #'flag-style = #'default
\override Stem #'thickness = #1.9 %
default
\override TimeSignature #'style = #'default
#(set-accidental-style 'default)
}
and use them like
\new Staff { \normal \relative c' { ... } }
\new Staff { \mensural \relative c' { ... } }
For the clefs I use
%clefcs = { \clef "petrucci-c2" }
%clefct = { \clef "petrucci-c4" }
%clefcb = { \clef "petrucci-f" }
clefcs = { \clef "treble" }
clefct = { \clef "treble_8" }
clefcb = { \clef "bass" }
What I think would be useful is either a setting
\override Clef = #'style = #'petrucci % e.g "alto" -> "petrucci-c3"
\override Clef = #'style = #'modern % e.g "petrucci-c3" -> "alto"
\override Clef = #'style = #'lazysinger % e.g "petrucci-c3" -> "treble"
so I can include them in the variable above
or a function like
% always keep as close to source as possible
aa = \relative c { \clef "petrucci-f" \time 2/2 c\breve d\longa ... }
\makeThisMensural { \aa } % no change?
\makeThisModern { \aa } % "petrucci-f" -> "bass", c\breve -> c1 ...
\makeThisIncipit { \aa } % mensural but only first breve or semiminima
> Maybe creating an incipit engraver, reading new context properties,
> like incipitKeySignature, incipitTimeSignature, etc, and creating a
In some instances it would be useful to be able to append \score's on
the same line, somewhat like if you used { \startStaff s1 \stopStaff }.
Regards,
/Karl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ancient notation: spacing, ligatures, bar lines: some ideas...
additional space that is counted to fit normallly between noteheads gets
> accumulated at the end of the ligature.
I see no other way if you use it in a score, what would you otherwise
do (i.e. if you want the notes to line up)?
In a single voice you could write it like
music = \relative c' {
d\breve*1/8 d\longa*1/16 b\breve*1/8 b\longa*1/16
}
then they get shorter, but it is very annoying.
That might be a way to get all notes to take up the same space?
> In addition, the space which the
> barlines would normally take gets still added to the space (since
> ligatures are normally long notes, they use quite a lot of bars). So my
> naïve idea would be to count the amount of space of all ligature heads
> minus the real head-width and subtract this amount from the space of the
> ligature.
> Unfortunately I know too few about programming to already provide some
> code here.
I assume you are using a single voice here?
> Well, another problem of the ligatures is their behaviour inside a
> Cadenza. They take up too few space so other notes start protruding
> them. This happens only, when the changed spacing values presented above
> are used. If used with the normal spacing engine, ligatures work out
> fine. But: when not using "zero-spacing" the spacing is again too wide.
> This means that we cannot use Cadenza at the moment to display tightly
> spaced notes containing ligatures.
>
> Actually, also the ligature brackets in the normal notation get badly
> cruched by the tight spacing: suddenly they appear in some cases to be
> too short and won't cover all the notes actually included in the
> ligature. Hopefully somebody has some hints at what I could look to make
> ligatures behave correctly. Juergen, do you have time reading the list?
>
> If assuming that my ideas about the spacing engine are correct I thought
> to implement the tight spacing somehow into the MensuralStaff which
> automatically should call mensural voice -- there could be differently
> named staves and voices containing the different notation style that are
> available for ancient notation.
The thing to do this would be to space the notes according to their
graphical size not their "time"-size. And a possible way to do that would
be to assign them the same timevalue. But that would only work single
voices unless you pad with a lot of \skip's.
One way would also be to simulate the movable type print process, have
some scans and stack them along the x-axis like lego.
But, anyhow I am satisfied with the result in
http://aspodata.se/noter/binchois/
(Yes I could done the editor accidentals smarter.)
> I hope you can bear my unprofessional approach, I am only learning how
> things work inside of lilypond.
In you example (attached in your following mail), why don't you use
#(set-accidental-style 'forget)
and what do the
\override Staff.Accidental #'glyph-name-alist =
#alteration-mensural-glyph-name-alist
do?
Regards,
/Karl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
texi2dvi, @appendixsubsec and utf-8
When running $ make web > log 2>&1 i get: ./fdl.pdftexi:371: Undefined control sequence. SUPPLÃ<89> MENT : comment utiliser cette licence pour vos documents when it tries to run texi2pdf --batch lilypond-program.pdftexi in Documentation/fr/user/out-www The lines in fdl.pdftexi is: @page @appendixsubsec SUPPLÃ<89>MENT : comment utiliser cette licence pour vos documents Copying SUPPLÉMENT to two lines below makes the error message go away... Soo, what is going on, cannot you have utf-8 chars in arguments to @appendixsubsec, is my texi2pdf broken, or what? $ texi2pdf --version | head -1 texi2dvi (GNU Texinfo 4.8) 1.34 Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Inkscape needed for make web
Suggests attached patch. Regards, /Karl diff --git a/configure.in b/configure.in index 15a41e9..8c98e9a 100644 --- a/configure.in +++ b/configure.in @@ -176,6 +176,9 @@ STEPMAKE_GUILE(OPTIONAL) # perl for help2man. STEPMAKE_PERL(OPTIONAL) +# inkscape for make web, to generate svg-files +STEPMAKE_INKSCAPE(OPTIONAL) + # New makeinfo for multi-page website docs Simply always require new # makeinfo should avoid bug reports; if people want to build lily # without the docs, they can find this comment and use an older diff --git a/stepmake/aclocal.m4 b/stepmake/aclocal.m4 index b69dc9c..5afdc76 100644 --- a/stepmake/aclocal.m4 +++ b/stepmake/aclocal.m4 @@ -1305,3 +1305,7 @@ AC_DEFUN(STEPMAKE_WINDOWS, [ STEPMAKE_PROGS(WINDRES, $target-windres windres, x) AC_SUBST(WINDRES) ]) + +AC_DEFUN(STEPMAKE_INKSCAPE, [ +STEPMAKE_PROGS(INKSCAPE, inkscape, $1) +])___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bash completion strings
[EMAIL PROTECTED]: ... > In order to handle the .ly-extension correctly, on needs to install bash > completion string in file /etc/bash_completion.d/lilypond : > > # LilyPond completion. > complete -f -X '!*.@(ly|LY)' lilypond Nice tip, but you have to have the shell option extglob to be able to use the @(...) construct: $ complete -f -X '!*.@(ly|LY)' lilypond $ lilypond $ shopt -s extglob $ complete -f -X '!*.@(ly|LY)' lilypond $ lilypond Mliv.ly Sliv.ly ... $ lilypond Why not just ignore uppercase LY and add lytex complete -f -X '!*.ly' lilypond complete -f -X '!*.lytex' lilypond-book Regards, /Karl --- Karl HammarAspö Data [EMAIL PROTECTED] Lilla Aspö 2340Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting --- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Saying hello and considering my first contribution
[EMAIL PROTECTED]:
> I am currently working with a cataloging project at the British
> Library which is recording all musical manuscripts between the years
> 1600 and 1800, I have developed an application for them to data input
> and manage the manuscripts. The information supplied with each
> manuscript sometimes comes with an "incipit" for the beginning of the
> music. Here is an example of an entire incipit pulled from the
> record for Sonata 1 by Johann Sebastian Bach:
>
> ''4G{3G FbEDC'BA5 BG}{8GxF+}{3FEDEFGA''5C'B}/''8{C+3C5DC'3B''C}
> {6.Ct'5B''C6D'A}'' 8G'3-{G5AB''CD}{8b E'B}/{6BA''bED}8-{BxF}
> {6D3DbEDC'B''5C'A}{3BxFGDbE''5DC'B''CC'B''C}/
>
> I would like to convert this to Lily textual notation so that Lily
> can then reproduce it in musical notation so regular users of the web
> catalogue can just click a link and run this up into Lilypond. My
...
If you provide the syntax rules for the record I might be able to help
you. Will the archive be publically searchable or is just for thoose
who have a subcription?
Regards,
/Karl
---
Karl HammarAspö Data [EMAIL PROTECTED]
Lilla Aspö 2340Networks
S-742 94 Östhammar +46 173 140 57 Computers
Sweden +46 70 511 97 84 Consulting
---
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GIT pull error
[EMAIL PROTECTED]: > Sorry. Now I actually checked: the url is > > http://git.sv.gnu.org/r/lilypond.git > > (Note that not only "http://"; is new, but also "/r/"). Ok, so I update this file: $ grep URL .git/remotes/origin URL: http://git.sv.gnu.org/r/lilypond.git $ in my local copy, $ git-pull Fetching refs/heads/master from http://git.sv.gnu.org/r/lilypond.git using http got 6ba19b9f48c1ce10adb30a69557ce38b8a073785 walk 6ba19b9f48c1ce10adb30a69557ce38b8a073785 ... and things works again. Regards /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
git problem
Does anybody have a solution for this problem? $ git-pull fatal: protocol error: bad line length character Fetch failure: git://git.sv.gnu.org/lilypond.git fatal: protocol error: bad line length character Failed to find remote refs No changes. Regards /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Melisma_translator obsolete?
>From Documentation/misc/ChangeLog-2.10:
2006-08-02 Erik Sandberg <[EMAIL PROTECTED]>
...
* ly/declarations-init.ly: change melisma/melismaEnd. Eliminates
ManualMelismaEvent, and obsoletes Melisma_translator.
So what should be done with:
$ lily_git -I input/manual input/test/engraver-one-by-one.ly
GNU LilyPond 2.11.12
Processing `input/test/engraver-one-by-one.ly'
Parsing...
error: unknown translator: `Melisma_translator'
$
and
$ grep Melisma_translator python/convertrules.py
str = re.sub (r'Melisma_engraver', 'Melisma_translator', str)
$
???
Regards
/Karl
export LILY_SRC_DIR=$HOME/most/music/lilypond/git/lilypond
lily_git() {
$LILY_SRC_DIR/out/bin/lilypond --relocate "$@"
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond font design
[EMAIL PROTECTED]: > I was wondering if I could start some contribution to the medieval > notation support via redesigning the fonts that in my opinion don't look > very good. Especially referring to the mensural notehead style (I think ... Great! Is your goal, like Guthenburg, to make a few e's etc, to simulate the variability of handwriting also? Would that be possible within lilypond? == Btw, I have found an antiqua font: http://moorstation.org/typoasis/designers/lab/lab_dayroman.htm which could be useful. The copyright seems to be Hope the ghost of Guyot looks good enough for your designs. Have a blast with it. If you use it commercially, give something to your favourite charity, will ya? I will try to make it usable within lilypond, though I don't know how to handle the diftongs or the cases where there is two variant of the same letter. Is any who knows how to include tex's yfrak frakture fonts? Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Styles [Was Re: Barline scans]
[EMAIL PROTECTED]: > Karl Hammar wrote: > > [moving this from bug-lilypond] > > > > [EMAIL PROTECTED]: > >> Karl Hammar wrote: > >>> Maybe we should have a "my style" section in the doc. > >> Like section 4.3 Style sheets ? > > > > There you tell us how to do it. But perhaps more like the snippet > > respository, examples of different styles. Right now we "only" have > > one style, the default one. Plus "tweaks", where the tweaks are more > > something you do when lilypond don't cope with it, not a different > > style. > > I have no objection to this; see > http://lilypond.org/web/devel/participating/documentation-adding I guess it would go to 9.4 Style examples. Before I can present any "new" style I have to make one though. Regards /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Styles [Was Re: Barline scans]
[moving this from bug-lilypond] [EMAIL PROTECTED]: > Karl Hammar wrote: > > Maybe we should have a "my style" section in the doc. > > Like section 4.3 Style sheets ? There you tell us how to do it. But perhaps more like the snippet respository, examples of different styles. Right now we "only" have one style, the default one. Plus "tweaks", where the tweaks are more something you do when lilypond don't cope with it, not a different style. Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: makeinfo with utf-8 support
> [EMAIL PROTECTED]: > > Le jeudi 04 janvier 2007 à 00:33 +0100, Karl Hammar a écrit : > > > Hmm, when building I get: > > > > > > out/lilypond.nexi:62: warning: unrecognized encoding name `utf-8'. > ... > > > Does anybody know where the makeinfo with utf-8 support is, a patch ? > > > > AFAIK Texinfo does no character encoding conversion for the Info and > > HTML output, so the LilyPond devels have decided to use the modern > > character set UTF-8, not Latin1. This will really become a problem for > > the PDF (outputted by Texinfo/TeX) when we decide to make PDF of Lily > > docs translation. > > > > Well, you can safely ignore these warnings. > > > > See also > > http://lists.gnu.org/archive/html/lilypond-devel/2007-01/msg00047.html > > Tried cvs version [1] of texinfo/makeinfo > > $ makeinfo --version > makeinfo (GNU texinfo) 4.8.90 > > But the warning persist. Well, never mind. > > Regards > /Karl > > [1] http://savannah.gnu.org/cvs/?group=texinfo This is fixed in latest texinfo cvs: Karl Berry: > I just added UTF-8 to the list of encoding names recognized by makeinfo > (from CVS). It just passes through the bytes as they are received, > which hopefully will be better than nothing. I can't undertake to > actually parse UTF-8 at this point (I added it to the TODO file :). > > Thanks, > Karl Regards /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond suggestions
[EMAIL PROTECTED]:
> Jesse Engle wrote:
> >
> > 4.) There is no way to create an entire page of exercises (a feature
> > that would be incredibly useful for music teachers such as myself)
> > like this:
> >
> > http://jengle.waferbaby.com/tmp/lp/exercises.png
> Actually, you could do this too within LilyPond, since you can use
> \markup commands to create several columns and you can embed scores
> into a \markup command. Here's a simple example:
...
Whu not use \startStaff and \stopStaff, like:
\score {
<<
\new Staff {
\relative c' {
\clef alto c1 c \stopStaff s1
\startStaff b1 b \stopStaff s1
\startStaff a1 a \stopStaff
}
}
\new Staff {
\relative c' {
\clef alto c1 c \stopStaff s1
\startStaff b1 b \stopStaff s1
\startStaff a1 a \stopStaff
}
}
\new Staff {
\relative c' {
\clef alto c1 c \stopStaff s1
\startStaff b1 b \stopStaff s1
\startStaff a1 a \stopStaff
}
}
>>
}
See staff-halfway.ly [1] in the regression tests.
[1] http://lilypond.org/doc/v2.11/input/regression/lily-1a72868935.ly
Regards
/Karl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
