Reviewers: benko.pal,
Message:
On 2012/09/28 07:52:32, benko.pal wrote:
what about an example like
\afterGrace f1\glissando f'16
?
Done - thanks!
Description:
Doc: extend description of glissandi (2844)
Add examples of
- connecting notes across staves
- connecting notes in chords
Am 28.09.2012 17:40, schrieb d...@gnu.org:
On 2012/09/28 15:06:38, janek wrote:
On Fri, Sep 28, 2012 at 9:30 AM, mailto:d...@gnu.org wrote:
I must be in a controversial mood today since I feel like upholding
the
idea. I had been thinking about it while fetching breakfast and
eating
and
On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup d...@gnu.org wrote:
Han-Wen Nienhuys hanw...@gmail.com writes:
In order to do cache invalidation, you will have to construct the
reverse graph. If A.x depends on B.y, now A points to B. For proper
cache invalidation, if B.y changes, then A.x
Marc Hohl m...@hohlart.de writes:
Am 28.09.2012 17:40, schrieb d...@gnu.org:
hmm... not quite perfect.
No other idea, though...
\here misses the relation to the next item (not that \single is much
better). \directly was nicer in that regard. \next would possibly also
work.
Having to
Am 28.09.2012 12:24, schrieb Phil Holmes:
- Original Message - From: Marc Hohl m...@hohlart.de
To: lilypond-devel@gnu.org
Sent: Friday, September 28, 2012 11:00 AM
Subject: Re: Error tracking through the log files [was: Re:
Compilation errorwith page-breaking-page-count3.ly]
[...]
Am 29.09.2012 07:11, schrieb k-ohara5...@oco.net:
Looks good so far.
In one pdf previewer (evince) at low resolution, the span bars look a
little thicker than the regular bar lines. Maybe a rounding fault of
the viewer, but it would be better if you know how to avoid it.
If you zoom it, this
Am 29.09.2012 11:01, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
Am 28.09.2012 17:40, schrieb d...@gnu.org:
hmm... not quite perfect.
No other idea, though...
\here misses the relation to the next item (not that \single is much
better). \directly was nicer in that regard.
On 29 sept. 2012, at 10:59, Han-Wen Nienhuys hanw...@gmail.com wrote:
On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup d...@gnu.org wrote:
Han-Wen Nienhuys hanw...@gmail.com writes:
In order to do cache invalidation, you will have to construct the
reverse graph. If A.x depends on B.y, now A
On Sat, Sep 29, 2012 at 11:35 AM, m...@mikesolomon.org
m...@mikesolomon.org wrote:
On 29 sept. 2012, at 10:59, Han-Wen Nienhuys hanw...@gmail.com wrote:
On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup d...@gnu.org wrote:
Han-Wen Nienhuys hanw...@gmail.com writes:
In order to do cache
Reviewers: janek,
Message:
On 2012/09/28 06:22:40, janek wrote:
The description looks really nice, but unfortunately i think i don't
grasp the
consequences of this change. Could you give some before/after input
examples?
Embarrassingly, not really. The point of this change is to move
On Sat, Sep 29, 2012 at 3:10 PM, d...@gnu.org wrote:
Embarrassingly, not really. The point of this change is to move forward
in removing the special-casing of various *_IDENTIFIER token types. The
target is to arrive at only a single SCM_IDENTIFIER type. Once that is
achieved, it is no
On 2012/09/29 13:37:28, janek wrote:
On Sat, Sep 29, 2012 at 3:10 PM, mailto:d...@gnu.org wrote:
Embarrassingly, not really. The point of this change is to move
forward
in removing the special-casing of various *_IDENTIFIER token types.
The
target is to arrive at only a single
Marc Hohl m...@hohlart.de writes:
Am 29.09.2012 11:01, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
Am 28.09.2012 17:40, schrieb d...@gnu.org:
hmm... not quite perfect.
No other idea, though...
\here misses the relation to the next item (not that \single is much
better).
Am 29.09.2012 17:01, schrieb lilyp...@googlecode.com:
Comment #1 on issue 2868 by mts...@gmail.com: Patch: Various clean-ups
in stems and beams.
http://code.google.com/p/lilypond/issues/detail?id=2868#c1
Various clean-ups in stems and beams.
*) Eliminates code dups for Kievan work.
*)
On Sat, Sep 29, 2012 at 4:30 PM, d...@gnu.org wrote:
Actually, it is not really simplifying the grammar. At the current
point of time, the lexer has to make decisions about the type of
identifiers (and functions) at a point of time where those decisions are
actually premature. As a result
Han-Wen Nienhuys hanwenn at gmail.com writes:
I think it is a much clearer abstraction to decide that each property
can only be evaluated once, and that everything should be driven by
callbacks. In fact, one thing I would suggest looking at is removing
{before,after}_line_breaking which
David == David Kastrup d...@gnu.org writes:
\bar inserts an empty stencil, so the padding around the
(invisible) bar line is preserved.
David Yes, I understood that. But what do we need that for?
For the Renaissance music I transcribe, the composers weren't thinking
in bar
Too bad that \delete is taken...
Maybe using \no is the right choice, although i'd prefer to make this
decision after GLISS decides that we don't need \no for something else.
As for \single vs. \next, i don't have a strong opinion.
Janek
http://codereview.appspot.com/6575048/
Am 29.09.2012 18:39, schrieb Laura Conrad:
David == David Kastrup d...@gnu.org writes:
\bar inserts an empty stencil, so the padding around the
(invisible) bar line is preserved.
David Yes, I understood that. But what do we need that for?
For the Renaissance music I
On 12-09-29 09:47 AM, David Kastrup wrote:
I am not convinced. Unless I see either a new proposal that I feel I
can get behind myself, or more prominent public support for one of the
numerous existing proposals including \next, I am going to stick with
\single.
Since by far the easiest time to
Am 29.09.2012 18:54, schrieb Colin Campbell:
On 12-09-29 09:47 AM, David Kastrup wrote:
I am not convinced. Unless I see either a new proposal that I feel I
can get behind myself, or more prominent public support for one of the
numerous existing proposals including \next, I am going to stick
Am 27.09.2012 00:32, schrieb Thomas Morley:
2012/9/26 Marc Hohl m...@hohlart.de:
I like the idea of giving the user the ability to change only parts of the
list
without having to rewrite the full list; I think that this concept could be
of
use in other parts of lilypond as well,
Hi Marc,
Marc == Marc Hohl m...@hohlart.de writes:
I hope that the new interface both makes more sense than the old one,
and still allows me to set barless music without ugly gaps where the bar
lines aren't.
Marc Hmmm - with the new interface, nonexistent bar lines are not
Marc
Hmm.
My answer to how would we place the glyph at the correct vertical
position, above the barline? is: i suppose that we're going to create
a \tickBreathe command; if so, i guess that defining it in this manner
tickBreathe = {
\override BreathingSign #'outside-staff-priority = something
On 29 sept. 2012, at 18:34, Keith OHara k-ohara5...@oco.net wrote:
Han-Wen Nienhuys hanwenn at gmail.com writes:
I think it is a much clearer abstraction to decide that each property
can only be evaluated once, and that everything should be driven by
callbacks. In fact, one thing I would
- Original Message -
From: Janek Warchoł janek.lilyp...@gmail.com
To: Phil Holmes m...@philholmes.net
Cc: James pkx1...@gmail.com; lilypond-devel@gnu.org; d...@gnu.org;
lemzw...@googlemail.com; re...@codereview-hr.appspotmail.com;
philehol...@googlemail.com
Sent: Saturday, September
On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org m...@mikesolomon.org
wrote:
The way you're using tentative is almost exactly how pure properties are used
in LilyPond.
Specifically, 'pure-height being the estimated vertical extent before
line-breaking, while 'height is its extent
On 29 sept. 2012, at 19:53, Keith OHara k-ohara5...@oco.net wrote:
On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org
m...@mikesolomon.org wrote:
The way you're using tentative is almost exactly how pure properties are
used in LilyPond.
Specifically, 'pure-height being the
Am 29.09.2012 19:05, schrieb Laura Conrad:
Marc == Marc Hohl m...@hohlart.de writes:
I hope that the new interface both makes more sense than the old one,
and still allows me to set barless music without ugly gaps where the bar
lines aren't.
Marc Hmmm - with the new
David Kastrup wrote Saturday, September 29, 2012 4:47 PM
Marc Hohl m...@hohlart.de writes:
Am 29.09.2012 11:01, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
Am 28.09.2012 17:40, schrieb d...@gnu.org:
hmm... not quite perfect.
No other idea, though...
\here misses the
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Saturday, September 29, 2012 4:47 PM
Since by far the easiest time to press a change is before a first
version is installed, people should speak up now if they feel that
c' \next \easyHeadsOn e' g' is significantly better than
On 2012/09/29 09:14:08, marc wrote:
Am 29.09.2012 07:11, schrieb k-ohara5...@oco.net:
In one pdf previewer (evince) at low resolution, the span bars look
a
little thicker than the regular bar lines.
Disregard. The slight mis-rendering on screen was there before your
patch as well.
Now looking at the log files, I do get undead errors for our
regression test 'bar-line-define-bar-glyph.ly' but not from any other
files that I tried. (I don't know why the scripts from `make check` did
not flag it.)
There are four messages, but the particular undead objects vary from run
to
I prefer \single to \next.
\justOne \onlyOne ?
It is, in a way, a complement to \once, so I would want to avoid
multiple-word approaches leading to CamelCase.
Had someone already suggested \here?
Werner
___
lilypond-devel mailing list
LGTM.
http://codereview.appspot.com/6594047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Mon, Sep 24, 2012 at 10:43:25AM +0100, Phil Holmes wrote:
- Original Message - From: Graham Percival
gra...@percival-music.ca
Either lilypond.make has changed (only one change in the past two
years:
https://github.com/gperciva/gub/commit/dd2f4077f5f818a6f689b0f4a795bacb92dcb8ae
36 matches
Mail list logo
