Re: BreathingSigns and automatic beams
I fully understand what you say, and similar symbols are used for singers, too, however, I think this somehow contradicts what lilypond is intended to do: engraving well-formatted music. It's not lilypond's job to imitate hand-written marks! In other words, I want to see some *printed* editions with such entries so that we can adjust lilypond accordingly, if necessary. * http://imslp.org/wiki/200_%C3%89tudes_nouvelles_m%C3%A9lodiques_et_progressives_pour_cor_(Alphonse,_Maxime) [...] Thanks for the samples. Basically all of them (except in the Franz Strauss Notturno) look as if the breathing marks were added to the already engraved plates... Honestly, I think that this is ugly and not good engraving. However, it clearly shows that this symbol can be positioned exactly on the bar if necessary :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Updated Roadmap text file (issue 106160043 by pkx1...@gmail.com)
With Mark P's comments - many thanks. It looks much better now. https://codereview.appspot.com/106160043/diff/1/ROADMAP File ROADMAP (right): https://codereview.appspot.com/106160043/diff/1/ROADMAP#newcode21 ROADMAP:21: | | Note: The Snippets and Internals manual are auto-generated On 2014/06/27 03:15:54, Mark Polesky wrote: I might say: Note: Snippets and Internals Reference are auto-generated or at least change manual to manuals. Also, maybe indent 2 spaces, similar to the note under TRANSLATED MANUALS. Done. https://codereview.appspot.com/106160043/diff/1/ROADMAP#newcode30 ROADMAP:30: | |-- usage/ How to execute all the programs distributed with LilyPond On 2014/06/27 03:15:54, Mark Polesky wrote: If you change programs distributed with to programs that come with (or just remove the all), then the file won't exceed 80 columns, if we still care about that... Done. https://codereview.appspot.com/106160043/diff/1/ROADMAP#newcode63 ROADMAP:63: | |-- snippets/Auto-generated .ly snippets (from the LSR and ../new/.) On 2014/06/27 03:15:54, Mark Polesky wrote: Technically it should be ./new/ instead of ../new/. I'd also omit the final period (before the parenthesis) since we don't use it elsewhere in the file. Done. https://codereview.appspot.com/106160043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: astyle 2.02
Hi Graham al., 2014-06-24 7:26 GMT+02:00 Graham Percival gra...@percival-music.ca: On Mon, Jun 23, 2014 at 09:28:24PM -0400, Devon Schudy wrote: The cases where 2.04 does worse than 2.02 are minor; I don't think they're enough that fixcc.py should refuse to use it. Thanks for the analysis of astyle 2.02 vs. 2.04. I support switching to 2.04. However, fixcc.py should reject any version other than the specific version we want. Otherwise, you could run it on your computer (and push it), then I could run it on my computer (and push it), then you could do the same thing, and basically we'd end up with an infinite sequence of formatting changes. I've submitted bug reports about these two problems: https://sourceforge.net/p/astyle/bugs/290/ https://sourceforge.net/p/astyle/bugs/291/ Do we want to wait until they are resolved before proceeding with the switch? Janek PS +1 for Graham! :) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: astyle 2.02
Graham Percival wrote: However, fixcc.py should reject any version other than the specific version we want. Otherwise, you could run it on your computer (and push it), then I could run it on my computer (and push it), then you could do the same thing, and basically we'd end up with an infinite sequence of formatting changes. Will fixcc.py's changes be committed often enough for this to matter? Lilypond seldom gets badly formatted code, so there's very little reason to reformat. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Question about the new fret-label-horizontal-offset option
Hello,
I just want to check the following for the
'fret-label-horizontal-offset' option we have added.
--snip--
\version 2.19.8
\new Voice {
c''1^\markup {
\override #'(fret-diagram-details . (
(fret-label-horizontal-offset . 0))) {
\fret-diagram-verbose #'((mute 6)
(place-fret 5 3 1)
(place-fret 4 5 2)
(place-fret 3 5 3)
(place-fret 2 5 4)
(place-fret 1 3 1)
(barre 5 1 3))
}
}
}
--snip--
Here is what happens when I use '0' (zero)
Here is what happens when I use 5
Here is what happens when I use -5
While these may not be the most reasonable examples, can I just check
that this is expected in that the fret label doesn't just offset but
changes (it seems) the whole dimension of the placement when using any
positive integer and if you use a negative integer that goes beyond the
width of the 'diagram' it pushes the diagram in the other way.
Here is what happens when I use -15
Thanks
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x up to June 2014 (issue 108130043 by pkx1...@gmail.com)
Thanks
https://codereview.appspot.com/108130043/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/108130043/diff/1/Documentation/changes.tely#newcode68
Documentation/changes.tely:68: Improved the automatic @q{x-extent}
placement of Accidentals.
On 2014/06/22 15:36:45, dak wrote:
It's X-extent, and we don't list bug fixes.
Removed.
https://codereview.appspot.com/108130043/diff/1/Documentation/changes.tely#newcode74
Documentation/changes.tely:74: @code{\compundMeter} no longer changes
the @code{TimeSignature.stencil}
On 2014/06/22 15:36:45, dak wrote:
compoundMeter, and it's actually another bug fix
Removed
https://codereview.appspot.com/108130043/diff/1/Documentation/changes.tely#newcode78
Documentation/changes.tely:78: Improved the legibility of many types of
error messages that can be
On 2014/06/22 15:36:44, dak wrote:
That's an actual feature but I don't think it makes sense to describe
it in
Changes as it is an incremental benefit but not something that will
make people
create scores they could not before.
Removed.
https://codereview.appspot.com/108130043/diff/1/Documentation/changes.tely#newcode83
Documentation/changes.tely:83: without it creating an extra staff.
On 2014/06/22 15:36:45, dak wrote:
Another bug fix. Totally longstanding, yes. But hard to qualify in
terms of
usability.
I actually would be hard put to create a sensible Changes entry if we
were to
fix issuenbsp;34 in spite of it being a real nuisance.
Removed.
https://codereview.appspot.com/108130043/diff/1/Documentation/changes.tely#newcode86
Documentation/changes.tely:86: It is now possible to color and/or
parenthesize single dots in fret
On 2014/06/22 15:36:45, dak wrote:
Now *that's* a worthwhile entry. Would it be possible to create a
visual
example by consulting the regtest?
Done.
https://codereview.appspot.com/108130043/diff/1/Documentation/changes.tely#newcode90
Documentation/changes.tely:90: Two new properties have been added for
use in fret-diagram-details;
On 2014/06/22 15:36:45, dak wrote:
Another case worth an example.
Not done yet. Am waiting on some extra information (fret diagrams are
not something I am familiar with in terms of music notation). I can add
one in another patch if I don't get one in time.
https://codereview.appspot.com/108130043/diff/1/Documentation/changes.tely#newcode96
Documentation/changes.tely:96: A new command @code{\justify-line} has
been added. Similar to the
On 2014/06/22 15:36:45, dak wrote:
Not sure whether it makes sense to add an example here. Could be if
one can
think of a nice snappy one.
Hopefully what I have done illustrates this concisely - David N gave me
some pointers. I used \typewriter as this is a mono spaced font which
helps make the point.
https://codereview.appspot.com/108130043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Question about the new fret-label-horizontal-offset option
2014-06-28 18:05 GMT+02:00 James pkx1...@gmail.com:
Hello,
I just want to check the following for the
'fret-label-horizontal-offset' option we have added.
--snip--
\version 2.19.8
\new Voice {
c''1^\markup {
\override #'(fret-diagram-details . (
(fret-label-horizontal-offset . 0))) {
\fret-diagram-verbose #'((mute 6)
(place-fret 5 3 1)
(place-fret 4 5 2)
(place-fret 3 5 3)
(place-fret 2 5 4)
(place-fret 1 3 1)
(barre 5 1 3))
}
}
}
--snip--
Here is what happens when I use '0' (zero)
Here is what happens when I use 5
Here is what happens when I use -5
While these may not be the most reasonable examples, can I just check
that this is expected in that the fret label doesn't just offset but
changes (it seems) the whole dimension of the placement when using any
positive integer and if you use a negative integer that goes beyond the
width of the 'diagram' it pushes the diagram in the other way.
Here is what happens when I use -15
Thanks
James
Hi James,
thanks for testing!
It's expected behaviour, at least consistent with the behaviour of the
(unchanged) `fret-label-vertical-offset'-property.
See the output from the code below, test it with different values for
'fret-label-vertical-offset':
\version 2.19.9
\new Voice {
c''1^\markup {
\override #'(fret-diagram-details . (
(fret-label-horizontal-offset . 0))) {
\fret-diagram-verbose #'((mute 6)
(place-fret 5 3 1)
(place-fret 4 5 2)
(place-fret 3 5 3)
(place-fret 2 5 4)
(place-fret 1 3 1)
(barre 5 1 3))
}
}
\break
%% taken from reg-test ‘fret-diagrams-landscape.ly’
%% override for ‘fret-label-vertical-offset’ added
\override TextScript.fret-diagram-details.orientation = #'landscape
c'' ^\markup {
\override #'(fret-diagram-details . (
(fret-label-vertical-offset . 15))) {
\fret-diagram-verbose #'((mute 6)
(capo 3)
(place-fret 4 5 1)
(place-fret 3 5 2)
(place-fret 2 5 3))
}
}
}
It might be worth fixing it, so that overrides for
fret-label-horizontal/vertical-offset doesn't move the main
fret-diagram.
I've no good idea at the moment, though.
Will think about it
Thanks,
Harm
P.S.
I assume you intended to include some images, though your mail doesn't
contain any, nor does
http://lilypond.1069038.n5.nabble.com/Question-about-the-new-fret-label-horizontal-offset-option-td163746.html
and
http://lists.gnu.org/archive/html/lilypond-devel/2014-06/msg00147.html
Though, I'm not friend with inline images at all. :)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Question about the new fret-label-horizontal-offset option
On 28/06/14 19:19, Thomas Morley wrote:
2014-06-28 18:05 GMT+02:00 James pkx1...@gmail.com:
Hello,
I just want to check the following for the
'fret-label-horizontal-offset' option we have added.
--snip--
\version 2.19.8
\new Voice {
c''1^\markup {
\override #'(fret-diagram-details . (
(fret-label-horizontal-offset . 0))) {
\fret-diagram-verbose #'((mute 6)
(place-fret 5 3 1)
(place-fret 4 5 2)
(place-fret 3 5 3)
(place-fret 2 5 4)
(place-fret 1 3 1)
(barre 5 1 3))
}
}
}
--snip--
Here is what happens when I use '0' (zero)
Here is what happens when I use 5
Here is what happens when I use -5
While these may not be the most reasonable examples, can I just check
that this is expected in that the fret label doesn't just offset but
changes (it seems) the whole dimension of the placement when using any
positive integer and if you use a negative integer that goes beyond the
width of the 'diagram' it pushes the diagram in the other way.
Here is what happens when I use -15
Thanks
James
Hi James,
thanks for testing!
It's expected behaviour, at least consistent with the behaviour of the
(unchanged) `fret-label-vertical-offset'-property.
See the output from the code below, test it with different values for
'fret-label-vertical-offset':
\version 2.19.9
\new Voice {
c''1^\markup {
\override #'(fret-diagram-details . (
(fret-label-horizontal-offset . 0))) {
\fret-diagram-verbose #'((mute 6)
(place-fret 5 3 1)
(place-fret 4 5 2)
(place-fret 3 5 3)
(place-fret 2 5 4)
(place-fret 1 3 1)
(barre 5 1 3))
}
}
\break
%% taken from reg-test ‘fret-diagrams-landscape.ly’
%% override for ‘fret-label-vertical-offset’ added
\override TextScript.fret-diagram-details.orientation = #'landscape
c'' ^\markup {
\override #'(fret-diagram-details . (
(fret-label-vertical-offset . 15))) {
\fret-diagram-verbose #'((mute 6)
(capo 3)
(place-fret 4 5 1)
(place-fret 3 5 2)
(place-fret 2 5 3))
}
}
}
It might be worth fixing it, so that overrides for
fret-label-horizontal/vertical-offset doesn't move the main
fret-diagram.
I've no good idea at the moment, though.
Will think about it
Thanks,
Harm
P.S.
I assume you intended to include some images, though your mail doesn't
contain any, nor does
http://lilypond.1069038.n5.nabble.com/Question-about-the-new-fret-label-horizontal-offset-option-td163746.html
and
http://lists.gnu.org/archive/html/lilypond-devel/2014-06/msg00147.html
Though, I'm not friend with inline images at all. :)
Sorry, here they are attached and labeled accordingly.
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x up to June 2014 (issue 108130043 by pkx1...@gmail.com)
Now added an example for the horizontal and parenthesis padding for fretted diagrams https://codereview.appspot.com/108130043/diff/1/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/108130043/diff/1/Documentation/changes.tely#newcode90 Documentation/changes.tely:90: Two new properties have been added for use in fret-diagram-details; On 2014/06/28 16:26:16, J_lowe wrote: On 2014/06/22 15:36:45, dak wrote: Another case worth an example. Not done yet. Am waiting on some extra information (fret diagrams are not something I am familiar with in terms of music notation). I can add one in another patch if I don't get one in time. Now added an example for this new feature https://codereview.appspot.com/108130043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building documentation: bad PNG output
CCing dev list in case anyone who understand the build system knows what is going on here On 28/06/14 16:59, Aymeric O. wrote: I found where the problem is! In make/lilypond-vars.make, the options used by LilyPond to generate the output files are given there: ## override from cmd line to speed up. ANTI_ALIAS_FACTOR=2 LILYPOND_JOBS=$(if $(CPU_COUNT),-djob-count=$(CPU_COUNT),) LANG_TEXIDOC_FLAGS:=$(foreach lang,$(LANGS),--header=texidoc$(lang)) LANG_DOCTITLE_FLAGS:=$(foreach lang,$(LANGS),--header=doctitle$(lang)) LILYPOND_BOOK_LILYPOND_FLAGS=-dbackend=eps \ --formats=ps,png,pdf \ $(LILYPOND_JOBS) \ -dinclude-eps-fonts \ -dgs-load-fonts \ --header=doctitle \ $(LANG_DOCTITLE_FLAGS) \ --header=texidoc \ $(LANG_TEXIDOC_FLAGS) \ -dcheck-internal-types \ -ddump-signatures \ -danti-alias-factor=$(ANTI_ALIAS_FACTOR) And the problem comes from -danti-alias-factor=$(ANTI_ALIAS_FACTOR) (=2), which is responsible for the crushed PNG files. I tested it on my own scores, and it gives the same result. So it looks like the /usr/bin/lilypond I built can't handle -danti-alias-factor=2, but why? I tried this option whith the precompiled version of LilyPond, and I get the same PNG files, so it must be a system-wide problem, as it was suggested before. I'm using Zenwalk GNU/Linux, a Slackware-based system. On 06/27/2014 02:47 PM, James wrote: Aymeric, On 27/06/14 13:06, Federico Bruni wrote: Helping you is a hard job and I've just run out of time. You are not telling us which source you are using. From a linux distro repository? From lilypond git repository? You should use git and checkout the 2.18.2 branch, otherwise you won't get much help from this list probably. And the logs of 'make doc'? I give up... Good luck! :) Yes diagnosing doc build problems can be very time consuming. Please make sure that 1. You are following the contributor guide which gives the minimum requirements to build documentation successfully: http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#requirements and http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#requirements-for-building-documentation 2. Next, build the latest 2.19 documents from git http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#summary-for-experienced-developers At least prove that that works or does not work. I know it does at the moment as I build the documentation daily, so if you are having problems with 2.19 then it could simply be an evironmental issue than a code issue. If you can build it fine and get your PNG files using 2.19 then use the same git repo and use the 2.18 branch and then try. Then at least we can attempt to help, knowing we are all looking at the same code as you. Regards James 2014-06-27 13:27 GMT+02:00 Aymeric ejisn...@gmail.com mailto:ejisn...@gmail.com: I'm trying to build 2.18.2, with... LilyPond 2.18.2, so there should be no problem, and, as I said, I can generate PNG files from my own scores. I even tried with the file you mentioned: aymeric[snippets]$ lilypond -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts --png pitches-headword.ly http://pitches-headword.ly GNU LilyPond 2.18.2 Processing `pitches-headword.ly http://pitches-headword.ly' Parsing... Interpreting music...[8] Preprocessing graphical objects... Finding the ideal number of pages... Fitting music on 1 page... Drawing systems... Layout output to `pitches-headword.eps'... Converting to PNG... Layout output to `pitches-headword-1.eps'... Writing pitches-headword-systems.texi... Writing pitches-headword-systems.tex... Writing pitches-headword-systems.count... Success: compilation successfully completed And here's the output. On 06/27/2014 01:18 PM, Federico Bruni wrote: BTW, what's the purpose of building the current stable doc (2.18.2)? Which source are you using? 2014-06-27 13:16 GMT+02:00 Federico Bruni fedel...@gmail.com mailto:fedel...@gmail.com mailto:fedel...@gmail.com mailto:fedel...@gmail.com: Ok, finally I see what's the problem. I never had such a problem and I cannot make a guess. You got no error when running make doc? You should check the log files in Documentation: ./Documentation/notation.texi2pdf.log ./Documentation/notation.bigtexi.log ./Documentation/notation.splittexi.log ./Documentation/notation.makeinfo.log That file is ./Documentation/snippets/pitches-headword.ly http://pitches-headword.ly http://pitches-headword.ly It seems that the lilypond version you are using cannot compile it. Perhaps a version mismatch? 2014-06-27 13:10 GMT+02:00 Aymeric
Re: astyle 2.02
2014-06-28 16:53 GMT+02:00 Devon Schudy dsch...@gmail.com: Graham Percival wrote: However, fixcc.py should reject any version other than the specific version we want. Otherwise, you could run it on your computer (and push it), then I could run it on my computer (and push it), then you could do the same thing, and basically we'd end up with an infinite sequence of formatting changes. Will fixcc.py's changes be committed often enough for this to matter? Lilypond seldom gets badly formatted code, so there's very little reason to reformat. If badly formatted = different than what fixcc.py would produce, i would say that LilyPond often gets badly formatted code - as you wrote, running fixcc now results in 400 lines of changes. I think we should enourage developers to use fixcc more often, and then Graham's concern is very valid. I can say that having to move past 5 code reformattings when doing git blame is pretty annoying, so anything that introduces changes that are not necessary is really unwelcome. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cleanup alignments of various grobs (issue 105410046 by janek.lilyp...@gmail.com)
On 2014/06/27 04:34:36, lemzwerg wrote: LGTM (without any testing). Thanks, Werner! I decided to move code refactoring to another issue, so that this one is only about changing how various grobs are aligned. It is now Issue 3978 (https://code.google.com/p/lilypond/issues/detail?id=3978), and the refactoring will be done in issue 3979. I apologize for confusion! Janek https://codereview.appspot.com/105410046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Pitches.itely - added 2 new snippets (issue 110240044 by pkx1...@gmail.com)
Is it worth making the Notation Reference longer? https://codereview.appspot.com/110240044/diff/40001/Documentation/notation/pitches.itely File Documentation/notation/pitches.itely (right): https://codereview.appspot.com/110240044/diff/40001/Documentation/notation/pitches.itely#newcode1325 Documentation/notation/pitches.itely:1325: \override Staff.KeySignature.flat-positions = #'((-5 . 5)) This already shows how to print key signatures over a different or wider range of the staff. You might consider this good enough. https://codereview.appspot.com/110240044/diff/40001/Documentation/snippets/new/creating-custom-key-signatures.ly File Documentation/snippets/new/creating-custom-key-signatures.ly (right): https://codereview.appspot.com/110240044/diff/40001/Documentation/snippets/new/creating-custom-key-signatures.ly#newcode26 Documentation/snippets/new/creating-custom-key-signatures.ly:26: \musicglyph #clefs.F But F is not 3 staff-spaces below C, only 2. You could \translate #'(-3 . -2) \musicglyph #clefs.F to avoid the overlap. Or you could use a G clef \translate #'(0. +2) \musicglyph #clefs.G https://codereview.appspot.com/110240044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: astyle 2.02
On Sun, Jun 29, 2014 at 12:08:56AM +0200, Janek Warchoł wrote: If badly formatted = different than what fixcc.py would produce, i would say that LilyPond often gets badly formatted code - as you wrote, running fixcc now results in 400 lines of changes. This could, of course, be completely automated. Once fixcc.py has been run on the whole source code, each patch could be tested to see if running fixcc.py on it produces any changes. If so, then the patch would be automatically rejected and the submitter would be asked to run fixcc.py before re-submitting the patch. A less strict method of this would be to simply produce an automated warning. Or this could be deferred to the merge staging side of things -- if fixcc.py produces any changing on staging, then it is not merged with master. The question to ask is where do you want the burden of producing properly formatted code? - a volunteer who runs fixcc.py manually once a year? (this also produces code reformatting commits which disrupt git blame) - an automated process which demands that the initial submitter format the patch? - an automated process which demands that the pusher format the patch? (note that with new or casual committers, the pusher is not the same as the committer) I favour the first or third option; people heavily involved in lilypond can set up a git hook and always have properly formatted code (whether they write the patch themselves or simply push somebody else's patch). Asking casual committers to have a specific version of astyle seems like a high burden. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: astyle 2.02
Janek Warchoł janek.lilyp...@gmail.com writes: I think we should enourage developers to use fixcc more often, and then Graham's concern is very valid. I can say that having to move past 5 code reformattings when doing git blame is pretty annoying, git blame -w -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building documentation: bad PNG output
James pkx1...@gmail.com writes: CCing dev list in case anyone who understand the build system knows what is going on here Not really a build system problem. On 28/06/14 16:59, Aymeric O. wrote: And the problem comes from -danti-alias-factor=$(ANTI_ALIAS_FACTOR) (=2), which is responsible for the crushed PNG files. I tested it on my own scores, and it gives the same result. So it looks like the /usr/bin/lilypond I built can't handle -danti-alias-factor=2, but why? Probably Imagemagick is not installed or not found in PATH. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
