I don't know how to check for --enable-double
There is `-D' appended somewhere after the date in fontforge's version
string, e.g.
Executable based on sources from 23:14 GMT 25-Feb-2011-ML-TtfDb-D.
^^
Werner
[Note that I'm not a Windows user.]
It's all a bit academic if no one can point me to a Windows
implementation of texi2pdf or texi2dvi, though.
Perhaps trying the `texify' program from MikTeX? Look here
http://ftp.uni-erlangen.de/mirrors/CTAN/systems/win32/miktex/tm/packages/
and search
So, with this idea in mind, I'd like to kick off a discussion about
the next stable release. Assuming that we can fix all the critical
issues (I think that's possible, but may be a month out or so),
what else should we plan to have part of the next stable?
Normally, a route to a stable
Normally, a route to a stable release means a code freeze, applying
only fixes to problems within the code. This also means that no
new bug fixes get applied. Are we going to do the same?
I don't understand the difference between the two - wouldn't a bug
be a problem within the code?
I
Normally, a route to a stable release means a code freeze, applying
only fixes to problems within the code. This also means that no
new bug fixes get applied. Are we going to do the same?
I think Werner means fix only things that are not working as
advertised, but defer fixes that are
Can someone do a survey how other free software projects handle this?
We could also set up a Pledgie campaign, however, this also cuts off
3% (or more) of the money.
97% of something is more than 100% of nothing.
Indeed.
What about setting up a whole bunch of lilypond crowdfunding
I am not sure whether the q stuff should be slated for 2.16. It
greatly simplifies things and decreases potential for problems, but
I don't see people reporting any test results, and it certainly has
seen less user contact than my totally new code.
As soon it is in master, I'll check it.
So check it out at least once it is in Patch-review orderly. That
means that it is regtest-clean, but that does not mean that a
feature change will make its main users happy.
OK. BTW, I've meant staging, not master. Sorry for the thinko.
And I might point out that it was you who
OK. BTW, I've meant staging, not master. Sorry for the thinko.
Same thing. Once it is in staging, it will move forward
_automatically_ to master potentially within hours unless there is a
compilation/testing error.
Humpf. I wasn't fully aware of this automatism.
OK, will apply manually
[Applying rietveld 5595043 to git afb4c5fb]
It means running your own files that use this feature, and reading
the docs to see whether the docs as well as the new incarnation of
the feature make sense to you.
It was really good that you have been a pain in the neck, since your
patch causes
[Applying rietveld 5595043 to git afb4c5fb]
It means running your own files that use this feature, and reading
the docs to see whether the docs as well as the new incarnation of
the feature make sense to you.
It was really good that you have been a pain in the neck, since your
patch
Let me just quote one item by screenshot [...]
This looks excellent. However, I don't understand the last sentence.
What do you mean with `not transferred'?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
I reworded the text and changed the example. It should now be
clearer from both text and picture.
Yes, thanks.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
L'Isle joyeuse:
master: 0m30.432s
patched: 0m46.997s
Psalm 94 (Reubke):
master: 1m31.692s
patched: 2m0.817s
In my opinion, these times are too high to justify the gain that one
gets from using fine-tuned vertical skylines.
Yes, unfortunately.
Werner
To all interested parties, this work is now up on:
dev/skylines
Thanks. A minor thing which causes me grief each time I see it:
Please configure your editor so that it automatically inserts a
newline character at EOF.
Werner
___
Folks,
openSuSE is now packaging guile 1 and guile 2 separately, and the
former comes with a `guile1-config' script, and the binary is called
`guile1'.
Given that lilypond doesn't work reliably with guile 2 yet (at least I
got a segfault during `make all') it might be a good thing to make it
Attached is a very primitive patch which works for me.
That patch looks like it would stop working the moment you also
install Guile 2.
I don't think so, but admittedly I haven't tested it. The patch is
bad, I know; it's just to tell people what I have done to compile
lilypond with the
I don't think so, but admittedly I haven't tested it. The patch is
bad, I know; it's just to tell people what I have done to compile
lilypond with the `guile1' package from openSuSE factory.
I've pushed a slightly modified version to staging. It improves the
situation for distros that
Somewhat independently, there is a mf2pt1.pl Perl script that
(shudder) generates .pe script to transform a metapost output to a
Type 1 font. I guess that could be done more concisely directly as
a python script.
This sounds like a very nice addition. Maybe generating Python should
be the
Metatype1 is hosted on a polish server:
http://www.gust.org.pl/projects/e-foundry/metatype1
At the time I did the transition to mf2pt1, I had compared the various
approaches of converting METAFONT outlines to Type1 fonts. mf2pt1
appeared as the most straightforward approach, much easier than
I found this comment in the font generation scripts:
# crashes fontforge, use PUA for now -- jcn
# SetUnicodeValue(i + 0xF, 0);
SetUnicodeValue(i + 0xE000, 0);
It seems that this comment is obsolete: fontforge (at least, my
version) no longer crashes if I use 0xF. Is one range
should we rather try to break inside Pango to be able to create
precise outlines for everything that is processed by Pango? The
advantage of this approach would be that lyrics and markups would
be skylined even better.
The reason we are using Pango in the first place is because it is
Folks,
to check the Savannah status, look here:
http://identi.ca/group/fsfstatus
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Trying to compile 55d9ad39, I get this:
scripts/build/out/help2man \
out/lilypond-invoke-editor out/lilypond-invoke-editor.1
Can't exec out/lilypond-invoke-editor:
No such file or directory at scripts/build/out/help2man line 193.
help2man: can't get `--help' info from
scripts/build/out/help2man \
out/lilypond-invoke-editor out/lilypond-invoke-editor.1
Can't exec out/lilypond-invoke-editor:
No such file or directory at scripts/build/out/help2man line 193.
help2man: can't get `--help' info from out/lilypond-invoke-editor
make[1]: ***
From what i see, the skylines are now more precise than they need to
be - every glyph has a skyline of 10 or so boxes, even if it's a
single letter! (see attached)
I second this.
I think the proper solution would be to:
a) set minimal step size to 0.2 staffspace (or more in case of
bigger
This should do it:
- AC_PATH_PROG($1, $2)
+ AC_PATH_PROGS($1, $2)
Yep, thanks.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Feel free to commit
Done.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Once you have checked that the recent fixes have not caused any of
your work to get lost and the criss-cross merge has been done, you
can continue committing to the translation branch.
I apologize for the inconvenience.
Thanks a lot for fixing this. Do you recommend a modification of the
Google has developed and makes available a tool for C++ developers,
and I wondered if it might be of interest to the Lilypond devels.
From the website: AddressSanitizer (ASan) is a fast memory error
detector. It finds use-after-free and out-of-bound bugs in C/C++
programs.
Folks,
you might consider the topic of this blog entry quite off-topic, but
it shows some details on how to profile Scheme. It was quite
interesting to read, however, I understand only a small percentage :-)
I suggest that the vertical spacing alrogithm should calculate the
area between the objects (staves, systems, lyrics etc). See here
how it would work: http://www.freeimagehosting.net/tsr21
Looks right: The area between horizontal skylines should influence the
spacing. However, I think we
Looks right: The area between horizontal skylines should influence the
spacing. However, I think we need a parameter to adjust the amount of
influence.
I'm not sure what you mean.
I mean that some people probably want a more rigid spacing, only
slightly influenced by the area inbetween.
Janek,
please do
s/syllabe/syllable/
Besides this, it looks nice, and hopefully everything runs fine! BTW,
expect delays with the schedule :-)
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Folks,
I really appreciate that `make doc' doesn't flood the console.
However, right now I see a long line calling lilypond-book.py which
sits there for already more than 15 minutes without any progress
indicator at all. This is perhaps too extreme and suitable only to
the supercomputers some
We're saving stdout and sterr to log files so we can keep the
output. Any additional info that lilypond-book prints would just be
saved to a file instead of screen.
There are more streams available than stderr and stdout, so it would
be actually possible to save stderr and stdout from
Git history will judge us all.
Interesting. Up to now I've assumed God does this.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Interesting. Up to now I've assumed God does this.
If HE weren't a fan of distributed version control systems, why
create the world in the first place?
Good point :-)
This reminds me of a joke:
Two planets meet.
`How are you?'
`Well, not very well.'
`How comes?'
`I suffer from
I've received a couple e-mails from colleagues and one nudge from
Valentin about:
http://concours.afim-asso.org/
Aah, very nice! Yes, participating in this contest would be a good
thing; and thanks for your offer to writing up the application.
1) Use it internally on projects (i.e. we'd
I'm trying to use the nice Feta braces in an OpenType math font I'm
working on[1] that is licensed under OFL which is is not compatible
with the GPL license of Feta. I'm wondering if it is possible to
have permission for using Feta braces under OFL?
Hello Khaled!
I support your request,
I don't mind relicensing the font under a more permissible license.
Werner, do you know of a suitable license for open source fonts?
Dual (multi) licensing is also possible: GNU GPL Font Exc. + OFL ?
Yes, dual-licensing with OFL sounds like the best solution.
Werner
But what about \footnote: that does not have this problem.
In fact, isn't generally prettier than s1*0? Should we be using
it in code and documentation rather than s1*0?
What a great idea! No notes generated; the duration doesn't
change.
Indeed! I wasn't aware that is valid syntax
There is a drawback, though. q is changed. Now q is implemented as
but with the current duration on it. Which would mean that the
total moment of
{ c4 q }
would likely change when q gets expanded. While c _is_ considered
for q for consistency's sake, perhaps should be made to
Warning! This is an off-topic e-mail.
I think it leads to the perlization of lilypond, where we end up
looking like a ridiculous language like Haskell.
What exactly is `ridiculous' in Haskell? Personally, I find this
language quite fascinating.
Werner
I don't understand why David's proposition, which is both cheap and
neat, faced such opposition. I, for one, will be using the new
idiom.
+1. I'm open to syntax improvements, but currently I fail to see one
which fulfils the necessary constraints. As other have suggested:
Let's do this
What about a real-life meeting? There will be a GNU conference in
Dusseldorf (west Germany) in second half of July, maybe we could
meet there for a couple of days and sort out some big picture
stuff?
Sounds great!
There is a piano here as well, but its tuning is sort of rural, too.
Oh,
The jury wishes to congratulate you on your LilyPond open source
software, that won the First Prize at the LoMus 2012 contest.
Great!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
we have
txi-de.tex txi-en.tex txi-es.tex txi-fr.tex txi-hu.tex txi-it.tex
in tex/, so I guess we also want txi-nl.tex.
Added.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Folks,
can someone with a fast machine please test whether a recent
texinfo.tex file works for the lilypond documentation? Simply replace
tex/texinfo.tex (temporarily) with this file:
http://cvs.savannah.gnu.org/viewvc/*checkout*/texinfo/doc/texinfo.tex?revision=1.365root=texinfo
I get an error
attached error log
Bug in Texinfo. It looks like this texinfo.tex can't deal with \ in
section titles. But \ is not supposed to be a special character in
Texinfo files.
Could you provide a minimal example, please? I'll then make a texinfo
bug report.
Werner
Due to this marvellous video
http://www.youtube.com/watch?v=345o3Wu95Qo
I have learned that short slurs and ties aren't engraved manually;
instead, there are ready-to-use stamps. In other words, since the
number of such stamps is limited, tie and slur shapes become discrete
if their length
People can argue that this is an unnecessary limitation; lilypond
can do a `better' job. However, I'm not sure whether we should do
better...
We should, definitely!
There are bad tie and slur shapes in Lily, but this is not due to
not having discrete lengths.
Umm, yes. I've meant:
Frankly, I don't see the point in simulating well-craftedness by
artificially introducing minor deficiencies associated with some of
the better work.
@Werner: i could live with an *option* doing this, but i doubt that
people are interested in writing it. And i think we have much,
much,
Bug in Texinfo. It looks like this texinfo.tex can't deal with \ in
section titles. But \ is not supposed to be a special character in
Texinfo files.
Looking up the bug-texinfo mailing list archive, I now remember that
I've diskussed this by myself :-/. It is an endless grief,
Travel by train or bus should focus on Dortmund, about 9 miles from here
and the next large city.
What a pity that I won't have time from mid-July to mid-August, given
that my two larger children live in Dortmund (I have lived there for
15 years also)... In other words, I wouldn't need an
Frankly, it always confuses me when i have to code a thick line
using . - it's very unintuitive. What about changing this to
some other character? Maybe uppercase i? It looks thicker -
unless you use a sans-serif font...
+1
I thought about uppercase I, too. |I looks not too bad.
Uh,
Uh, oh, please not a letter. I almost always use seriffed fonts, and
it looks rather strange. What slightly longer but easy to remember
symbolics?
|
||
How about ! then? It actually has both | and . in it, and it _is_ a
sentence ending punctuation.
|| |:
!: or !|: (I
The inspiration for this ,@ is described as
If an `(unquote-splicing expression ...)' form appears inside a
qq template, then the expressions must evaluate to lists; the
opening and closing parentheses of the lists are then stripped
away and the elements of the lists
If I break down the example I listed before, here are a few
useful ways of applying it:
This is much easier to understand, thanks. However:
; this $@ produces elements for a sequential music list via map!. Each
; element is constructed from p, a list of pitches making up a chord,
; and
(map! + '(1 2 3) '(4 5 6)) = (5 7 9)
You must not! not! not! use map! on constant lists.
Interesting. This is something non-obvious, at least after reading
the Guile documentation. Now, knowing what you've just written, a
second read makes much more sense, and I can see that this
As a sort of emergency measure, I would consider it sensible if we
did a source-only release of 2.14.3 or, if you want to, 2.14.2a, the
same as 2.14.2 plus cherry-picked compilation fixes. Namely just
what it takes to get 2.14.2 through the current compilers.
+1
Werner
There is just one patch I put in the repo (Werner's slur/tie fix)
that is causing cyclic dependencies in some of his scores.
Maybe it's caused just by using an unoptimized build (which I always
do)? I couldn't see any problems in the output.
Werner
I seem to remember that Werner was away until the middle of August,
and the school holidays last until August 21st.
I've now booked a fly to Dortmund (in addition to visiting my two
children there will be probably a performance of my piece for Cello
orchestra), staying there from Aug 15th to
[...] I'm afraid I can't be present. I'm not really a core
developer, so couldn't contribute much to the discussion anyway.
This doesn't matter. It's fully sufficient that you are capable of
drinking beer, I presume :-)
Werner
___
I don't know exactly what a sort-of commune in a rural region
means. :)
This essentially means that you are eating the same as the horses.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Sorry for the long delay. The second batch of dates in August are
doable for me (Friday the 24th to Tuesday the 28th). Keep me posted!
Ok with those who already said they could make the first date?
I've booked my flights (15th to 20th) already some weeks ago, but this
shouldn't be a
Pity. If you say you booked your flights already for the sake of
visiting your relatives, this would probably imply that you would
not likely have had more than a day to spare anyway, right?
Werner
___
lilypond-devel mailing list
Folks,
I'm quite allergic to overly long lines in any kind of documents.
Particularly the various Makefiles have become unreadable IMHO, so I
suggest something similar to the attached version of the top-level
`GNUmakefile.in'. What do you think?
Werner
PS: If you want to compare with
I'm quite allergic to overly long lines in any kind of documents.
Particularly the various Makefiles have become unreadable IMHO, so I
suggest something similar to the attached version of the top-level
`GNUmakefile.in'. What do you think?
Oops, this was the original file, now comes the new
Oops, this was the original file, now comes the new one.
And here is a revised version which shortens even more overlong lines.
Werner
# -*-Makefile-*-
depth = .
SUBDIRS = \
python scripts \
flower lily \
mf ly \
tex ps scm \
po make \
elisp vim \
input \
stepmake
Consider this example file `foo.ly':
\version 2.15.41
\paper {
page-breaking = #ly:one-line-breaking
}
\header {
copyright = ##f
footer = ##f
tagline = ##f
}
\relative c' {
\repeat unfold 200 { d16 d d d e e e e f f f f g g g g }
}
If called with
lilypond
This might be of interest to some of you. Search for `Lilypond'.
Werner
---BeginMessage---
GNU Source-highlight 3.1.7 has been released. It is available from
ftp://ftp.gnu.org/gnu/src-highlite/ and mirrors of that site (see
list of mirror sites at http://www.gnu.org/order/ftp.html).
GNU
SUBDIRS = \
python scripts \
I'm a big fan of splitting lists into one entry per line; esp. if
you break at position 20 rather than 78.
Yes! Of course, if you have a lot of small entries like
SUBDIRS = \
foo bar baz foz fuz buz
vertical alignment is probably harder to read.
Where do the additional vertical 1000px come from? Looks like a
bug...
It comes from the height of the page: ly:one-line-breaking doesn't
(currently) adjust the height, but only the width.
Ah, ok. I've only skimmed the code with gitk and missed that. I
suggest to (optionally?) adjust
* could you and Jan decide a formatting convention that we can apply
by hand or with a script?
I don't have a definite answer on that; usually I follow my gut
feelings. If in doubt, I use a more vertical formatting. Most of the
decisions are simply a consequence of trying to stay within the
Folks,
compiling git 17270930 with gcc 4.6.2 I get the following warnings:
beaming-pattern.cc:
In function
'void find_location(
SCM, Moment, Moment, Rational,
Moment*, Moment*, Moment*)':
beaming-pattern.cc:220:39:
warning: conversion to 'int' from 'I64 {aka
It is almost certainly a problem with your system clock. If you have
touched source files with a future clock, and now the clock is right,
then compiled files will be outdated (older than the source file)
immediately after compilation again.
There is a special built-in target in GNU make:
I suggest that we adopt this as an official policy: fixes for
easy-to-overlook things should be documented by regtests using
big/enormous font-size (e.g. between 30 and 100, depending on
issue). So, everyone checking regtests should pay extra attention
to details when he sees a big-font
Hmm, that brings to mind a different possible solution:
@macro lilyfile{\FILENAME\}
@/@file{\FILENAME\}
@end macro
if there's no way to automate our desired behaviour (assuming we
can agree on a desired formatting in the output!), this might be
an alternate solution?
It is very
this-is-a-very
-long-name.ly
No, I don't like that idea. Filenames shouldn't be hyphenated.
I disagree. By starting a line with the hyphen it is clear that it is
part of the file name and not due to hyphenation (and we use a
typewriter font also). It is *much* less ugly than overlong
It is very unfortunate that we can't upgrade to the current
texinfo.tex file; it contains a lot of improvements, including a
very flexible URL command.
Why can't we? If it is ok for us to distribute a modified version
of texinfo.tex, I am pretty sure that I can concoct a fix for
whatever
Changes in MIDI instruments sometimes take effect only after a note,
not at the note to which the change is already expected to apply.
From the user's point of view, this problem occurs in an
unpredictable way since even seemingly irrelevant changes to the
input file can make the problem
Try the dev/texinfo branch. It is not really suitable for Rietveld
since it is two commits: one the current Texinfo version, and the
second a much smaller commit just changing the problematic lines.
Two days ago I've built the documentation, and everything seems fine.
Thanks a lot!
One
An even better solution would be for Texinfo to support these
characters.
- Just saying - I wouldn't expect any Lily developers to be working
on that!
Well, some years ago I've added UTF-8 infrastructure support to
texinfo (based on the LaTeX code); additionally, I've written the CJK
This is kind of the nub of the issue. I agree that the notation for
staff pitches (and octaves) is going to remain stable -- but I'm
_not_ convinced that you can guarantee stability for accidentals or
durations.
At least for German, the current syntax is the only good one IMHO,
both for
It did not accept your key. Sure you uploaded the _public_ key to
Savannah and it got accepted?
Be careful of newlines accidentally inserted in the public key while
entering it in the web interface!
Werner
___
lilypond-devel mailing list
At least for German, the current syntax is the only good one IMHO,
both for accidentals (for the twelve tones of an octave
You mean the 35 tones. After all, we are talking printed output and
not Midi.
Yes: cis, ces, fisis, feses, etc.
Werner
Be careful of newlines accidentally inserted in the public key
while entering it in the web interface!
Opening the key file with Firefox is pretty reliable, IME, as FF
doesn't break lines.
Good to know. My reason for writing was that I've experienced exactly
this problem, and others too
Yes: cis, ces, fisis, feses, etc.
And asas.
Yes, I think so.
Or aeses? Or was that ases?
Never heard.
bes or heses?
Rather the latter.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
FYI
Werner
---BeginMessage---
A new release, 20120731, is now available for download.
This time there is also a MS/Windows binary package available,
thanks to Matthew Petroff who provided it.
Regards,
Michał Nowakowski
Simply include the attached file somewhere at the beginning of a
document to have Cyrillic support (however, due to the used extension
mechanism, you don't get kerning or hyphenation, even if you set the
document language to Russian).
Note that TeXLive doesn't come with precomposed TFM files for
[lilypond commit 1dedaf12]
Mike,
is the problem `start and end points of slurs and ties don't fall
together' supposed to be fixed? This snippet
\version 2.17.0
\paper {
ragged-right = ##f
}
\relative c' {
\time 5/4 g'2.( ~ g8 a4. ~ |
a1) r4
}
still exhibits a
Odd...I'll look into it.
Thanks!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Personally, I am almost in favor of a rather hard cut where we switch
from Guilev1 to Guilev2.
+1
Most direct would be a hard cut: exchange the Guile version, and get
everybody working furiously until LilyPond works again.
Yes :-)
Given that these patches will be quite extensive, is now
Simply include the attached file somewhere at the beginning of a
document to have Cyrillic support (however, due to the used
extension mechanism, you don't get kerning or hyphenation, even if
you set the document language to Russian).
I've committed a slightly improved version to the git
I don't see this hack as the canonical way to go forward,
Interesting. I'm all ears to any more sensible solution which extends
the texinfo.tex framework without completely rewriting the font
selection mechanism.
and it is certainly not of the obviously trivial and correct
quality
I don't have more than the power of appeal to ask people from
refraining sabotaging the development branch until the settling
phase of 2.16 is mostly over, and that will be the case when 2.16.0
and 2.17.0 have been released: everything that actually should be
in 2.16.0 but did not warrant
In macros.itexi which is used throughout the entire documentation, for
every single Texinfo document, whether generating PDF, info, HTML. Have
you checked the performance impact?
Performance impact? For building the documentation? Are you kidding?
Building the snippets with LilyPond takes
But as soon as somebody complained (regardless of who it was,
regardless of the reason), I would revert the commit, and send the
patch for review+countdown.
Just done.
In the future, we'll all remember that changes to texinfo.tex can be
problematic, so we'll be slightly less likely to take
Pushing to staging means I consider this change to be safe and
can't imagine anybody suggesting anything to change.
Actually, this is what I still believe. However, we probably agree to
disagree, and going the Rietveld route is certainly the safe way.
For changes with potentially large
1 - 100 of 3174 matches
Mail list logo
