Re: Fix critical regressions to lyric spacing (issue4061043)
Carl, having struggled myself trying to smooth the transition to the new spacing with a snippet(s), I appreciate the simplicity of this solution. It looks good to me. Having text in CHANGES seems important. A little sugar would help the medicine go down; if spin is not your style, one of the others of us could sweeten in a follow-up-patch. http://codereview.appspot.com/4061043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with git-cl
Original Message > Somebody this weekend posted, either in an email or in an issue comment, > that they were finally able to upload patches to Rietveld. That was me, in an issue comment explaining why my first patch set was bad. I intended to follow-up to say that Python finds file types from /etc/mime.types (as opposed to the mime-types-xml-database that modern fancy linux desktops might use) You want to have a line in there indicating that scm indicates mime category text : text/x-script.scheme scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: flags, beams and stem length in forced directions - output improvement
2011/1/24 Werner LEMBERG : >>> In one of my previous mails I gave you a recipe how to produce a >>> `proof' version of the font using `mf' and `gftodvi'. It doesn't >>> help to get the exact outline since it is always based on the >>> rasterized output of `mf', but it nicely shows the construction >>> points (if possible). >> >> I've tried making a "proof" version of the font, but my insufficient >> knowledge resulted in a failure :( > > Could you elaborate, please? Essentially, you just have to call mf, > followed by gf2dvi. It worked now. Perhaps i called it in the wrong directory... Silly me. By the way, how to call mf with changed output directory? I tried mf '\mode:=proof; input feta-noteheads20'-output-directory=../build and mf '\mode:=proof; -output-directory="../build" input feta-noteheads20' but both failed... >>> FONTFORGE=foo mf2pt1 --rounding=0.0001 , >>> >>> do you see the irregularity if you open the font with fontforge? >> >> Yes, i attach a screenshot. The font file is here: >> http://www.mediafire.com/?hadr9nt5w5iqulb > > Looking at the image, I see that you haven't followed my advice since > all overlapping outlines have been removed already. Using the > `FONTFORGE=foo' environment setting while calling mf2pt1 prevents this > so that you get the direct output of mf2pt1 without postprocessing > with fontforge. Ah, i think i understand. The screenshot i provided was useless because it said us what we already knew, that there is a spike in the final font. Looking at the proof dvi, i can say that there are no spikes there. I understand that it's fontforge's fault then, am i right? > And yes, it should really be `foo', a non-existent > program name. running FONTFORGE=foo mf2pt1 --rounding=0.0001 in /mf or /build/mf results in this error: bash: syntax error near unexpected token `newline' I'm probably doing something stupid here... > To set up mf2pt1 so that you can call it manually in an easy way, > please execute > > mpost -progname=mpost -ini mf2pt1.mp \\dump that worked. Now i have mf2pt1.log in /mf directory. By the way, is there an easy way of avoiding cluttering my main source directory and doing all this in /build for example? > in the `mf' subdirectory (lilypond does this in the `mf/out' directory > during `make all'). > >>> You might try the recent CVS version of fontforge which has a lot >>> of fixed issues. Don't forget to pass `--enable-double' to the >>> `configure' script of fontforge. >> >> Umm.. i'm afraid i don't understand :( > > 1. Check out the CVS sources of fontforge: > > cvs -d:pserver:anonym...@fontforge.cvs.sourceforge.net:/cvsroot/fontforge > login Do i need to have an account of some kind and how can i create it? It asks me for CVS password. >From what i see i cannot proceed any further. Thanks for help! Janek > cvs -z3 > -d:pserver:anonym...@fontforge.cvs.sourceforge.net:/cvsroot/fontforge co -P > fontforge > > 2. Change to the freshly created `fontforge' directory and configure > the program with > > ./configure --enable-double > > then build the program with > > make > > If the configure script complains it is necessary to install > additional packages to fulfill all dependencies (probably missing > `*-devel' packages so that the necessary C header files are > provided for compiling). After installing a new package, simply > rerun `./configure --enable-double' until it succeeds. > > 3. Finally, install it with > > sudo make install > > Assuming that you are originally using a fontforge package from your > GNU/Linux distribution, your original binary is in /usr/bin/fontforge. > Now you have a new, additional binary in `/usr/local/bin/fontforge'. > You might add `--prefix=/your/preferred/directory/tree' to the > configure script if you want a different location than `/usr/local'. > > > Werner > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: flags,beams and stem length in forced directions - output improvement
> By the way, how to call mf with changed output directory? I tried > mf '\mode:=proof; input feta-noteheads20'-output-directory=../build > and > mf '\mode:=proof; -output-directory="../build" input feta-noteheads20' > but both failed... It fails for me too... I've just reported this to the TeXLive people. I suggest that you copy the whole `mf' directory to another place. > Looking at the proof dvi, i can say that there are no spikes there. > I understand that it's fontforge's fault then, am i right? I think so. > FONTFORGE=foo mf2pt1 --rounding=0.0001 > in /mf or /build/mf results in this error: > bash: syntax error near unexpected token `newline' > I'm probably doing something stupid here... It's my fault, sorry. I've used `<' and `>' as meta-markers which shouldn't be used for invocation. Try this: FONTFORGE=foo mf2pt1 --rounding=0.0001 feta-noteheads20.mf > By the way, is there an easy way of avoiding cluttering my main source > directory and doing all this in /build for example? You might write a script to do that, something like cd build mf '\mode:=proof; input ../feta-noteheads20' cd .. >> cvs >> -d:pserver:anonym...@fontforge.cvs.sourceforge.net:/cvsroot/fontforge login > > Do i need to have an account of some kind and how can i create it? > It asks me for CVS password. From what i see i cannot proceed any > further. No password required. Simply press enter. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
MIDI remapping
Apologies for repeating my original message. I just subscribed and thought that the first one didn't go through! -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
hi Carl, thanks for reviewing!
> Let me start by saying I know *nothing* about mensural notation.
>
> The code looks good to me.
>
> I found only one real issue:
>
> LilyPond coding standards for C++ say that if there is only one
> statement in an if clause, we omit {} around that clause.
that's a pity - I hate adding/removing braces when the number of
statement changes. nevertheless I'll change these instances.
> I also had a question (and it probably doesn't matter much). When I've
> written font glyphs that are sometimes solid and sometimes hollow, I
> always calculate both the inner and outer paths. And then when I create
> the glyph I only use the paths that are actually needed. In your code,
> you didn't create the path unless it was needed. It probably makes no
> difference at all, but I'd like to hear from the font gurus if there is
> a preference.
>
> My take was we only make the fonts at install, so the code doesn't need
> to be optimized for speed, so I optimized for readability, which in my
> mind, meant not putting the inner path inside a conditional.
in this case the shape of the inner path is conditional as well
(and it's truly nasty, I admit).
I'll upload a modified patchset tonight.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Pentatonic Diatonic Transposition?
Thanks Carl. I'll check with Mike to see how he'd like to proceed with this. Trevor - Original Message - From: "Carl Sorensen" To: "Trevor Daniels" ; "LilyPond-Devel list" Sent: Monday, January 24, 2011 2:08 AM Subject: Re: Pentatonic Diatonic Transposition? On 1/23/11 4:03 AM, "Trevor Daniels" wrote: The code below seems to satisfy a request seen several times on -user. Assuming the code is good I'd prefer to see this added to the LP distribution rather than the LSR. What do you think? Looks reasonable to me. The code needs to be put in a .scm file (scm/modal-transpose.scm), and the music function needs to go to ly/music-functions-init.ly. The publically-accessible functions need to be define-public. The indentation isn't right. I think the errors should be turned into warnings. If the transposer pitches aren't valid, the transposer should just return the argument to be transposed without transposition. We shouldn't abort when we have the chance to continue gracefully but with a warning. make-extended-scale has a display-scheme-music call that I think should be eliminated. We need a shortened version of the demo for a regression test. And we need a doc-section written. But the code generally looks good to me. I think we should get it added. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Quanting and issue 37
Hey all, I am trying to understand beam-quanting.cc better, and I think I know how I'm gonna tackle this. I'm going to put my collision callback before beam quanting, and then try something to the effect of: if (the beam was pushed up during the collision callback) impose an insanely prohibitive demerit for the beam position going down in the quanting else if (the beam was pushed down during the collision callback) impose an insanely prohibitive demerit for the beam position going up in the quanting Could anyone give me a quick primer on how to do that? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixing issue 37 with extra position callback (issue3928041)
On Mon, Jan 24, 2011 at 9:42 AM, Mike Solomon wrote: > Fixed, although I have no idea what the "desired output" is in this case (I > have a feeling it's "Hey...you asked for it..."). IMO, in the last case, the stems should be shortened so there is no collision; why is there a collision now? -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: flags,beams and stem length in forced directions - output improvement
> mf2pt1: command not found Ah, sorry, the script is in /scripts/build, so you should say perl /path/to/lilypond/src/directory/scripts/build/mf2pt1.pl ... > Or would it provide some important information? Yes, what mf2pt1 produces shows the exact outlines of the font. This is always good to have for checking IMHO. > And you know what? The spikes are gone! :D Good! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixing issue 37 with extra position callback (issue3928041)
I had just reverted it to the old behavior (I think...). The question is: when we have a collision like the third example, how much do we shorten the stems before it becomes ridiculous? We could shorten the stems to avoid the collision there, but if the note were a perfect 5th lower, it'd lead to a very squashed result. I'm just not sure how low is too low before you have to give up and print a collision. Cheers, MS On Jan 24, 2011, at 7:46 AM, Han-Wen Nienhuys wrote: > On Mon, Jan 24, 2011 at 9:42 AM, Mike Solomon wrote: >> Fixed, although I have no idea what the "desired output" is in this case (I >> have a feeling it's "Hey...you asked for it..."). > > IMO, in the last case, the stems should be shortened so there is no > collision; why is there a collision now? > > -- > Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixing issue 37 with extra position callback (issue3928041)
On Mon, Jan 24, 2011 at 10:49 AM, Mike Solomon wrote: > I had just reverted it to the old behavior (I think...). > > The question is: when we have a collision like the third example, how much do > we shorten the stems before it becomes ridiculous? We could shorten the > stems to avoid the collision there, but if the note were a perfect 5th lower, > it'd lead to a very squashed result. If the note were a 5th lower, there would not be a collision to start with. > I'm just not sure how low is too low before you have to give up and print a > collision. That is the advantage of scoring: you can give points for how bad the shortened stem is vs. how bad the colllision is, and let the scoring figure it out. The larger context of my objections to your patch is that we used to have (pre 1.6.0) beam formatting routines like yours: a sequence of routines that each tried to modify #'positions on its own to fix one thing (slopes, quantizations, concavity, etc.). The result was a mess as all these routines interacted in unpredictable ways, and although it would work for a large number of cases, there were always new errors that required more complicated conditional fixups. We never got it working 100%, so we threw everything out and moved to score based formatting. If you dig in the archive, you can see it happening around 1.5.42. In particular, you can see old code being thrown out in commit 46c5beb169abbc5a03bd57562cda1669640e4c72 Let me whip up a prototype for you to see how it works. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quanting and issue 37
On 1/24/11 6:04 AM, "Mike Solomon" wrote: > Answered my own question...new patch attached that does collision management > before quanting and then does correct quanting. > First one who throws it up on Rietveld wins! > Uploaded. I win! Carl P.S. Mike, did you see the email from Keith? You can probably solve your problem by looking in /etc/mime.types ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: flags, beams and stem length in forced directions - output improvement
2011/1/24 Werner LEMBERG : > >> mf2pt1: command not found > > Ah, sorry, the script is in /scripts/build, so you should > say > > perl /path/to/lilypond/src/directory/scripts/build/mf2pt1.pl ... Calling perl scripts/build/mf2pt1.pl from lilypond-git directory says Can't exec @PERL@ at scripts/build/mf2pt1.pl line 1. First line of that file reads #!@PERL@ Strange... Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
new Staff in a Voice?
when going thru the snippets i came upon this confusing aggregation of voices
and staves ( http://lsr.dsi.unimi.it/LSR/Snippet?id=141 LSR 141 )
\score {
\context Voice \relative c {
\context Staff <<
\new Voice {
i don't understand this construction and i think it should be simplified to
(also placing the \relative in the voice instead of overall):
\context Staff <<
\context Voice = "1" \relative c''' {
c2 c8 b a g
\override Stem #'no-stem-extend = ##t
c2 c8 b a g
}
\context Voice = "2" \relative c {
f2 f8 g a b
\override Stem #'no-stem-extend = ##t
f2 f8 g a b
}
>>
thanks!
Eluze
--
View this message in context:
http://old.nabble.com/new-Staff-in-a-Voice--tp30748054p30748054.html
Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041)
- Original Message - From: To: Cc: ; Sent: Monday, January 24, 2011 5:15 AM Subject: Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041) Extended to cover the other issues that were fixed along with 1120. The regression test that /could/ have caught the breakage of issue 1120 is revised so it will (more likely) catch any future breakage. FWIW had I been running my pixel comparator then, I'd have spotted this easily. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixing issue 37 with extra position callback (issue3928041)
On Mon, Jan 24, 2011 at 11:22 AM, Han-Wen Nienhuys wrote:
> Let me whip up a prototype for you to see how it works.
See attached (it applies on top of issue3928041_55001.diff)
It is imperfect in several ways,
- see TODOs in the code.
- 4th beat 1st line: should go below
- 5th beat 1st line: should be closer to collision
- 4th beat 2nd line: any position will better
it needs some tuning in how all the penalties work together (try the
#'debug-scoring property, together with #'inspect-quants),
but I hope you will agree the code is cleaner and handles more cases.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
commit aa271b4aaf5bb48bdeea41da6e44a883de1ed0de
Author: Han-Wen Nienhuys
Date: Mon Jan 24 12:15:48 2011 -0200
Proof of concept: use scoring for beam collisions.
diff --git a/input/regression/beam-collision.ly b/input/regression/beam-collision.ly
index b73ce8a..b91d060 100644
--- a/input/regression/beam-collision.ly
+++ b/input/regression/beam-collision.ly
@@ -1,19 +1,46 @@
\version "2.13.47"
\header {
- texidoc = "When set manually, beams do not collide in polyphonic textures.
-"
+ texidoc = "Manual beams do not collide with notes, accidentals, etc."
+ tagline = ""
}
-\relative c'' {
- \time 4/4
- << { s128 e[ s cis,] } \\ { b''[ s b] } >> r8..
- << { s8 d,,[ s d] } \\ { f'8[ s fis] } >>
- << { s16 c,16[ s c''] } \\ { b16[ s d,,] } >> |
- \time 3/4
- << { \times 4/5 { s32 e[ s g s g, s e'' s b'] } } \\
- { \times 4/5 { c,,32[ s c'' s g, s b s d s] } } >>
- \clef bass g,,,8[ \clef treble d''8]
- b8[ c |
- \time 2/4
- d e] r4 |
+\relative \new Staff {
+
+ <<
+\new Voice {
+\voiceOne
+\repeat unfold 8 { c8[ c] }
+ }
+
+\new Voice \relative c'' {
+ \voiceThree
+ \autoBeamOff
+ f f e e
+ d d c c
+ b b a a
+ g g f f
+ \break
+}
+ >>
+ <<
+ \new Voice {
+ \repeat unfold 8 \relative {
+ \voiceOne
+ c8[
+ \voiceTwo
+ c'']
+ }
+ }
+ \new Voice \relative {
+ \voiceFour
+ s8 f
+ s8 g
+ s8 a
+ s8 b
+ s8 c
+ s8 d
+ s8 e
+ }
+ >>
}
+
diff --git a/lily/beam-quanting.cc b/lily/beam-quanting.cc
index 2ecf070..f6338e7 100644
--- a/lily/beam-quanting.cc
+++ b/lily/beam-quanting.cc
@@ -58,6 +58,8 @@ Beam_quant_parameters::fill (Grob *him)
MUSICAL_DIRECTION_FACTOR = get_detail (details, ly_symbol2scm ("musical-direction-factor"), 400);
IDEAL_SLOPE_FACTOR = get_detail (details, ly_symbol2scm ("ideal-slope-factor"), 10);
ROUND_TO_ZERO_SLOPE = get_detail (details, ly_symbol2scm ("round-to-zero-slope"), 0.02);
+ COLLISION_PENALTY = get_detail (details, ly_symbol2scm ("collision-penalty"), 500);
+ COLLISION_DISTANCE = get_detail (details, ly_symbol2scm ("collision-distance"), 0.5);
}
static Real
@@ -150,6 +152,9 @@ Beam::quanting (SCM smob, SCM posns)
*/
vector stems
= extract_grob_array (me, "stems");
+
+ extract_grob_set (me, "covered-grobs", covered_grobs);
+
vector stem_infos;
vector base_lengths;
vector stem_xposns;
@@ -157,8 +162,11 @@ Beam::quanting (SCM smob, SCM posns)
Drul_array dirs_found (0, 0);
Grob *common[2];
for (int a = 2; a--;)
-common[a] = common_refpoint_of_array (stems, me, Axis (a));
-
+{
+ common[a] = common_refpoint_of_array (stems, me, Axis (a));
+ common[a] = common_refpoint_of_array (covered_grobs, me, Axis (a));
+}
+
Grob *fvs = first_normal_stem (me);
Grob *lvs = last_normal_stem (me);
Real xl = fvs ? fvs->relative_coordinate (common[X_AXIS], X_AXIS) : 0.0;
@@ -194,6 +202,18 @@ Beam::quanting (SCM smob, SCM posns)
stem_xposns.push_back (s->relative_coordinate (common[X_AXIS], X_AXIS));
}
+
+ /*
+Get dimensions of possible collisions.
+ */
+ vector covered;
+ for (vsize i = 0; i < covered_grobs.size(); i++)
+{
+ Grob* g = covered_grobs[i];
+ covered.push_back (Box(g->extent (common[X_AXIS], X_AXIS),
+ g->extent (common[Y_AXIS], Y_AXIS)));
+}
+
bool xstaff = Align_interface::has_interface (common[Y_AXIS]);
Direction ldir = Direction (stem_infos[0].dir_);
@@ -237,6 +257,20 @@ Beam::quanting (SCM smob, SCM posns)
parameters outside of the loop, we can save a lot of time. */
for (vsize i = qscores.size (); i--;)
{
+ Real d = score_collisions (qscores[i].yl, qscores[i].yr,
+ covered,
+ beam_thickness,
+ xl, xr,
+ ¶meters);
+ qscores[i].demerits += d;
+
+#if DEBUG_BEAM_SCORING
+ qscores[i].score_card_ += to_string (" C %.2f", d);
+#endif
+}
+
+ for (vsize i = qscores.size (); i--;)
+{
Real d = score_slopes_dy (qscores[i].yl, qscores[i].yr,
dy_mus, yr- yl,
xr - xl,
@@ -308,6 +342,7 @@ Beam::quanting (SCM smob, SCM posns)
}
#endif
+
Interval final_p
Re: flags,beams and stem length in forced directions - output improvement
> Calling > perl scripts/build/mf2pt1.pl > from lilypond-git directory says > Can't exec @PERL@ at scripts/build/mf2pt1.pl line 1. > First line of that file reads > #!@PERL@ > > Strange... Well, the perl script gets `massaged', and the @PERL@ construct gets replaced with a real path to the perl interpreter. I forgot that. In case you have a compiled lilypond, use scripts/build/out/mf2pt1 instead. Otherwise, copy the file and simply remove that line. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: flags,beams and stem length in forced directions - output improvement
>> By the way, how to call mf with changed output directory? I tried >> mf '\mode:=proof; input feta-noteheads20'-output-directory=../build >> and >> mf '\mode:=proof; -output-directory="../build" input feta-noteheads20' >> but both failed... > > It fails for me too... I've just reported this to the TeXLive > people. I've received an explanation: It's a feature. In the central configuration file of TeXLive, `texmf.cnf', you can find this: % Allow TeX \openin, \openout, or \input on filenames starting with `.' % (e.g., .rhosts) or outside the current tree (e.g., /etc/passwd)? % a (any): any file can be opened. % r (restricted) : disallow opening "dotfiles". % p (paranoid) : as `r' and disallow going to parent directories, and % restrict absolute paths to be under $TEXMFOUTPUT. openout_any = p openin_any = a This means that by default you can't access the parent directory while writing output files for security reasons. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add new merge-function.ly file for rests (issue4005046)
Patch v.3 is up. Still having compile issues even after Carl's suggestions - so I wonder if someone can take a look and see if I have edited in the correct place. PS. I am not seeing any emails go to dev when I update or upload so I am not sure if my gmail account is set up for dev properly. So I apologise if this has already been seen Thanks again for your help. http://codereview.appspot.com/4005046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add new merge-function.ly file for rests (issue4005046)
On 1/24/11 9:14 AM, "pkx1...@gmail.com" wrote: > Patch v.3 is up. Still having compile issues even after Carl's > suggestions - so I wonder if someone can take a look and see if I have > edited in the correct place. > > PS. I am not seeing any emails go to dev when I update or upload so I am > not sure if my gmail account is set up for dev properly. So I apologise > if this has already been seen Emails are not automatically sent when you update or upload. To get an email sent, just click on Publish and Mail Comments (from the Rietveld issue page) and announce a new patchset. But -- Neil's comment indicated that this approach wrong for getting this functionality into the LilyPond distribution. He suggests that a new engraver will be needed. Therefore, putting this up as an LSR snippet in the original form is probably the best thing to do right now, IMO. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix critical regressions to lyric spacing (issue4061043)
Almost there. http://codereview.appspot.com/4061043/diff/19001/Documentation/snippets/new/lyrics-old-spacing-settings.ly File Documentation/snippets/new/lyrics-old-spacing-settings.ly (right): http://codereview.appspot.com/4061043/diff/19001/Documentation/snippets/new/lyrics-old-spacing-settings.ly#newcode1 Documentation/snippets/new/lyrics-old-spacing-settings.ly:1: \version "2.13.47" Could you run makelsr and then don't forget to do git add Documentation/snippets/*.ly so that git master will compile after applying this patch? :) I'm missing lyrics-old-spacing-settings.ly in Documentation/snippets/ . http://codereview.appspot.com/4061043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 1376 ambitus two accidentals. (issue4099044)
On 2011/01/23 22:35:02, Neil Puttock wrote: Sorry Graham, my comment on the regtest should've been clearer: I wasn't proposing we add that information to the test (since it only applies to the new case fixed by this patch); it's just that the original text is ambiguous (the part about two noteheads, since we can only see one in the altered unison case). Ok, no problem. I pushed the modified regtest text, since it certainly doesn't hurt. Cheers, - Graham http://codereview.appspot.com/4099044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix critical regressions to lyric spacing (issue4061043)
On 1/24/11 9:33 AM, "percival.music...@gmail.com" wrote: > Almost there. > > > http://codereview.appspot.com/4061043/diff/19001/Documentation/snippets/new/ly > rics-old-spacing-settings.ly > File Documentation/snippets/new/lyrics-old-spacing-settings.ly (right): > > http://codereview.appspot.com/4061043/diff/19001/Documentation/snippets/new/ly > rics-old-spacing-settings.ly#newcode1 > Documentation/snippets/new/lyrics-old-spacing-settings.ly:1: \version > "2.13.47" > Could you run makelsr and then don't forget to do >git add Documentation/snippets/*.ly Ah. I did the makelsr, but forgot to do the git add. It compiles on my machine. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add new merge-function.ly file for rests (issue4005046)
On 2011/01/24 16:20:20, c_sorensen_byu.edu wrote: snip... But -- Neil's comment indicated that this approach wrong for getting this functionality into the LilyPond distribution. He suggests that a new engraver will be needed. Therefore, putting this up as an LSR snippet in the original form is probably the best thing to do right now, IMO. Thanks, Carl No problem. What would be the best thing to do with this 'code' would putting the 'patch' I have on the tracker issue, with explanation and appropriate comments from this Rietveld thread, be the right thing if only to save re-doing more work for anyone who'd like to tackle this? Seems a waste to just close this inasmuch I as a lot of the grunt work has been done; or maybe not - it wasn't a waste for me in terms of learning though. James http://codereview.appspot.com/4005046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add new merge-function.ly file for rests (issue4005046)
On 1/24/11, pkx1...@gmail.com wrote: > > No problem. What would be the best thing to do with this 'code' would > putting the 'patch' I have on the tracker issue, with explanation and > appropriate comments from this Rietveld thread, be the right thing if > only to save re-doing more work for anyone who'd like to tackle this? Could do. I think that the main point of doing this would be to motivate somebody to look at the engraver stuff -- "hey, James did a fair amount of work on this and showed that he was serious; I'll tackle this new feature request instead of some other one". > Seems a waste to just close this inasmuch I as a lot of the grunt work > has been done; or maybe not - it wasn't a waste for me in terms of > learning though. One definite benefit would be if you wrote a few words about what you just did. Find somewhere in the CG programming chapter, or maybe even make your own @node @subsection or @subsubsection or something like that, and put down a few notes about what you just did. Once you actually know what you're doing, this kind of grunt work only takes a few minutes. The difficult thing is discovering *what* work to do, and that's what the CG is for. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Going on hols
Having a few days skiing in the USA from Tuesday (tomorrow) to Thursday 3rd Feb. Will not have my desktop with me - just me little laptop that's set up differently and so may not be able to contribute too much. Wonder whether we'll have a stable release for my return? -- Phil Holmes Bug Squad ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Is it possible to have a single \override for same context/Grob for different property values?
Hello, According to the NR it states: \override context.GrobName #'property = #value Is more-or-less equivalent to: \set context.GrobName = #(cons (cons 'property value) So I wondered if it is possible to save some lines of code/simplify overrides for the same context/Grob such that I can write 'something like' \override context.GrobName ( ( #'property1 = #value1) (#'property2 = #value2) (#'property3 = #value3) ) Although I know that the above syntax doesn't work I hope you get the idea. James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Going on hols
On 1/24/11, Phil Holmes wrote: > Having a few days skiing in the USA from Tuesday (tomorrow) to Thursday 3rd > Feb. Will not have my desktop with me - just me little laptop that's set up > differently and so may not be able to contribute too much. Have fun! > Wonder whether we'll have a stable release for my return? Absolutely not -- we have a 14-day waiting period after 0 critical issues are reached. If all 5 current Critical issues were patched (and pushed) immediately, the we'd be looking at a stable release on 7 Feb. Assuming that nobody found any other critical problems. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Going on hols
-Original Message- From: Graham Percival Date: Mon, 24 Jan 2011 18:07:13 + To: Phil Holmes Cc: lilypond-devel Subject: Re: Going on hols >On 1/24/11, Phil Holmes wrote: >> Having a few days skiing in the USA from Tuesday (tomorrow) to Thursday >>3rd >> Feb. Will not have my desktop with me - just me little laptop that's >>set up >> differently and so may not be able to contribute too much. > >Have fun! > >> Wonder whether we'll have a stable release for my return? > >Absolutely not -- we have a 14-day waiting period after 0 critical >issues are reached. If all 5 current Critical issues were patched >(and pushed) immediately, the we'd be looking at a stable release on 7 >Feb. Assuming that nobody found any other critical problems. > Well then, let's hope we have a 'stable Phil' (with no critical issues) when he returns. :) Don't forget to wrap up warm! Have fun James > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041)
Is there any point in anyone working on 1474 before this is resolved? /Bernard On Mon, Jan 24, 2011 at 02:24:16PM -, Phil Holmes wrote: > - Original Message - From: > To: > Cc: ; > Sent: Monday, January 24, 2011 5:15 AM > Subject: Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041) > > >> Extended to cover the other issues that were fixed along with 1120. The >> regression test that /could/ have caught the breakage of issue 1120 is >> revised so it will (more likely) catch any future breakage. > > > FWIW had I been running my pixel comparator then, I'd have spotted this > easily. > > -- > Phil Holmes > > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041)
On 1/24/11 11:15 AM, "Bernard Hurley" wrote: > Is there any point in anyone working on 1474 before this is resolved? I don't think so. 1120, 1472, and 1474 are intimately connected and will be resolved together. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
now I see I forgot to answer a question:
> http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode380
> lily/mensural-ligature-engraver.cc:380: {
> Why put the {} in this case?
because variables defined there should not be seen in the default case.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
new patchset up. please advise me about regression tests: can I modify ligatures within mensural-ligatures.ly? if not, can I add new ones to the same file? http://codereview.appspot.com/3797046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
>> please advise me about regression tests: can I modify ligatures within >> mensural-ligatures.ly? if not, can I add new ones to the same file? > > Ancient music has been abandoned by developers for a number of years. > IMO, you may do whatever you think makes the most sense as you try to > bring ancient music back into the mainstream of LilyPond development. I thought there might be a general policy about editing files in the regression suite. p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
On 2011/01/24 21:27:35, benko.pal wrote: new patchset up. please advise me about regression tests: can I modify ligatures within mensural-ligatures.ly? if not, can I add new ones to the same file? Ancient music has been abandoned by developers for a number of years. IMO, you may do whatever you think makes the most sense as you try to bring ancient music back into the mainstream of LilyPond development. Thanks, Carl http://codereview.appspot.com/3797046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
On 1/24/11 3:31 PM, "Benkő Pál" wrote: >>> please advise me about regression tests: can I modify ligatures within >>> mensural-ligatures.ly? if not, can I add new ones to the same file? >> >> Ancient music has been abandoned by developers for a number of years. >> IMO, you may do whatever you think makes the most sense as you try to >> bring ancient music back into the mainstream of LilyPond development. > > I thought there might be a general policy about editing files in the > regression suite. As far as I know, the only policies we have about writing regression tests are in the Contributors' Guide, section 10.8.2 Writing regression tests. " Regression tests should be as brief as possible to demonstrate the functionality of the code. Regression tests should generally cover one issue per test. Several short, single-issue regression tests are preferred to a single, long, multiple-issue regression test. Use existing regression tests as templates to demonstrate the type of header information that should be included in a regression test. " Sometimes a regression test is intended to show all possible functionality. In such a case, an existing test should be extended to show the added functionality. But where possible, we try to keep tests to a single issue. Personally, I will trust your judgment in this case. Do what seems best. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixing issue 37 with extra position callback (issue3928041)
On 24 January 2011 14:28, Han-Wen Nienhuys wrote: > See attached (it applies on top of issue3928041_55001.diff) + common[a] = common_refpoint_of_array (covered_grobs, me, Axis (a)); I suspect this line needs changing, otherwise it junks the calculated refpoint for the stems (which means we no longer get the correct refpoint for cross-staff beams). + common[a] = common_refpoint_of_array (covered_grobs, common[a], Axis (a)); Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is it possible to have a single \override for same context/Grob for different property values?
On 24 January 2011 17:30, James Lowe wrote:
> So I wondered if it is possible to save some lines of code/simplify
> overrides for the same context/Grob such that I can write 'something like'
>
> \override context.GrobName ( ( #'property1 = #value1) (#'property2 =
> #value2) (#'property3 = #value3) )
Here's an idea:
overrideGrobProps =
#(define-music-function (parser location grob-name prop-list) (symbol?
cheap-list?)
(make-sequential-music
(map (lambda (entry)
(make-grob-property-override grob-name (car entry) (cadr entry)))
prop-list)))
\relative c' {
c4 cis d des
% apply \override to list of properties + values (not \once)
\overrideGrobProps #'Accidental #`((color ,red) (font-size 4)
(extra-offset (1.5 . 3)))
\overrideGrobProps #'NoteHead #'((style mensural) (duration-log 0))
c4 cis d des
}
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is it possible to have a single \override for same context/Grob for different property values?
On 1/24/11 4:55 PM, "Neil Puttock" wrote:
> On 24 January 2011 17:30, James Lowe wrote:
>
>> So I wondered if it is possible to save some lines of code/simplify
>> overrides for the same context/Grob such that I can write 'something like'
>>
>> \override context.GrobName ( ( #'property1 = #value1) (#'property2 =
>> #value2) (#'property3 = #value3) )
>
> Here's an idea:
>
> overrideGrobProps =
> #(define-music-function (parser location grob-name prop-list) (symbol?
> cheap-list?)
>(make-sequential-music
> (map (lambda (entry)
>(make-grob-property-override grob-name (car entry) (cadr entry)))
> prop-list)))
>
> \relative c' {
> c4 cis d des
> % apply \override to list of properties + values (not \once)
> \overrideGrobProps #'Accidental #`((color ,red) (font-size 4)
> (extra-offset (1.5 . 3)))
If you use pairs, instead of lists, for the property overrides then the
override list is a standard alist:
\overrideGrobProps #'Accidental #`((color . ,red) (font-size . 4)
(extra-offset . (1.5 . 3)))
Seems like this might be able to be implemented in core LilyPond, but it's a
GLISS topic, I think.
Great idea!
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is it possible to have a single \override for same context/Grob for different property values?
On 25 January 2011 00:10, Carl Sorensen wrote: > If you use pairs, instead of lists, for the property overrides then the > override list is a standard alist: > > \overrideGrobProps #'Accidental #`((color . ,red) (font-size . 4) > (extra-offset . (1.5 . 3))) Yup, but then you have to type those annoying full stops (or periods, if you prefer. :) Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is it possible to have a single \override for same context/Grob for different property values?
On 1/24/11 5:15 PM, "Neil Puttock" wrote: > On 25 January 2011 00:10, Carl Sorensen wrote: > >> If you use pairs, instead of lists, for the property overrides then the >> override list is a standard alist: >> >> \overrideGrobProps #'Accidental #`((color . ,red) (font-size . 4) >> (extra-offset . (1.5 . 3))) > > Yup, but then you have to type those annoying full stops (or periods, > if you prefer. :) > This is true, but it's also consistent with the standard idiom of LilyPond (another GLISS discussion, I suppose) Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix critical regressions to lyric spacing (issue4061043)
On 2011/01/24 16:33:22, Graham Percival wrote: Almost there. Could you run makelsr and then don't forget to do git add Documentation/snippets/*.ly Done, and new patch set uploaded. Thanks, Carl http://codereview.appspot.com/4061043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixing issue 37 with extra position callback (issue3928041)
On Mon, Jan 24, 2011 at 9:40 PM, Neil Puttock wrote: > + common[a] = common_refpoint_of_array (covered_grobs, me, Axis (a)); > > I suspect this line needs changing, otherwise it junks the calculated > refpoint for the stems (which means we no longer get the correct > refpoint for cross-staff beams). > > + common[a] = common_refpoint_of_array (covered_grobs, common[a], > Axis (a)); Yes, you are correct. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Do we have a git-cl problem with lilydev?
We have had multiple contributors (Keith O'Hara, Mike Solomon, Valentin Villenave) who were unable to successfully upload patches to Rietveld for review. Keith tracked it down to a missing entry in /etc/mime.types on his system. I've added a note to the CG, so we don't lose Keith's information, but... I'd like to have somebody who is working on lilydev make a patch that involves a .scm file (e.g. delete a line starting with a semicolon) and then upload the patch for review. If we can't upload the patch for review, we may need to make an adjustment to lilydev. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041)
This patch also resolves the problem in issue 1229 of notes extending beyond the right-hand bar line. Adding additional extra-spacing-height to the TimeSignature grob resolves the 1229 issue of overlapping the time signature. This patch seems to have some very good benefits. http://codereview.appspot.com/4095041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041)
On Mon, 24 Jan 2011 20:47:24 -0800, wrote:
This patch also resolves the problem in issue 1229 of notes extending
beyond the right-hand bar line.
Adding additional extra-spacing-height to the TimeSignature grob
resolves the 1229 issue of overlapping the time signature.
This patch seems to have some very good benefits.
The patch doesn't take any specific action for issues 1472 1474 1229. I'd say it
"reduces these other issues to their version-2.12.3 status," in which version
they were un-noticed.
I especially like that it reduces back to 2.12.3-levels the frequency of slurs
confusing note separation { g''8( c''-> geses'' a'') }.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
