http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc#newcode284
lily/stem.cc:284: string style = robust_symbol2string
(heads[0]->get_property ("style"), "default");
I think Aleksandr is right.
See h
LGTM.
http://codereview.appspot.com/5504091/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi David,
Could you make your own patch for the doc changes?
And, as you mentionned, the unused function should be removed. Do you
want me to commit this change?
Bertrand
http://codereview.appspot.com/4917044/
___
lilypond-devel mailing list
lilypon
LGTM. You'll be happy to know that Mike and I are currently trying to
get rid of \markuplines, so that there will only be a \markup command.
http://codereview.appspot.com/5312050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gn
"lily-guile updates" pushed as 6ee8c04678442855cb794d4598c056c15c42673b.
http://codereview.appspot.com/4917044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Sorry for this total mistake. !ly_is_equal (..., SCM_EOL) should do it,
then.
http://codereview.appspot.com/5293053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
A small comment to show you a possible solution for the indentation.
This can be apply at every "line length" comment.
http://codereview.appspot.com/5293053/diff/12001/lily/page-breaking.cc
File lily/page-breaking.cc (right):
http://codereview.appspot.com/5293053/diff/12001/lily/page-breaking.c
http://codereview.appspot.com/5293053/diff/12001/lily/page-layout-problem.cc
File lily/page-layout-problem.cc (right):
http://codereview.appspot.com/5293053/diff/12001/lily/page-layout-problem.cc#newcode79
lily/page-layout-problem.cc:79: footnotes_added = g->get_property
("footnote-stencil") !=
I can't compile because of valgrind.
Bertrand
http://codereview.appspot.com/5293053/diff/12001/lily/include/page-layout-problem.hh
File lily/include/page-layout-problem.hh (right):
http://codereview.appspot.com/5293053/diff/12001/lily/include/page-layout-problem.hh#newcode100
lily/include/page
http://codereview.appspot.com/5306050/diff/2001/lily/spring-smob.cc
File lily/spring-smob.cc (left):
http://codereview.appspot.com/5306050/diff/2001/lily/spring-smob.cc#oldcode42
lily/spring-smob.cc:42: return a == b ? SCM_BOOL_T : SCM_BOOL_F;
On 2011/10/21 11:27:35, dak wrote:
scm_is_true (scm
LGTM.
http://codereview.appspot.com/5306050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, but the result is really disturbing. We need to think about a
better approach of character boxes in MetaFont. The ideal solution
would be to create a mask for each character. For example, a mask for
the "espressivo" glyph would be a "fill" between its 6 dots.
I know it's impossible to in
LGTM. Two tiny changes and it'll be ready to push.
http://codereview.appspot.com/4951062/diff/78001/ly/engraver-init.ly
File ly/engraver-init.ly (right):
http://codereview.appspot.com/4951062/diff/78001/ly/engraver-init.ly#newcode1107
ly/engraver-init.ly:1107: \remove Stem_engraver
Sorry, I ma
I pushed the doc as b4a2cb2cf00347c477ed595f1435cc212e70ce33.
Could the remaining C part of the patch be 'countdowned'?
http://codereview.appspot.com/4917044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinf
Pushed as 8adeb99e344bf047b9b3b9b48a9e97e59e8fc4d3 and
71aa438bce0f68b0e8ab8c633b4902c971ede48b.
http://codereview.appspot.com/5233042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
http://codereview.appspot.com/5240054/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
http://codereview.appspot.com/5240054/diff/1/Documentation/contributor/source-code.itexi#newcode953
Documentation/contributor/source-code.itexi
Thanks Neil, I'll make two commits. Do you want to see them both on
codereview?
Comment in lily-guile restored.
http://codereview.appspot.com/5233042/diff/12001/lily/lily-guile.cc
File lily/lily-guile.cc (left):
http://codereview.appspot.com/5233042/diff/12001/lily/lily-guile.cc#oldcode72
lily
http://codereview.appspot.com/5233042/diff/1/lily/note-head.cc
File lily/note-head.cc (right):
http://codereview.appspot.com/5233042/diff/1/lily/note-head.cc#newcode79
lily/note-head.cc:79: out = fm->find_by_name (idx_either);
Unfortunately, this doesn't work. If the condition line 73 is false,
Here's the second part of my review. I saw that kievan notation has
beams, contrary to what I thought. If you're intrepid, you can also try
to implement the kievan beaming parameters in you KievanVoice.
Hold on, it's the end!
Bertrand
http://codereview.appspot.com/4951062/diff/64002/mf/parmes
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc#newcode855
lily/stem.cc:855: if (attach && !scm_is_eq (style, ly_symbol2scm
("mensural"))
I meant: the stem is aligned to the right of the attach
Reviewers: ,
Message:
Hi,
This is a try to increase performance, especially under Windows (see
http://code.google.com/p/lilypond/issues/detail?id=1926).
As I don't use Windows to compile LilyPond, can someone test it?
Regards,
Bertrand
Description:
Optimizes note-heads.cc and introduces robus
You can't solve the Kievan bar line problem without calculate every dot
position. I made a pure MetaFont version of the Kievan bar line:
fet_beginchar ("kievan end of piece (slash)", "barline.kievan");
% this draws the end of piece figure
% this figure is placed at the end of the
Thanks Keith, I'll quickly fix that in a new issue.
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc#newcode853
lily/stem.cc:853: extract_grob_set (me, "note-heads", heads);
... OK.
http://cod
Pushed as bb7cac7b276bd7d1335523f3be8df815cf894ece.
http://codereview.appspot.com/4514042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Very good! The MetaFont code could still be improved, but don't think
about it. The only things you have to improve in MetaFont are the
character boxes, which are broken. Example:
\markup \box { \musicglyph #"noteheads.u3kievan" \musicglyph
#"scripts.barline.kievan" \musicglyph #"accidentals.ki
This passes make and make doc on my computer, without a scratch.
This is a great work, but it doesn't fit correctly into LilyPond:
* This should be put inside the parmesan font, like every ancient font:
noteheads in parmesan-noteheads, accidentals in parmesan-accidentals,
clef in parmesan-clefs,
Pushed as 688f5f1711d8ca07338385a2ae0191b1a8aae315.
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Update done.
I think the C part is ok.
There's maybe a few things to change in the doc.
Shall I wait for a countdown or push directly?
Bertrand
http://codereview.appspot.com/4917044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://list
Pushed as 829f0ded77ee44ea6f0566fb5e5318802a8857ad.
http://codereview.appspot.com/5030053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Thanks a lot, Neil.
Could you have a last look at the Scheme files?
I'm not sure of the indentation.
I created a new scm/text.scm file for the definitions I couldn't put
elsewhere.
Bertrand
http://codereview.appspot.com/4553056/
___
lilypond-devel ma
On 2011/09/21 21:11:50, Neil Puttock wrote:
remove extra parens
Done.
Janek and Pal: thanks!
http://codereview.appspot.com/5030053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
New patch set.
I hope this is ready for to be pushed, now.
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely#newcode1636
Documentation/notation/input.itely:1636: @end lilypond
Yes, unfor
Hmm, I don't understand one comment, but I agree with the others.
Thanks,
Bertrand
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/inpu
New patch set including some documentation work.
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
On 2011/09/20 14:15:53, Ian Hulin (gmail) wrote:
"don't have to" == "don't need to", I assume you mean "you shouldn't"
> with tabulators in scripts/musicxml2ly.ly .
Yes, this was a subtle "DON'T DO IT!" :)
http://codereview.appspot.com/4974078/
_
On 2011/09/20 12:07:31, J_lowe wrote:
> Where do you think I should put it? In NR 1.8.1 or 1.8.2?
Hmm.. I'd say 3.3.3 actually
Oh, yes! This is better.
> Do you think I have to move the table from the regtest to the
Appendix A (and
> keep the rest of the regtest as a regtest)?
I am no
Thanks for applying these!
Sorry to bother you again with indentation, but you don't have to
replace spaces with tabulators in scripts/musicxml2ly.ly .
We decided that the rule for Python is 4 spaces per indentation level.
For more infos, see:
http://lilypond.org/~graham/gop/gop_1.html#GOP-1-_00
Hey!
I'm currently writing a doc entry that explains how to use replacements.
I have a few questions:
Where do you think I should put it? In NR 1.8.1 or 1.8.2?
Do you think I have to move the table from the regtest to the Appendix A
(and keep the rest of the regtest as a regtest)?
Bertrand
PS
Pushed as f9251331576c94fa6aa4b85776917d3774b13b63
http://codereview.appspot.com/4387046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Pushed as 2fff263f10fd542454455994aea5ff3bbe075c7d
http://codereview.appspot.com/4912041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi Ian,
I have some comments. The rest of the patch LGTM.
Regards,
Bertrand
http://codereview.appspot.com/4974078/diff/3001/scm/document-identifiers.scm
File scm/document-identifiers.scm (right):
http://codereview.appspot.com/4974078/diff/3001/scm/document-identifiers.scm#newcode31
scm/docume
On 2011/09/18 21:47:04, janek wrote:
I think LGTM, but it would be great if you'd add a regtest to
demonstrate what
this patch is fixing.
I don't think so. mensural-ligatures.ly contains every case fixed by
this patch.
If I make a regtest to show such tiny graphical differences, then we
would
Oh, yes. Thanks Werner, this is fixed.
http://codereview.appspot.com/5030053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Another update that fixes some variable errors.
It now passes make.
http://codereview.appspot.com/5030053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi Pal!
I updated the patch.
This wasn't working since Werner's e10a13.
It couldn't be applied to 0dcc93: I forgot some files that I added in
0e31cd.
Bertrand
http://codereview.appspot.com/5030053/
___
lilypond-devel mailing list
lilypond-devel@gnu.o
New patch set.
After thinking about that during three weeks, I decided to remove the
long tie and even reduce the length of the default tie. Janek, thank you
for showing me that overshooting vowels was useless and maybe
disturbing.
I also changed the "è" for a "e"...
Thanks,
Bertrand
http://co
Reviewers: benko.pal,
Message:
Hi,
The new mensural style introduced with commit
0dcc93c0a5a97d048db2f7631966f41ae0059ab5 created some ugliness's in
mensural ligatures.
This patch fix these. I also added serifs to flexas.
Regards,
Bertrand
Description:
Unifies mensural ligatures with blot-dia
Hi Joe,
At last, a fix for that!
But this looks unfinished. Are you working on a solution that would
avoid having to specify the X-extent?
A fix that calculates the font size of the ParenthesesItem according to
the Y-extent of the parenthesized grobs would also be awesome :)
Bertrand
http://c
Pushed as:
0dcc93c0a5a97d048db2f7631966f41ae0059ab5
and
0e31cd90e44673eca7ac59705ce4bed33dd8e80e
Thank you all for this review!
Bertrand
http://codereview.appspot.com/4639065/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.or
New patch set.
'&' and '@' have been added to the lexer.
'&' is therefore a perfectly working escape character in lyrics.
Bertrand
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mail
Ok Pal, I removed the left-stemmed longa.
I don't know where you could put these rules.
Maybe we should start a new doc part that references the established
engraving rules?
Bertrand
http://codereview.appspot.com/4639065/
___
lilypond-devel mailing li
Great. I removed the dynamics.
Is someone opposed to this patch to be pushed?
I suggest we put this issue in the next countdown.
Thanks,
Bertrand
http://codereview.appspot.com/4387046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://li
Thanks Janek.
Does someone else thinks the long tie should be removed?
Bertrand
http://codereview.appspot.com/4912041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
New patch set (inspired by Janek's ideas).
On 2011/09/14 21:05:28, benko.pal wrote:
> * Use the left-stemmed longa in ligatures.
exactly what is this last one?
When note_shape is MLP_LONGA and the direction of the stem is UP, then
the left-stemmed longa is used.
I know, this should be Mensu
On 2011/09/12 22:37:05, janek wrote:
i've looked at latest screenshot attached to tracker issue and... wow!
It looks
really great!
Thanks a lot :)
http://codereview.appspot.com/4639065/diff/13002/ly/engraver-init.ly#newcode1063
ly/engraver-init.ly:1063: \override Stem #'thickness = #2
I'd
On 2011/09/12 22:37:05, janek wrote:
i've looked at latest screenshot attached to tracker issue and... wow!
It looks
really great!
Thanks a lot :)
http://codereview.appspot.com/4639065/diff/13002/ly/engraver-init.ly#newcode1063
ly/engraver-init.ly:1063: \override Stem #'thickness = #2
I'd
LGTM, with the same comment.
http://codereview.appspot.com/4962072/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Thanks for your reviews!
On 2011/09/12 19:16:26, benko.pal wrote:
http://codereview.appspot.com/4639065/diff/13002/lily/mensural-ligature.cc#newcode147
lily/mensural-ligature.cc:147: Direction stem_dir = stem ?
get_grob_direction
(stem) : CENTER;
this is unneeded: there are no stemmed notes w
On 2011/09/12 21:35:03, janek wrote:
can you tell me what needs work in this patch? I've read Mike's
comments, but i
don't understand what should be done.
This patch contains many copy/paste from the arpeggio engraver. We
obviously need a new grob, since the braces need some special grob
par
LGTM.
Is there any way to also move \time, \key, \repeat and \alternative from
the parser?
Bertrand
http://codereview.appspot.com/4969076/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Hi everyone,
This patch is finally ready for review!
What has been done for Petrucci/mensural/neomensural:
* Stems centered around the attachment point.
* Attachment point lowered.
* Brevis/longa/maxima pointing downward.
* Use the left-stemmed longa in ligatures.
* A larg
Ok, DynamicText and DynamicLineSpanner should be removed.
But what about the others?
* Simple trill is directed (as a Script), so TrillSpanner logically has
to be directed.
* Slurs, Ties and TupletBrackets are also directed, so I don't see any
reason for LigatureBrackets to behave differently.
On 2011/09/06 08:54:40, janek wrote:
I'm not sure what you mean. Are you saying that i should assign (i *
(gap +
stemthick), 0) to a variable in the for loop? I.e. sth like
for i := 0 step 1 until linecount - 1:
foobar := (i * (gap + stemthick), 0);
Reviewers: J_lowe, dan_faithful.be,
Message:
I updated the patch and added a regtest.
Dan, I don't have time for now to rewrite the whole part combiner. Do
you want to do it ? If so, I can help you (at my level).
Bertrand
Description:
New partcombineUp and partcombineDown functions
Fix issue 1
This requires an update.
The patch fails to apply.
Bertrand
http://codereview.appspot.com/4917046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Updated.
Bertrand
http://codereview.appspot.com/4387046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Sorry, I forgot to send the comments.
http://codereview.appspot.com/4931043/diff/1/mf/feta-noteheads.mf
File mf/feta-noteheads.mf (right):
http://codereview.appspot.com/4931043/diff/1/mf/feta-noteheads.mf#newcode168
mf/feta-noteheads.mf:168: gap# := (0.95 - 0.008 * design_size) *
stemthick#;
Yo
Just a quick review.
Bertrand
http://codereview.appspot.com/4931043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2011/08/19 18:04:38, Carl wrote:
THanks for doing this!
And thanks for this excellent review!
I have some comments about the docs. I think they're too tutorial,
and I think
the exhaustive lists are unwieldy and should be eliminated. THe
source should
be the reference.
You're right.
Reviewers: ,
Message:
Hi,
Graham asked me to document an small issue.
(http://codereview.appspot.com/4875054/)
And this became something bigger.
He also told me to push it directly, but I made a few changes in the
interface as I read the code and wrote the doc.
So the review concerns only the C
(Two minor comments however).
http://codereview.appspot.com/4875054/diff/1/lily/auto-beam-engraver.cc
File lily/auto-beam-engraver.cc (right):
http://codereview.appspot.com/4875054/diff/1/lily/auto-beam-engraver.cc#newcode172
lily/auto-beam-engraver.cc:172: return !scm_is_false (scm_call_4
(get
LGTM :)
Bertrand
http://codereview.appspot.com/4875054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Hi everyone,
This follows 8d148ea05fa4b34f8cc3407e112363d715b27ad8
This is fully working, except for a small issue in make doc.
The two examples I put in the doc are working alone, but not with make
doc:
there should be short ties in "~è~", but we mysteriously get medium
t
That wasn't working 'cause I forgot to add some files to git...
This is now fixed.
Bertrand
http://codereview.appspot.com/4807053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Same remark for fingerings.
See input/regression/fingering-cross-staff.ly
Consecutive ties look better in input/regression/tie-single.ly
http://codereview.appspot.com/4898044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.or
Benchmark done on a book with many beams:
without the patch: 51.8s and 80 pages
with the patch: 52.2s and 83 pages
I also noticed some ugliness's between beams and figured bass. The
figures stay exactly where they were, but the stems are longer and
collide a bit with them.
Bertrand
http://coder
Pushed as 8d148ea05fa4b34f8cc3407e112363d715b27ad8
Bertrand
http://codereview.appspot.com/4808074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
use separate binding for (/ word-space 2)
Done.
http://codereview.appspot.com/4808074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Here's how a better solution should work:
* create a smaller tie in addition to this one
* use a scm regexp to find this special case; something like:
#(use-modules (ice-9 regex))
#(display (regexp-substitute #f (string-match "([^:])~([^:])~([^:])"
"questa~è~in")
'pre 1 " " 2 " " 3 'post))
But I
Reviewers: ,
Message:
figuredBassCenterContinuations fails to merge continuation lines on if a
figure is composed of three or more figures.
This tiny patch fixes that.
Bertrand
Description:
Fixes figuredBassCenterContinuations.
Please review this at http://codereview.appspot.com/4868046/
Aff
I forgot these cases (o~è~in; a~è~in; o~è~an...). They are often elided
("quest'in" instead of "questa~è~in") by editors and composers.
So your view is that lyric ties are not used in the real world? I
still feel them as a pedagogy resource for young musicians or
something. Or maybe old score
Secondly, it does not follow the policy for syllable separator, which
is '[space]--[space]', not '-[space]'.
I already fixed it in this patch (for every language).
Finally, 2nd and 3rd stanzas look _very_ improbable to me in that it
has three syllables on a single note, which requires two lyri
This needs an update to be applied.
Cheers,
Bertrand
http://codereview.appspot.com/4813048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM (still one trailing whitespace in the regtest).
Bertrand
http://codereview.appspot.com/4841052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
What if we want a larger padding?
In your regtest, the clef collides with the third notehead when we set
the padding with:
\override Score.SpacingSpanner #'left-loose-column-padding = #2
There's also two trailing whitespaces.
Regards,
Bertrand
http://codereview.appspot.com/4841052/diff/6001/in
So do I, but a shorter tie would collide with commas. The best solution
is probably to shorten the tie and lower it according to the Y-extent of
the covered letters. But this requires much more work.
Maybe having two sizes of lyric ties would also be a good idea: a short
one and the default one.
Changes done.
Passes make, regtest comparison and make doc.
Bertrand
http://codereview.appspot.com/4808074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Better handling of lyric ties:
* The space between two tied words is no more fixed. Its value is
word-space. The default space is therefore decreased.
* New glyph, so that we won't need an external font.
* Increased vertical space between words and tie. It is therefore now
p
Hi,
I think I found a proper way to calculate church rests.
I also updated so that it applies on the latest git HEAD.
Bertrand.
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailma
lily/text-interface.cc updated.
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
This should work now.
http://codereview.appspot.com/4807053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Ouch...
The problem with '&' is that it fails on lyrics:
this works:
\new Lyrics \lyricmode { a&s; }
but this doesn't:
\new Lyrics \lyricmode { &s; }
There is the same kind of issues with almost every easy-to-type special
character:
@ % $ # \ / < > ^ ~ + = * ; ( ) [ ] { }
This is the exact lis
I updated the patch.
There's now a list of special characters and a \replace command for
markups.
The escape character is now '§'. It's the only one that works great
with lyrics. And it isn't used elsewhere in LilyPond's syntax.
The syntax for using the list of special characters
#(include-sp
Hi Pál (besides, are you Pál Benkő the chess master?)
Thanks for this nice review.
1. about the very existence of usable-duration-logs -
ok, it's generic, but who uses this genericity?
is it not always (0 -1 -2 -3)?
is it not always a range with lower end -3?
is it not always a
I updated the patch to work on the latest git HEAD.
After doing a clean regtest comparison (git clean -fxd, config, make,
make test-baseline, make check), I don't see anything.
The logs' names show this is due to Mike's last commits.
Regards,
Bertrand
http://codereview.appspot.com/4807053/
___
It doesn't need to be ordered.
It can have holes, but there's a small issue with this for now:
Church rests are only looking for maximum and minimum values. You can
therefore find longas in a church rest if you set usable-duration-logs
to '(0 -1 -3).
I don't know whether it's better to keep this s
> I should have write "2 << (-i + 1)" instead of "/2"...
the +1 multiplies by 2, not divides.
Whoops, I meant -(i + 1)...
perhaps the best would be 1 << -i.
Thanks.
When I told you I never understood "<<", I wasn't kidding!
An update will follow this comment.
Bertrand
http://codereview.
http://codereview.appspot.com/4536068/diff/37002/lily/multi-measure-rest.cc#newcode241
lily/multi-measure-rest.cc:241: length = (2 << -i) / 2;
The division by 2 changes the result. Not that I understand too well
what it is
supposed to be doing.
To be honest, I never understood well how this
Reviewers: ,
Message:
Hi!
This patchs allows to add braces the same way as arpeggios.
Very useful for complex organ music.
Check this out, there is several examples:
http://imslp.org/wiki/12_Pi%C3%A8ces_pour_Orgue_(Gigout,_Eug%C3%A8ne)
For the moment, the new engraver is a clone of Arpeggio_eng
1 - 100 of 166 matches
Mail list logo
