Re: Part combiner: separate split state and voice names
Keith OHara k-ohara5...@oco.net writes:
Urs Liska ul at openlilylib.org writes:
Keith wrote:
I suggest looking over the existing partcombine bugs, and orchestral
scores, to see what problems generally need solving.
If there's anything I can do to help (without understanding more than
basic Scheme and without any option to help on the C++ part) please let
me know. Maybe it helps that I'm currently working on a big orchestral
score?
I remember that you were once trying to define \new Voices in the music
you gave to \partcombine (but it seems you decided you did not need to) :
http://lists.gnu.org/archive/html/lilypond-user/2014-10/msg00509.html
This doesn't work because \partcombine rearranges the music into Voices
that it defines, with names one two shared solo. With the color
coding below, you can see that LilyPond's layout receives notes in four
distinct voices from \partcombine.
soprano = { d''2 f'' g'' a'' g''4 e''~e''2 R1 e''1}
alto = { b'2. c''4 c''2( e'') R1 f''4 d''~d''2 c''1}
\new Staff
\context Voice = one { \override NoteHead #'color = #red }
\context Voice = two { \override NoteHead #'color = #green }
\context Voice = shared {\override NoteHead #'color = #blue }
\context Voice = solo {\override NoteHead #'color = #grey }
\partcombine \soprano \alto
Dan has for a long time wanted to be able to control which voices get
which notes, while still having \partcombine do the tedious work of
finding where the parts can be joined into chords, figuring rests,
etc.
Well, in the category dumb tricks with context definitions we can
crank out the following:
soprano = { d''2 f'' g'' a'' g''4 e''~e''2 R1 e''1}
alto = { b'2. c''4 c''2( e'') R1 f''4 d''~d''2 c''1}
\new Staff
\context Voice = one {
\context VoiceAlias = shared { }
\override Voice.NoteHead #'color = #red
}
\context Voice = two { \override NoteHead #'color = #green }
\context Voice = solo {\override NoteHead #'color = #grey }
\partcombine \soprano \alto
\layout {
\context {
\Voice
\accepts VoiceAlias
}
\context {
\name VoiceAlias
\alias Voice
\type Engraver_group
}
}
Something like this might also help for defining the main voice in
\\ split voices.
But it does beg the question whether these kinds of trick are not an
indication that we are lacking some better interfaces. Something like
\partcombine \with { one = solo } ...
would of course be feasible but that does not buy us an input strategy
for \\ yet.
At any way, this particular trick requires issue 3225 (version 2.17.14
or later) to work.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown for December 5th 2014
Hello, Here is the current patch countdown list. The next countdown will be on December 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 PUSH: Dan Eble: Part combiner shifts or omits rests http://code.google.com/p/lilypond/issues/detail?id=4205 COUNTDOWN: David Kastrup: Patch: Reorder \language english to prefer abbreviations http://code.google.com/p/lilypond/issues/detail?id=4210 David Kastrup: Patch: Change notename csharp et al. to c-sharp et al. http://code.google.com/p/lilypond/issues/detail?id=4209 David Kastrup: Patch: Various Emacs mode tweaks: http://code.google.com/p/lilypond/issues/detail?id=4208 Keith OHara: Give compressed multi-measure rests more space http://code.google.com/p/lilypond/issues/detail?id=4197 Keith OHara: \partcombineSolo truncates an immediately-preceeding solo sequence http://code.google.com/p/lilypond/issues/detail?id=4061 REVIEW: Dan Eble: Patch: Add an alternative quarter rest shaped like a mirrored Z. http://code.google.com/p/lilypond/issues/detail?id=4211 Dan Eble: Patch: Convert ly::time-signature::print from C++ to Scheme. http://code.google.com/p/lilypond/issues/detail?id=4204 Keith OHara: allow bn for B-natural in English http://code.google.com/p/lilypond/issues/detail?id=4076 David Kastrup: Chord repeats should not repeat forced/cautionary accidentals http://code.google.com/p/lilypond/issues/detail?id=4010 James Lowe: articulate.ly: documentation issues and incorrect rendering of grace notes http://code.google.com/p/lilypond/issues/detail?id=2877 WAITING: Urs Liska: Patch: Add original-breaks.ly commands http://code.google.com/p/lilypond/issues/detail?id=4155 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
How to *hide* a page from the website (and manuals)?
Hi folks, I just stumbled over http://lists.gnu.org/archive/html/lilypond-devel/2013-12/msg00187.html and http://lilypond.org/website/gsoc-2012.html I think my first sentence in the thread starter is even more true today. I thought we could *hide* that GSoC 2012 page from the website instead of completely removing it (making it easier to create something new someday). Any opinions? And how would one hide a page instead of deleting it? In any case, I think we can't leave it online in its current state. Best Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB and mpfr/mpc
I changed mingw.org's mingw-runtime to mingw-64 (32-bit). Then an error didn't occur and correct test.pdf was generated. https://github.com/trueroad/gub/tree/binutils-2.24 I may pull request if you request it. Further, even if the runtime is mingw-w64, bad_alloc occurred when optimization was turned on. For both of bad_alloc prevented and optimization, I tried the following setting. Only one file (lily/skyline.cc) optimization is disabled and all other files optimization is enabled. Do you have a backtrace that might give us some more clue about where lily/skyline.cc has a problem? I thought that I had at one time proposed something to be changed (as part of some issue?) order to deal with possible memory corruption, but a quick look through the log messages does not turn up either a commit from me or a commit message ringing a bell. I turned off optimization to get correct backtrace, but bad_alloc didn't occur. Therefore I could get only incomplete backtrace. It seems that push_back in Skyline::internal_merge_skyline throws bad_alloc. I think the problem is Skyline::internal_merge_skyline and/or first_intersection. Skyline::internal_merge_skyline has a while loop with push_back. I think that the loop termination condition may break by optimization. So, I tried to disable optimization only not one file whole, but one function. In the case of Skyline::internal_merge_skyline, the result was bad_alloc. In the case of first_intersection, the result was that correct PDF was generated. The source tree when succeeding, is as follows. https://github.com/trueroad/gub/commit/5e63dbde436bd3fca154557672394987c8d2e385 Masamichi Hosoda ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB and mpfr/mpc
Masamichi HOSODA truer...@sea.plala.or.jp writes: I changed mingw.org's mingw-runtime to mingw-64 (32-bit). Then an error didn't occur and correct test.pdf was generated. https://github.com/trueroad/gub/tree/binutils-2.24 I may pull request if you request it. Further, even if the runtime is mingw-w64, bad_alloc occurred when optimization was turned on. For both of bad_alloc prevented and optimization, I tried the following setting. Only one file (lily/skyline.cc) optimization is disabled and all other files optimization is enabled. Do you have a backtrace that might give us some more clue about where lily/skyline.cc has a problem? I thought that I had at one time proposed something to be changed (as part of some issue?) order to deal with possible memory corruption, but a quick look through the log messages does not turn up either a commit from me or a commit message ringing a bell. I turned off optimization to get correct backtrace, but bad_alloc didn't occur. Therefore I could get only incomplete backtrace. It seems that push_back in Skyline::internal_merge_skyline throws bad_alloc. I think the problem is Skyline::internal_merge_skyline and/or first_intersection. Skyline::internal_merge_skyline has a while loop with push_back. I think that the loop termination condition may break by optimization. I need more elements from the backtrace. The problem most likely is that the Skyline is destructed before work with it is finished, and that means that somewhere in the call chain the Skyline is not maintained in a manner where the Lisp Garbage collector will consider it as still in use. So internal_merge_skyline is likely only the place where things blow up, but the actual cause will be further up in the call chain. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to *hide* a page from the website (and manuals)?
On 02/12/14 14:28, Urs Liska wrote: Hi folks, I just stumbled over http://lists.gnu.org/archive/html/lilypond-devel/2013-12/msg00187.html and http://lilypond.org/website/gsoc-2012.html I think my first sentence in the thread starter is even more true today. I thought we could *hide* that GSoC 2012 page from the website instead of completely removing it (making it easier to create something new someday). Any opinions? And how would one hide a page instead of deleting it? We could simply put the text in a comment within the TexInfo code that the page is built from. Assuming that is the best way forward, create a tracker and label it accordingly and I'll look at doing that. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Another English notename issue
David Kastrup wrote So I think we should likely reorder the English notename language such that the default output is the abbreviated form. Thoughts? +1 That makes good sense to me. -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Another-English-notename-issue-tp169097p169140.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to *hide* a page from the website (and manuals)?
Urs Liska wrote I just stumbled over http://lists.gnu.org/archive/html/lilypond-devel/2013-12/msg00187.html and http://lilypond.org/website/gsoc-2012.html I still think it would be best to convert it into a generic GSOC page and start the process of updating it for the next round which will arrive soon enough. Having a persistent page on the website about GSOC signals to any potential future GSOCoders that we're interested (not just for one year but every summer). We could ask the mentors listed on that page if they would still be interested in mentoring for 2015, and/or possibly remove their names and replace them with Mentor: to be determined. Just my $0.02 -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/How-to-hide-a-page-from-the-website-and-manuals-tp169135p169142.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to *hide* a page from the website (and manuals)?
Am 02.12.2014 16:58, schrieb Paul Morris: Urs Liska wrote I just stumbled over http://lists.gnu.org/archive/html/lilypond-devel/2013-12/msg00187.html and http://lilypond.org/website/gsoc-2012.html I still think it would be best to convert it into a generic GSOC page and start the process of updating it for the next round which will arrive soon enough. Having a persistent page on the website about GSOC signals to any potential future GSOCoders that we're interested (not just for one year but every summer). Sound reasonable but is definitely more work than simply hiding or deleting it. We could ask the mentors listed on that page if they would still be interested in mentoring for 2015, and/or possibly remove their names and replace them with Mentor: to be determined. Just my $0.02 -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4211: Add an alternative quarter rest shaped like a mirrored Z. (issue 177640043 by nine.fierce.ball...@gmail.com)
https://codereview.appspot.com/177640043/diff/20001/mf/feta-rests.mf File mf/feta-rests.mf (right): https://codereview.appspot.com/177640043/diff/20001/mf/feta-rests.mf#newcode438 mf/feta-rests.mf:438: rest := rest xscaled -1 shifted (w, 0); Please use tabs for indentation https://codereview.appspot.com/177640043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Context: prevent dangling references in child contexts when the daddy is destroyed (issue 182400043 by nine.fierce.ball...@gmail.com)
Reviewers: ,
Description:
I have some books which use an on-the-fly markup procedure that refers
to a context in a closure. I now question the wisdom of this, but
that's what I have. In certain circumstances (when processing a certain
book with hundreds of scores, but not other books with tens of scores),
one or more of the ancestors of the important context are destroyed.
When the time finally comes to evaluate the markup, the first thing the
on-the-fly procedure does is get a context property, which walks up the
now-invalid hierarchy until a segfault occurs.
Nullifying the child's pointer in the parent's destructor was the
obvious way to fix this. Is there a better way?
Please review this at https://codereview.appspot.com/182400043/
Affected files (+8, -1 lines):
M lily/context.cc
Index: lily/context.cc
diff --git a/lily/context.cc b/lily/context.cc
index
4a1381ae1bb8830970be3a927eaf73f7ed2b2f8c..d74e9204a752bf5cea6afaaa9a5b24ab01ee910d
100644
--- a/lily/context.cc
+++ b/lily/context.cc
@@ -248,7 +248,7 @@ Context::set_property_from_event (SCM sev)
unset_property (sym);
return;
}
-
+
bool ok = true;
ok = type_check_assignment (sym, val, ly_symbol2scm
(translation-type?));
@@ -645,6 +645,13 @@ Context::get_output_def () const
Context::~Context ()
{
+ // prevent dangling references in child contexts
+ for (SCM p = context_list_; scm_is_pair (p); p = scm_cdr (p))
+{
+ Context *ctx = Context::unsmob (scm_car (p));
+ if (ctx)
+ctx-daddy_context_ = 0;
+}
}
Moment
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
