hi all,
Regarding the quality of the patch: It's just fine. However, I can't
say anything about the details since my knowledge of mensural notation
is very limited. Especially the `sM2semimensural' in `parmesan20'
(which I'm currently looking at after applying the patch locally)
looks very
Especially the `sM2semimensural' in `parmesan20' (which I'm
currently looking at after applying the patch locally) looks very
strange, and I've never seen a similar note shape before. But I
suspect this is my lack of knowledge.
I'll try to compile a list of online facsimiles.
Yes, please
What do you think about activating this by default in lilypond-book
(and possibly providing an option to disable this)?
If this is a question about our build process (as I believe), then
whether or not it's enabled by default in lilypond-book is
completely separate issue.
It's both.
On Tue, Nov 9, 2010 at 5:40 PM, Werner LEMBERG w...@gnu.org wrote:
My question: Is it possible to implement a warning message for the
former case
I'm not sure how that would work. Perhaps we could add a check_context
function to property-iterator.cc, in addition to the existing
check_grob
Trevor Daniels wrote Tuesday, October 19, 2010 8:34 PM
Keith E OHara wrote Monday, October 18, 2010 11:40 PM
I suggest (diff attached) removing the part about
instrumentCueName in favor of a fuller example for \killCues.
The manual teaches markup elsewhere; the challenge with cue-note
Hi Patrick,
On 10/11/10 06:01, pnor...@gmail.com wrote:
Hi Ian,
LGTM.
Before sending me the git patch, I would recommend changing the subject
from Remove (define define-ly-syntax define-public) to something more
accurate that reflects what this patch fixes.
Thanks for your work on this!
Hope that helps... I'm attempting a GUB build for binary distribution
and fighting another problem :-)
I've created a GUB installer for linux-x86
http://lilypond.org/schikkers-list/download/
Example usage
schikkers-list or
schikkers-list
On Sun, Nov 07, 2010 at 01:33:48PM -0800, Keith E OHara wrote:
In fact, those tests did not include a case of Lyrics above their affinity
staff. My change (2b) placed a minimum-space rod from the centerline of the
staff to the baseline of Lyrics, which pushes lyrics-above too far away.
It's now been a week since report 22 came out and the -hackers
drama began.
The positive outcome is:
- we pushed an 18-line patch to the CG which says there is a
dormant lilypond-hackers mailing list, which we'll sort out
after 2.14 is out.
The neutral outcome is our policies -- there was no
On Mon, Nov 08, 2010 at 01:26:41PM +0100, Xavier Scheuer wrote:
On 8 November 2010 13:05, Valentin Villenave valen...@villenave.net wrote:
Please repost your mail as a comment there, I think it will be more
appropriate, useful and (possibly) efficient :-)
Actually I'm sad when I see this
On 11/10/10 9:05 PM, Mark Polesky markpole...@yahoo.com wrote:
The \paper variables are completely absent from the IR.
Shouldn't they be included in an internals reference?
I assume so. Let's open a tracker issue
Carl
___
lilypond-devel
Reviewers: ,
Message:
Here's a new patch-set for renaming the vertical spacing
grob properties. But...
I'm kind of going in circles trying to decide where to put
some things:
1) individual alist-key descriptions
2) individual grob-property descriptions
3) non-staff line reference-points
I
On 2010/11/11 03:53:44, Mark Polesky wrote:
Here's a new patch-set for renaming the vertical spacing
grob properties. But...
I'm kind of going in circles trying to decide where to put
some things:
1) individual alist-key descriptions
2) individual grob-property descriptions
3) non-staff
Many of my general comments were in my reply to your message. There are
some specifics in the files here.
Thanks,
Carl
http://codereview.appspot.com/3031041/diff/30001/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):
14 matches
Mail list logo
