You might search through the issues list for issues with the label "Frog".
Those are intended to be tasks that those with only limited LilyPond
development experience can tackle.
:o) What a wonderful organization ! And GOP hasn't started yet !
I'll do my best on these issues !
BTW, I have che
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
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
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
Pushed as 2fff263f10fd542454455994aea5ff3bbe075c7d
http://codereview.appspot.com/4912041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Pushed as f9251331576c94fa6aa4b85776917d3774b13b63
http://codereview.appspot.com/4387046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
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
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
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/
_
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
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
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
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
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
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
Pushed as 829f0ded77ee44ea6f0566fb5e5318802a8857ad.
http://codereview.appspot.com/5030053/
___
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 688f5f1711d8ca07338385a2ae0191b1a8aae315.
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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,
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
Pushed as bb7cac7b276bd7d1335523f3be8df815cf894ece.
http://codereview.appspot.com/4514042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
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
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
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
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/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,
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
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
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
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
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
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.
http://codereview.appspot.com/5306050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
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/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") !=
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
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
"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
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
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.
http://codereview.appspot.com/5504091/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
Update on http://code.google.com/p/lilypond/issues/detail?id=1517
http://codereview.appspot.com/4172047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Yes, sorry...
I made a new codereview issue : http://codereview.appspot.com/4182056/
...(currently reading the Contributor's Guide again)...
http://codereview.appspot.com/4172047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gn
Reviewers: carl.d.sorensen_gmail.com,
Message:
A few questions.
http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm#newcode994
scm/define-markup-comm
Changes done !
It is more clean now.
I'm not sure if the commands are in the right categories.
I also noticed numerous commands have @code instead of @var and vice
versa in their descriptions. Center-align's args or fill-line's
line-width for example.
Should I do a small patch to fix these ?
Reg
Maybe add \pattern to the changelog ?
http://codereview.appspot.com/4182056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
I added a "dir" argument to \pattern, so that we can get vertical
repeats.
Also made a changelog item.
Bertrand
http://codereview.appspot.com/4182056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypon
Wow, nice job Mike !
I am also currently trying to solve this issue.
With Scheme only I managed to do a good solution for endnotes.
I have some suggestions for your work :
* There should be more space between separator line and footnotes.
* Maybe a smaller separator, like LaTeX does. line-width /
I meant : we can't use this to do a footnote when in a markup or
markuplines.
Something like :
\markuplines { bla bla bla \footnote { Oh yes ? } bla bla bla }
I know lilypond-book is the best solution for this issue. But it would
be easier if LilyPond had a native support of these features.
http
:p
Great job !
There's no word to thank you enough !
Thanks thanks thanks,
Bertrand
http://codereview.appspot.com/4167063/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
New patch here : http://codereview.appspot.com/4213042
http://codereview.appspot.com/4167063/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
New patch with Neil's changes.
http://codereview.appspot.com/4182056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi Mike,
Nice job, as usual !
However, I noticed some obvious problems. You probably already know
them.
Here, the padding :
\markup {
\footnote b c
\footnote e f
}
Here, the horizontal space between markup and number :
\markup {
\footnote d e
\footnote f g
}
Also : why are in-text num
http://codereview.appspot.com/4237059/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
http://codereview.appspot.com/4237059/diff/1/scm/define-markup-commands.scm#newcode159
scm/define-markup-commands.scm:159: (markup #:fill-line
I suggest you move this fill-lin
There is still a vertical spacing bug in the footnotes :
\markup {
\footnote e e
\footnote e ef
}
There should be a fixed distance between the baseline and the number.
For the thin space, I meant in-text words and numbers :
Cromorne ²
Which is more elegant than :
Cromorne ²
or
Cromorne²
Rega
Of course, I agree that we should get rid of the two-pass algorithm. But
it's really tricky to do it the clean way :o\
As the issues I pointed out need deep changes, I think the two-pass
algorithm is better than nothing.
For the moment, we can also avoid these issues by displaying footnotes
anot
Reviewers: ,
Message:
Small patch that takes new grobs in account :
Accidental suggestions, dynamics, ligatures and spanned trills.
Regards,
Bertrand
Description:
Add some polyphonically directed grobs
Accidental suggestions, dynamics, ligatures and spanned trills added to
direction-polyphonic
Reviewers: ,
Message:
A few nitpicks.
Description:
Autobeam nitpicks (following Carl's fix).
Please review this at http://codereview.appspot.com/4385050/
Affected files:
M scm/time-signature-settings.scm
Index: scm/time-signature-settings.scm
diff --git a/scm/time-signature-settings.scm
Ok. But you agree with the other grobs ?
http://codereview.appspot.com/4387046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
This fixes issue 1605. Keith's patch takes the "\" bug into account. But
this bug also occures with simple markups, so I assume this hasn't to be
fixed.
Description:
Fix issue 1605
PDF metadata for titles now handle unclosed parentheses.
Please review this at http://coder
I made another patch here :
http://codereview.appspot.com/4377054/
http://codereview.appspot.com/4382052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Mistake : this produces the right output when we have title = "\a", but
PDF metadata is wrong and only shows "a". I'll include \\ in my next
update of the patch.
http://codereview.appspot.com/4377054/
___
lilypond-devel mailing list
lilypond-devel@gnu.
Done. I don't know if this is the correct place for ps-quote.
http://codereview.appspot.com/4377054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Besides, I noticed two special markups :
\markup "\n" and \markup "\t"
What is their use ? I know \n stands for UNIX carriage return and \t
stands for tab.
But here...
By the way, this doesn't cause any problem with metadata.
http://codereview.appspot.com/4377054/
___
How ? output-ps is dependant of framework-ps... When I move it to
output-ps, it doesn't work.
Thanks !
Bertrand
http://codereview.appspot.com/4377054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypon
I added a line to the test. And I don't think we need to do something
about newlines.
http://codereview.appspot.com/4377054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: carl.d.sorensen_gmail.com,
Message:
Thanks for the review !
Patch updated.
I don't know if there's a better way to solve this issue.
As big braces look good, I decided to limit the changes to the smallest
ones.
Description:
Fattens the 256 first braces.
Please review this at http://c
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf
File mf/feta-braces.mf (right):
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf#newcode150
mf/feta-braces.mf:150: save fatten;
That's what I thought at first. Then I saw "save number;" line 129, so I
decided to p
I don't know if this is a joke, so I answer to David's question :
of course there is no jump between the 256th and the 257th !
Refer to this message to see before/after :
http://lists.gnu.org/archive/html/lilypond-devel/2011-05/msg00150.html
http://codereview.appspot.com/4518052/
___
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf
File mf/feta-braces.mf (right):
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf#newcode151
mf/feta-braces.mf:151: fatten := 1 + fatten_factor - min ( number *
fatten_factor / 256, fatten_factor);
Thanks !
Hum...
:)
Thanks ! This works great. Updated.
http://codereview.appspot.com/4518052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Longas are now handled in multi-measure rests.
Regards,
Bertrand
Description:
Handles longa in MultiMeasureRest
Please review this at http://codereview.appspot.com/4543055/
Affected files:
M lily/multi-measure-rest-engraver.cc
M lily/multi-measure-rest.cc
M scm/def
I was also wondering : shall we add another exception for half rests ?
I always found this disturbing to have a whole rest in 2/4.
I know this is what traditional editors do, but...
If we do so, then it would be better and cleaner to make an alist of
durations instead of this mess.
And add a use
I know these rules. They will always be LilyPond's default behavior.
What I meant is "if someone want to change this (for contemporary music
or anything else), it doesn't have to be difficult to do".
If we want to create a non-standard capability, it would seem to me
that the
user-settable pr
Ok, I worked hard on this and did a brand new patch :
http://codereview.appspot.com/4536068/
http://codereview.appspot.com/4543055/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Just one regtest change :
in multi-measure-rest.ly, the two longas of the third measure are
tranformed into a maxima (as expected).
Regards,
Bertrand
Description:
Adds longas, maximas and non-standard tweaks to MultiMeasureRest
Please review this at http://codereview.apps
This name is nice and generic, which is good. Bit it has no
information content
as far as I can see. Can we make it more explicit by changing either
the name
(to something like usable-duration-logs) or the description (to
something like
"List of duration-logs that can be used in typesettin
I applied it to the more recent git HEAD without any problem.
By maxima, I mean the glyph "rests.M3".
I chose to use maximas because they are easier to read than two longas
with many space in between.
In such cases, this is mandatory :
{ \compressFullBarRests \time 4/1 R\longa*10 }
http://coder
Sorry, I misread your first sentence. Forget the first line of my
previous post.
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
A feature that helps text typesetting.
Bertrand
Description:
New alist to replace special characters.
Please review this at http://codereview.appspot.com/4553056/
Affected files:
A input/regression/markup-special-characters-shorthands.ly
M lily/text-interface.cc
M
This prints every character with its shorthand, but works bad because of
'\t', '\v' and '\n' :
\version "2.15.0"
\include "special-characters.ly"
#(define-markup-list-command (show-special-characters layout props) ()
(interpret-markup-list layout props
(1) You can do it using \override #'(replacement-string-max-length . 0)
But I agree, there's a problem with backslashes.
(2) What if we define something like "\tz" when we want 'ꜩ' and just
write "tz" when no ligature is needed ? This isn' t so constraining.
(3) I know, this is another change
Response to Reinhold and Carl's concerns.
http://codereview.appspot.com/4553056/diff/1/lily/text-interface.cc
File lily/text-interface.cc (right):
http://codereview.appspot.com/4553056/diff/1/lily/text-interface.cc#newcode40
lily/text-interface.cc:40: int max_length = scm_to_int
(ly_chain_assoc
Yes.
Knowing this, I suggest we keep whitespaces, punctuation, quotes and
word dividers (with some small changes).
There's still something that bothers me : isn't there some special
characters that you can't do with you keyboard ?
Even on linux I can't type some symbols like ſ or • without
copyin
...definitely not user-friendly!
I totally agree it's better to type in UTF and that's what I always did
with LilyPond. But this REALLY wastes time when we type several symbols
and ligatures.
Making this easier should be the OS's job.
I'll think more about this and make another patch set.
Bertran
Nitpicks done :
"duration-log-list" changed for "usable-duration-logs" (Thanks Carl !)
Whitespaces and tabs removed.
Bertrand
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/l
longest-church-rest is the longest rest displayed in church rests.
One may want to only print a whole rest in a breve measure but print
breve and longa rests in a church rest.
But I agree with you, it can be changed for the min value of
usable-duration-logs.
You're right for measure-duration-log.
Carl's suggestions done !
Bertrand
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Thanks, 'tis done.
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
New patch set with Carl's ideas.
I don't know if replacement-alist should be defined by default.
Nor if '&' is a good escape character. I chose it because it's quicker
to type on a french keyboard than '@'.
Bertrand.
http://codereview.appspot.com/4553056/
___
Ok, I'll change these. What about 'No.' ? '№', 'N°' or '&N°;' ?
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
If I understand well, there's no need anymore for manual beams in
cross-staff cases ?
If so, I suggest you remove the manual beams from
input/regression/beam-collision-cross-staff.ly.
You should also remove the knownissues in keyboard.itely and the last
part of changes.tely's entry.
Thanks,
Bertr
Thanks again, Neil !
I applied these.
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Done !
Regression tests are ok.
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/9003/input/regression/markup-special-characters.ly
File input/regression/markup-special-characters.ly (right):
http://codereview.appspot.com/4553056/diff/9003/input/regression/markup-special-characters.ly#newcode7
input/regression/markup-special-charact
Yes, thanks. 'Tis done.
Bertrand
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
1 - 100 of 166 matches
Mail list logo
