LGTM
I think the templates would be improved with
system-system-spacing #'basic-distance = #20
added to \paper. Otherwise the bass lyrics will be too
close to the soprano lyrics on the following system.
Trevor
http://codereview.appspot.com/4061043/
2011/1/23 Francisco Vila paconet@gmail.com:
I'll make a proper patch for the docs.
The patch (attached) for English docs only; compiles fine.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
From b505e6f9223064dce458bd5fa1775332878fb1e9 Mon Sep 17 00:00:00 2001
From:
Francisco Vila wrote Sunday, January 23, 2011 10:01 AM
The patch (attached) for English docs only; compiles fine.
Not my most favourite piece of vocal music, but it
makes a fine headword!
LG to push TM.
Trevor
___
lilypond-devel mailing list
2011/1/23 Trevor Daniels t.dani...@treda.co.uk:
Francisco Vila wrote Sunday, January 23, 2011 10:01 AM
The patch (attached) for English docs only; compiles fine.
Not my most favourite piece of vocal music,
I think the same :-)
but it
makes a fine headword!
LG to push TM.
OK, I'll
Le 23/01/2011 12:20, Francisco Vila disait :
2011/1/23 Trevor Danielst.dani...@treda.co.uk:
Francisco Vila wrote Sunday, January 23, 2011 10:01 AM
The patch (attached) for English docs only; compiles fine.
Not my most favourite piece of vocal music,
I think the same :-)
but it
makes a
2011/1/23 Jean-Charles Malahieude lily...@orange.fr:
I'll take care of it for French, since I'm in a full review of the French
version and wishing to have it up to date with 2.14.
Pushed in English and Spanish only.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
This looks like Issue 1098. That one was closed due to lack of
reproducible scenario: my scores, too, were crashing Lilypond after
growing above a certain size, but just like in your case, I can not
reproduce it with a simple \repeat.
On 11-01-16 12:57 PM, Benkő Pál wrote:
following up
Hi,
In order to understand the lily code better I read Erik Sandberg’s
master's thesis. The idea of a music stream seems very interesting. Is
this anywhere near being implemented?
Cheers,
/Bernard
___
lilypond-devel mailing list
On 1/23/11 6:22 AM, Bernard Hurley bern...@marcade.biz wrote:
Hi,
In order to understand the lily code better I read Erik Sandberg¹s
master's thesis. The idea of a music stream seems very interesting. Is
this anywhere near being implemented?
Yes, music streams are currently implemented in
On 1/23/11 6:20 AM, Boris Shingarov b...@shingarov.com wrote:
This looks like Issue 1098. That one was closed due to lack of
reproducible scenario: my scores, too, were crashing Lilypond after
growing above a certain size, but just like in your case, I can not
reproduce it with a simple
I think we have a convert-ly problem.
http://codereview.appspot.com/4061043/diff/1/Documentation/snippets/new/lyrics-old-spacing-settings.ly
File Documentation/snippets/new/lyrics-old-spacing-settings.ly (right):
On Sun, Jan 23, 2011 at 11:03:55AM -, 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.
Sure. Please create a patch in the way that James Lowe is
So I've declared myself Patch Meister for the immediate future. Once
2.14 is out, we'll have a discussion about how this should work, and
find somebody else to do it. Until then, just roll with it.
I've replaced label:patch with a few subcategories on the google issue tracker.
1)
Passes regtests, but a few minor nitpicks.
http://codereview.appspot.com/4025044/diff/10001/input/regression/bar-extent.ly
File input/regression/bar-extent.ly (right):
http://codereview.appspot.com/4025044/diff/10001/input/regression/bar-extent.ly#newcode1
input/regression/bar-extent.ly:1:
On 11-01-01 03:24 AM, Graham Percival wrote:
or an
art history / research grant. I think the latter is more
likely... for example, if somebody got a grant to typeset 17th
century Norweigan folk songs, and decided to use lilypond, and
spent x% of the grant towards improving community-oriented
On 2011/01/23 15:00:28, Graham Percival wrote:
Passes regtests, but a few minor nitpicks.
thanks, Graham; all observations implemented.
http://codereview.appspot.com/4025044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Looks good to me!
NB: I'm not vouching for the quality of the scheme or C++ code; that's
outside of my expertise. But the .ly files look fine, and the results
(in the form of the regtest comparison) look fine.
http://codereview.appspot.com/4025044/
On Sun, Jan 23, 2011 at 10:29:11AM -0500, Boris Shingarov wrote:
The Lilypond project has a very specific set of objectives. There
is a defined set of procedures, a roadmap, a set of criteria of
what is acceptable to go into the codebase, etc.
This is true of any (well-organized) project.
Looks good, but there's still some excessive beam translation in
slur-scoring.ly.
http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly
File input/regression/beam-collision.ly (right):
http://codereview.appspot.com/3992042/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):
http://codereview.appspot.com/3992042/diff/1/Documentation/changes.tely#newcode77
Documentation/changes.tely:77: c c c c c c c
c8
I noticed another nitpick.
http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly
File input/regression/beam-collision.ly (right):
http://codereview.appspot.com/3928041/diff/30001/input/regression/beam-collision.ly#newcode1
input/regression/beam-collision.ly:1:
Hi Carl,
Is moving `determine-frets-and-strings' required for the patch to work?
It makes reviewing the changes difficult.
Cheers,
Neil
http://codereview.appspot.com/4056041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
LGTM.
http://codereview.appspot.com/4099044/diff/1/input/regression/ambitus.ly
File input/regression/ambitus.ly (right):
http://codereview.appspot.com/4099044/diff/1/input/regression/ambitus.ly#newcode8
input/regression/ambitus.ly:8: Two noteheads are displayed even for a
note with two
2011/1/23 Graham Percival gra...@percival-music.ca:
Developers: please bookmark this:
http://code.google.com/p/lilypond/issues/listcan=2q=label:patch-review
A question mark character is missing in this URL inside listcan, it
should be list[question mark]can. Hopefully this will work:
Reviewers: Neil Puttock,
Message:
On 2011/01/23 18:00:23, Neil Puttock wrote:
LGTM.
Thanks!
I've uploaded patchset 3, which I believe fixes all these.
Cheers,
- Graham
Description:
Fix issue 1376 ambitus two accidentals.
Add regtest for 1376 ambitus accidentals.
When an ambitus consists
Hello and thank you Jakob, hello list,
this piece is a great work. It compiles well in 2.13(.47 lilybuntu) and adds a
very useful function to lily!
The .ly is attached again, because I think it is good to have it on the
devel-list.
I would like to add it to LSR to have it in the main distro
Hi everyone, I know the lilypond's main purpose isn't midi playback. HOWEVER :)
I am wondering if I can hack the source so that I can change what midi
pitch values are output when it renders. This is so that I can retune
the output with a software synth like csound or pd.
For instance, I would
Reviewers: carl.d.sorensen_gmail.com, Graham Percival,
Message:
I have done all the changes (except added a reg test) and uploaded them.
However this does not make cleanly. I am getting an error
current/scm/lily.scm:851:21: Unbound variable:
merge-rests-on-positioning
Any help would be
On 1/23/11 2:10 PM, pkx1...@gmail.com pkx1...@gmail.com wrote:
Reviewers: carl.d.sorensen_gmail.com, Graham Percival,
Message:
I have done all the changes (except added a reg test) and uploaded them.
However this does not make cleanly. I am getting an error
current/scm/lily.scm:851:21:
On 2011/01/23 18:21:11, Graham Percival wrote:
I've uploaded patchset 3, which I believe fixes all these.
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
http://codereview.appspot.com/4061043/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):
http://codereview.appspot.com/4061043/diff/1/Documentation/changes.tely#newcode70
Documentation/changes.tely:70: Lyrics above a staff must have their
@code{staff-affinity} set to
I
2011/1/23 Carl Sorensen c_soren...@byu.edu:
Well, you could call calc_length to get the stem length, since you have the
stem grob in the form of me, i.e.
Real length = robust_scm2double (me-calc_length (smob));
If you want to, you could try adding a saved value for the length so you
don't
This is a nice hack, but the way it's currently implemented makes it
unsuitable to be merged.
The full-bar rests should be collected by an engraver (like the
Rest_collision_engraver), rather than using a hash table.
http://codereview.appspot.com/4005046/
On 2011/01/22 20:29:17, Graham Percival wrote:
Patch looks great, passes regtests, and I built the docs from scratch
with it.
I think it's ready to be pushed.
Thanks. I've deliberately left out doc changes (i.e., snippets, removal
of known issue and changes entry), but they'd follow soon
On 2011/01/23 09:09:09, Trevor Daniels wrote:
I think the templates would be improved with
system-system-spacing #'basic-distance = #20
added to \paper. Otherwise the bass lyrics will be too
close to the soprano lyrics on the following system.
Done. I also added top-system-spacing and
I've responded to the comments in detail below.
Graham, relative to your comments on issues 1483 and 1486, both are
addressed in this patch.
The templates now have the lyrics attached properly to the staves, as do
the examples in the NR. This takes care of 1483.
The templates also have
On 1/23/11 7:54 AM, Graham Percival gra...@percival-music.ca wrote:
Developers: please bookmark this:
http://code.google.com/p/lilypond/issues/listcan=2=label:patch-review
http://code.google.com/p/lilypond/issues/listcan=2q=label:patch-review
This link is missing a ?, so it doesn't work.
On 1/23/11 4:03 AM, Trevor Daniels t.dani...@treda.co.uk 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
LGTM.
Carl
http://codereview.appspot.com/212048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
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.
I also had a question (and it probably doesn't
LGTM.
Carl
http://codereview.appspot.com/4099044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
I made a lot of changes to get things looking more lilypond-y.
I also now have it better handling scenarios where the subdivisions are
wacky. Check out:
\relative c' { { b32 [ c,16 c'8 d,64 e'8. c,32 e'' ] } \\ { f8 [ c32
d'32 bes,,64 c'64 c64 c'128 ] } }
The low D is snug as a bug in a
New patch set uploaded.
http://codereview.appspot.com/3928041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
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.
http://codereview.appspot.com/4095041/diff/32001/scm/define-grobs.scm
File
Sorry, I got the author incorrect.
Thanks for looking into this, Mike!
http://codereview.appspot.com/3928041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi Carl,
thanks for diving into this!
I love the idea of handling beam collisions, but I think the design of
the backend code is flawed. See my comments.
http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc
File lily/beam.cc (right):
http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc
File lily/beam.cc (right):
http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode1014
lily/beam.cc:1014: pos[RIGHT] += offset;
also, these offsets disregard carefully computed beam quantizations.
Even though these are
http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc
File lily/beam.cc (right):
http://codereview.appspot.com/3928041/diff/30001/lily/beam.cc#newcode1015
lily/beam.cc:1015: return ly_interval2scm (pos);
On 2011/01/23 18:05:39, hanwenn wrote:
it looks like this only handles the 1st
On Mon, Jan 24, 2011 at 12:58 AM, mts...@gmail.com wrote:
acknowledge manual beams only instead, then there's no need for this
hack
OK - but as far as I know, there is no way to have DECLARE_ACKNOWLEDGER
(manual_beam) . What would be the appropriate way to do this?
Look at the cause of
I think I may be losing my mind.
Somebody this weekend posted, either in an email or in an issue comment,
that they were finally able to upload patches to Rietveld.
They had been having a problem because their Python was linking .scm files
with a mime-type of a ScreenCam file, rather than a text
Mike, I tried Chopin preludes Opus 28 No. 1 (where I thought there might
be trouble because beams need to cross stems there) and No. 2 (the
classic example that benefits from this fix).
These, and the large score + parts I use for informal checking, look
good.
Hope you can keep weaving it in to
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
52 matches
Mail list logo
