LGTM
https://codereview.appspot.com/167040043/diff/1/lily/side-position-interface.cc
File lily/side-position-interface.cc (right):
https://codereview.appspot.com/167040043/diff/1/lily/side-position-interface.cc#newcode383
lily/side-position-interface.cc:383: /* If we are closer to the staff
Feliz cumpleaños, LilyPond!
El 01/11/2014 07:11, Francisco Vila paconet@gmail.com escribió:
Sorry for the cross-posting. Just a short note to say LIlyPond is 18
since october if our git history is true.
Congrats to all for using/developing/maintaining/enjoying this great
piece of
[release/2.19.15-1-13-gdd5a6e7]
Folks,
with this input
\relative c' {
gis' cis e8[ r fis gis dis' e gis cis]
}
I would expect that there is at least a tiny distance between the rest
and the sharp, but it seems that they directly touch – is this
expected? Having such a dense setting
As the subject line says: What can I do to make the horizontal space
between a time signature and following material squeezable? Even in
extremely dense situations lilypond is merciless and bravely defends
the gap, which gets even disturbing in situation like
\relative c' {
e1 |
\time
Werner LEMBERG wrote Sunday, November 02, 2014 7:03 AM
[release/2.19.15-1-13-gdd5a6e7]
with this input
\relative c' {
gis' cis e8[ r fis gis dis' e gis cis]
}
I would expect that there is at least a tiny distance between the rest
and the sharp, but it seems that they directly
https://codereview.appspot.com/13242056/diff/26001/lily/part-combine-iterator.cc
File lily/part-combine-iterator.cc (right):
https://codereview.appspot.com/13242056/diff/26001/lily/part-combine-iterator.cc#newcode37
lily/part-combine-iterator.cc:37: = {one, two, shared, solo,
null};
On
On Nov 2, 2014, at 03:15 , Werner LEMBERG w...@gnu.org wrote:
As the subject line says: What can I do to make the horizontal space
between a time signature and following material squeezable? Even in
extremely dense situations lilypond is merciless and bravely defends
the gap, which gets
Hello,
i have a question concerning the parser of LilyPond. I would like to
use it as standalone, so I can do some analysis on its AST
representation (i.e. the music expression tree):
From the received AST I would like to read out all notation relevant
data e.g. notes, durations,
Having such a dense setting for a situation where lilypond isn't
forced to squeeze at all is bad IMHO.
I'd call this a bug. The manual beam over the rest is necessary to
provoke it. The bug was introduced during the 2.15 develoment cycle
- in 2.14.2 it displays nicely, but compresses in
s9vah...@stud.uni-saarland.de writes:
Hello,
i have a question concerning the parser of LilyPond. I would like to
use it as standalone, so I can do some analysis on its AST
representation (i.e. the music expression tree):
From the received AST I would like to read out all notation relevant
This is
https://code.google.com/p/lilypond/issues/detail?id=1785
For four years this space was too compressible, and would not stretch.
The behavior did not match the names of the settings and code comments,
so I raised issue 1785 to make the space rigid.
Another option, semi-fixed-space in
'notehead' noted.
On Sat, 01 Nov 2014 23:43:34 -0700, lemzw...@googlemail.com wrote:
/* If we are closer to the staff than the notehead,
quantize for ledger lines. */
But I wonder whether this is the best description – it's rather about
note heads and attached grobs having the same
Dan Eble dan at faithful.be writes:
On Nov 1, 2014, at 18:48 , Noeck noeck.marburg at gmx.de wrote:
* leave the default style alone
* add to the C style: 4/2 - CC, 2/1 - cut-CC
This would end the equivalence of default and C styles.
Does that seem like a bad idea to any seasoned
I'm not comfortable pushing this, there were some things on the original
email
http://lists.gnu.org/archive/html/bug-lilypond/2014-10/msg00024.html
(after which I offered to help move a patch through the list) that I am
simply not qualified to say if it is still OK to push or still needs
some
On Nov 2, 2014, at 10:58 PM, pkx1...@gmail.com wrote:
I'm not comfortable pushing this, there were some things on the original
email
http://lists.gnu.org/archive/html/bug-lilypond/2014-10/msg00024.html
(after which I offered to help move a patch through the list) that I am
simply not
I'll mark issue 1785 as open.
Thanks.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hello,
Here is the current patch countdown list. The next countdown will be on
November 5th.
You can always view the most current countdown list here:
http://code.google.com/p/lilypond/issues/list?q=Patch%3Apush%2Ccountdown%2Creview%2Cnew%2Cwaitingcolspec=Patch%20Owner%20ID%20Summarysort=patch
On Nov 2, 2014, at 14:52 , Keith OHara k-ohara5...@oco.net wrote:
The current code has some logic to choose a glyph timesig.C34 if we
set style=C in 3/4 time, but it seems that code is disabled by complex
logic. Cleaning that up, as part of moving toward scheme markup,
would be nice.
I
On Sun, 02 Nov 2014 18:11:58 -0800, Dan Eble d...@faithful.be wrote:
On Nov 2, 2014, at 14:52 , Keith OHara k-ohara5...@oco.net wrote:
The current code has some logic to choose a glyph timesig.C34 if...
I followed everything you said except this, maybe because of the sudden mention of
19 matches
Mail list logo
