Re: Updated patch for issue 155 (issue 230860044 by carl.d.soren...@gmail.com)
On 2015/04/19 19:32:29, Keith wrote: LGTM. The main difference is the change in handling pure functions. I can't see any difference here relative to Joe's patch, but it looks fine. When Joe's patch was written, we had a scheme procedure that turned impure functions pure, based on an alist. That is now removed from LilyPond, so there is no place that uses pure-y-extent. Thanks, Carl https://codereview.appspot.com/230860044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Set CFLAGS and LDFLAGS to build python modules (issue 227850044 by truer...@gmail.com)
author Masamichi Hosoda truer...@sea.plala.or.jp Tue, 21 Apr 2015 19:11:40 + (20:11 +0100) committer James Lowe pkx1...@gmail.com Tue, 21 Apr 2015 19:12:13 + (20:12 +0100) commit 2eb22fd223cd56a2dd90eda1499dadbcbfa5fad5 Thank you Hosoda-san James https://codereview.appspot.com/227850044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Set CFLAGS and LDFLAGS to build python modules (issue 227850044 by truer...@gmail.com)
Patch counted down - please push https://codereview.appspot.com/227850044/ I don't have git account. I've attached the patch file to this mail. Would you push it? From 9a4757685fa0e877cc1e970915376de8a550a569 Mon Sep 17 00:00:00 2001 From: Masamichi Hosoda truer...@trueroad.jp Date: Wed, 15 Apr 2015 22:36:23 +0900 Subject: [PATCH] Set CFLAGS and LDFLAGS to build python modules --- aclocal.m4 | 2 ++ config.make.in | 2 ++ python/GNUmakefile | 3 ++- 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/aclocal.m4 b/aclocal.m4 index 74cf3bc..7ed3151 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -1128,6 +1128,8 @@ AC_DEFUN(STEPMAKE_PYTHON_DEVEL, [ warn=Python.h (python-devel, python-dev or libpython-dev package) STEPMAKE_ADD_ENTRY($1, $warn) fi +AC_SUBST(PYTHON_CFLAGS) +AC_SUBST(PYTHON_LDFLAGS) ]) diff --git a/config.make.in b/config.make.in index 9837fc3..c3fd6d7 100644 --- a/config.make.in +++ b/config.make.in @@ -14,6 +14,7 @@ package-depth = @package_depth@ FREETYPE2_CFLAGS = @FREETYPE2_CFLAGS@ GUILE_CFLAGS = @GUILE_CFLAGS@ PANGO_FT2_CFLAGS = @PANGO_FT2_CFLAGS@ +PYTHON_CFLAGS = @PYTHON_CFLAGS@ CONFIG_CPPFLAGS = @CPPFLAGS@ CONFIG_DEFINES = @DEFINES@ @@ -25,6 +26,7 @@ FONTCONFIG_LIBS = @FONTCONFIG_LIBS@ GUILE_LIBS = @GUILE_LDFLAGS@ FREETYPE2_LIBS = @FREETYPE2_LIBS@ PANGO_FT2_LIBS = @PANGO_FT2_LIBS@ +PYTHON_LIBS = @PYTHON_LDFLAGS@ CXXABI_LIBS = @CXXABI_LIBS@ CONFIG_LIBS = @LIBS@ @EXTRA_LIBS@ $(GUILE_LIBS) $(PANGO_FT2_LIBS) $(FONTCONFIG_LIBS) $(FREETYPE2_LIBS) diff --git a/python/GNUmakefile b/python/GNUmakefile index 87fa766..19af006 100644 --- a/python/GNUmakefile +++ b/python/GNUmakefile @@ -6,7 +6,8 @@ STEPMAKE_TEMPLATES=c python-module install-out po include $(depth)/make/stepmake.make -CFLAGS += -DPy_BUILD_CORE -Wall +CFLAGS += -DPy_BUILD_CORE -Wall $(PYTHON_CFLAGS) +LDFLAGS += $(PYTHON_LIBS) # unset al guile stuff from configure CONFIG_LDFLAGS= -- 2.1.4 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replace C++ (in)equality checks with proper SCM syntax (issue 226840043 by v.villen...@gmail.com)
Patch counted down - please push https://codereview.appspot.com/226840043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove cygwin_conv_to_posix_path (issue 227200043 by truer...@gmail.com)
I'm leaving this patch on review as it is not clear to me if there needs anything more done to it. Patch on countdown for April 24th https://codereview.appspot.com/227200043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Set CFLAGS and LDFLAGS to build python modules (issue 227850044 by truer...@gmail.com)
Patch counted down - please push https://codereview.appspot.com/227850044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown for April 24th 2015
Hello, Here is the current patch countdown list. The next countdown will be on April 24th. 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 PUSH: James Lowe: Patch: Set CFLAGS and LDFLAGS to build python modules http://code.google.com/p/lilypond/issues/detail?id=4347 Valentin Villenave: Patch: Replace C++ (in)equality checks with proper SCM syntax http://code.google.com/p/lilypond/issues/detail?id=4342 Valentin Villenave: modifying default behaviour of tremolo slashes http://code.google.com/p/lilypond/issues/detail?id=1735 Carl Sorensen: \parenthesize does not take accidentals into account http://code.google.com/p/lilypond/issues/detail?id=155 COUNTDOWN: Trevor Daniels: Clarify where changes to beatStructure and baseMoment should be placed http://code.google.com/p/lilypond/issues/detail?id=4349 Dan Eble: Patch: Part combiner: move direction handling out of iterator http://code.google.com/p/lilypond/issues/detail?id=4348 James Lowe: Patch: Remove cygwin_conv_to_posix_path http://code.google.com/p/lilypond/issues/detail?id=4346 Trevor Daniels: Avoid macro at top-level in ly/satb.ly http://code.google.com/p/lilypond/issues/detail?id=3799 Valentin Villenave: Attach lilypond source in pdf http://code.google.com/p/lilypond/issues/detail?id=2643 REVIEW: David Kastrup: Patch: Rename Translator_void_method_ptr to Translator::Callback http://code.google.com/p/lilypond/issues/detail?id=4351 NEW: James Lowe: Doc: NR section 3.5.x MIDI file creation tidy up http://code.google.com/p/lilypond/issues/detail?id=2877 WAITING: Urs Liska: Patch: Issue 3916: Add \alternatingTimeSignatures http://code.google.com/p/lilypond/issues/detail?id=3918 Mike Solomon: Patch: Prevents vertical axis groups with empty skylines http://code.google.com/p/lilypond/issues/detail?id=3156 Mike Solomon: Patch: Removes the translate_axis call from axis-group-interface outside-staff positioning. http://code.google.com/p/lilypond/issues/detail?id=3134 David Kastrup: Patch: Implement music functions in Scheme rather than C++ http://code.google.com/p/lilypond/issues/detail?id=2716 Thank you, James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR section 3.5.x MIDI file creation tidy up (issue 120480043 by pkx1...@gmail.com)
On 2015/04/20 16:31:52, J_lowe wrote: https://codereview.appspot.com/120480043/diff/240001/Documentation/notation/input.itely#newcode2732 Documentation/notation/input.itely:2732: accent, marcato and portato. On 2014/12/28 23:40:29, Trevor Daniels wrote: We need a proper list here showing clearly what is supported, so users new to midi output can see at the outset what it can do for them. The basic facilities can then be compared with the enhancements provided by the articulate script to see if that is going to be useful. Not all users use articulate.ly, so the point was to list that what is 'not supported without articulate.ly' in the section that has nothing to do with articulate.ly and to list that which 'is supported with the articulate script' IN the articulate script where *already* seemed to be documenting this kind of thing in the first place. If these lists are all wanted in one place then fine - pick a place - but at least it has to be clear of which features won't appear in your MIDI output if you don't use articulate.ly and then that either means you list that all at the beginning or the end (where we have the articulate script information located). Also there seemed to be a 'want' to list what does work which I cannot understand; as my personal preference for 'lists' like this is that assume it ALL works unless it is listed that it does not work. Listing things that both do and don't work again seemed overkill and what if something isn't listed? Does it work, or doesn't it? This last para seems to be the nub of our disagreement. I strongly believe we should list the supported features and you want to list the unsupported ones. I should explain why I hold this view. There are two main reasons: 1. This is a Reference manual. It is intended to show what LP can do and how to do it. That is, it has a positive view: what can be done, not what cannot be done. This is apparent from the way the contents list is laid out, and the way the rest of the document is written, but let me give just a couple of examples: a) In 1.1.1 under Note names in other languages it says: The available languages and the note names they define are: and then goes on to list them. It does not list what languages are not supported. b) In 1.2.1 under Durations it says: Durations as short as 128th notes may be specified. Shorter values are possible, but only as beamed notes. A positive, not a negative statement. You can find similar lists of what is supported in many other places, and AFAICS, none that list what is not supported. Try glancing at the Appendices. 2. MIDI is a complex and extensible standard. LP, even with articulate.ly, supports only a fraction of the possibilities. So it is simply misleading to let the user believe LP supports everything that is not listed, unless you are going to have a very long list. Have a look at https://en.wikipedia.org/wiki/MIDI to see what this would entail. Look at the range of controllers, sequencers and synthesizers; look at system exclusive messages and MIDI extensions. OK, so what am I asking for? Simply a list of MIDI features supported by basic LP, and a list of additional features supported when articulate.ly is included. That's all. The two lists exist already. They're in 3.5.2 under Supported in MIDI. The lists need to be updated, but I can do that later. Where should it go? As close to the beginning of the MIDI section as is sensible. Without your revised section ordering immediately to hand I'll have to leave you to decide that. If you still can't accept this, we'll have to wait until some other developers chip in with their view. Other than that, LGTM, and thanks for working so persistently with this! Trevor https://codereview.appspot.com/120480043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3799: New satb.ly built-in template and template framework (issue 225860043 by tdanielsmu...@googlemail.com)
On 2015/04/17 21:03:18, Trevor Daniels wrote: Patch set 2 contains a number of code improvements as well as four regression tests and a (minimal) change to the documentation. The main changes from patch set 1 are: - There is now a distinction between Women/Men music variables in their own right and WomenDivided/MenDivided variables which are used when modifying the instrument names and midi instruments associated with the two-voice staves. Is Women/Men the correct nomenclature or would it rather be female/male [voice types]? As an alto I'd prefer the least sexist designation as long as it matches typical usage. https://codereview.appspot.com/225860043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR section 3.5.x MIDI file creation tidy up (issue 120480043 by pkx1...@gmail.com)
On 4/21/15 4:06 PM, tdanielsmu...@googlemail.com tdanielsmu...@googlemail.com wrote: If you still can't accept this, we'll have to wait until some other developers chip in with their view. I agree that we should list what is supported, with the idea that anything not mentioned is not supported. We should list what is supported by LilyPond, and then additional items that are supported by LilyPond + articulate.ly. Maybe it could be one table, with a column indicating whether it is native lilypond, or lilypond + articulate.ly. That way the user wouldn't need to vist two places to see what is possible. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
\change Voice
Would it be hard to make \change Voice work as below without relying on the
extra “X” context?
—
Dan
\version 2.19.17
\layout {
\context {
\name X
\type Engraver_group
}
\context {
\Voice
\accepts X
\defaultchild X
}
}
\new Staff
\context Voice = one \with { \voiceOneStyle } {
f'2 \change Voice = two f'2
}
\context Voice = two \with { \voiceTwoStyle } {
s1
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updated patch for issue 155 (issue 230860044 by carl.d.soren...@gmail.com)
https://codereview.appspot.com/230860044/diff/20001/input/regression/parenthesize-notes-accidentals.ly File input/regression/parenthesize-notes-accidentals.ly (right): https://codereview.appspot.com/230860044/diff/20001/input/regression/parenthesize-notes-accidentals.ly#newcode10 input/regression/parenthesize-notes-accidentals.ly:10: \parenthesize ais'4. \parenthesize bes' These parentheses overlap, which seems to be an accepted behavior of the parentheses, but it will make us look twice every time we check the regression tests. Maybe just boost the bes' up a bit. And you could just modify 'parenthesize.ly' to have an accidental and a dot, so there is one fewer test to check. https://codereview.appspot.com/230860044/diff/20001/scm/define-grobs.scm File scm/define-grobs.scm (right): https://codereview.appspot.com/230860044/diff/20001/scm/define-grobs.scm#newcode1736 scm/define-grobs.scm:1736: (X-extent . (0 . 0)) It looks like parentheses don't get horizontal space, so there seems to be no need for a pure-height. https://codereview.appspot.com/230860044/diff/20001/scm/output-lib.scm File scm/output-lib.scm (right): https://codereview.appspot.com/230860044/diff/20001/scm/output-lib.scm#newcode908 scm/output-lib.scm:908: (define-public (parentheses-item::pure-y-extent grob start end) On 2015/04/21 18:46:38, Carl wrote: On 2015/04/19 19:32:29, Keith wrote: The only need I could see for pure-y-extent here, would be to estimate horizontal space for the parentheses around an accent outside a slur or beam. So is it best to remove the code, since we don't have a regtest that exercises it? I agree, we should not add an unused function. https://codereview.appspot.com/230860044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3799: New satb.ly built-in template and template framework (issue 225860043 by tdanielsmu...@googlemail.com)
On 2015/04/21 19:58:34, dak wrote: Is Women/Men the correct nomenclature or would it rather be female/male [voice types]? As an alto I'd prefer the least sexist designation as long as it matches typical usage. Men is commonly seen in vocal scores, certainly in Oxford and Novello publications. Women is used rarely, but I have examples in an Oxford publication. Usually a change to the S/A line is written as S/A Unis or similar above the staff, and the staff is left unnamed. This can be done easily by a user of the template if that is desired. I've never seen female/male used, so I'd prefer to keep the names unchanged. Trevor https://codereview.appspot.com/225860043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
