Re: Fix for issue 1706. (issue4662047)
On 2011/06/23 17:48:23, hanwenn wrote: * Test missing. * Should print programming_error if dir == CENTER. * I'd use linear_combination on dir instead, so it is symmetric in up/down. Done, done, and done. Cheers, MS http://codereview.appspot.com/4662047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements multiple-line non-cross-staff glissandi (issue4527086)
On Jun 13, 2011, at 1:03 PM, m...@apollinemike.com wrote: On Jun 12, 2011, at 5:49 PM, n.putt...@gmail.com wrote: On 2011/06/05 10:18:18, mike_apollinemike.com wrote: On Jun 2, 2011, at 9:00 PM, mailto:n.putt...@gmail.com wrote: http://codereview.appspot.com/4527086/diff/7002/scm/output-lib.scm File scm/output-lib.scm (right): http://codereview.appspot.com/4527086/diff/7002/scm/output-lib.scm#newcode795 scm/output-lib.scm:795: (define-public (glissando::before-line-breaking grob) Possibly silly question: can't you fold this into callbacks for left-bound-info/right-bound-info instead? Sorry - I don't get what you mean :( Could you please elaborate? You're calculating a value for 'Y which you add back into bound-details. This bypasses the default calculation in calc_bound_info (). Why not caculate 'Y when left-bound-info/right-bound-info is requested, either directly in C++ or as glissando-specific scheme versions? My goal is to bypass the default calculation and replace it with this one, and it is easier to harvest the information about Y placement relative to the staff before line breaking happens. Currently, there is no mechanism in Line_spanner::calc_bound_info that can outsource the Y calculation to another function, and I wouldn't want to code dup all of the parts of Line_spanner::calc_bound_info that are worth keeping into a glissando specific function. Taking that into account, does that seem like the right approach? Just touching base on this thread to see if the explanation above makes sense and, if so, if it is push-ready. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replace Tab with 8 Spaces for .py files (issue4627062)
Thanks Keith and Carl. Pushed as 20596e17d6f8026f7199c9ae0e5f03517631a66c Closing this issue http://codereview.appspot.com/4627062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New breve rest with ledger lines (issue4650052)
Yes, sorry for that. Just for information, ancient fonts are stored in the parmesan-* files. For the ancient fonts, we really need to think about a less hard-coded solution. http://codereview.appspot.com/4650052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: question about mod dates in my git tree for resetted files
On Fri, Jun 24, 2011 at 01:57:13AM +, James Lowe wrote: Usually when I make some patches and post on Rietveld, I make a .patch file, save it somewhere safe and then 'reset' my tree (abort in Lilygit.tcl). This means I can work on other stuff without having to do complicated stuff (for me) in gitk or git cli. Incidently, this is exactly what branches are used for in git. Since you're already proficient in lily-git.tcl, and since you seem to do a lot of this stuff, and since you enjoy playing with open-source technology, it might be time to start doing some serious reading about git and leave lily-git.tcl behind. I'd allocate 10 hours of tutorial reading until things click, but I know that you have a fair amount of down time during your day job. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Adds ly:engraver-property to engraver-scheme (issue1878048)
Reviewers: ,
Message:
I found this 10-month old patch of mine laying around. It still seems
relevant, so I'm sending it to the list. Lemme know what y'all think.
Description:
Adds ly:engraver-property to engraver-scheme
Adds ly:engraver-property to engraver-scheme
Get rid of whitespace error...
Please review this at http://codereview.appspot.com/1878048/
Affected files:
M lily/engraver-scheme.cc
Index: lily/engraver-scheme.cc
diff --git a/lily/engraver-scheme.cc b/lily/engraver-scheme.cc
index
409831e8804e55a92770742d4a2c26379f63fd05..ea8f3dec2b9044bcf89ea7c2a3e357f09f0b9be0
100644
--- a/lily/engraver-scheme.cc
+++ b/lily/engraver-scheme.cc
@@ -54,3 +54,23 @@ LY_DEFINE
(ly_engraver_announce_end_grob, ly:engraver-announce-end-grob,
return SCM_UNSPECIFIED;
}
+
+LY_DEFINE (ly_engraver_property, ly:engraver-property,
+ 2, 1, 0, (SCM engraver, SCM sym, SCM val),
+ Return the value for property @var{sym} of @var{engraver}.
+If no value is found, return @var{val} or @code{'()}
+ if @var{val} is not specified.)
+{
+ Engraver *e = unsmob_engraver (engraver);
+
+ LY_ASSERT_TYPE (unsmob_engraver, engraver, 1);
+ LY_ASSERT_TYPE (ly_is_symbol, sym, 2);
+ if (val == SCM_UNDEFINED)
+val = SCM_EOL;
+
+ SCM retval = e-internal_get_property (sym);
+ if (retval == SCM_EOL)
+retval = val;
+
+ return retval;
+}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows glissandi to span multiple lines. (issue4564042)
On 2011/05/30 07:38:19, mike_apollinemike.com wrote: I'm flying to Ireland today will attempt to crunch this during the flight. This was almost a month ago. Are you sailing to Ireland instead of flying? ;) What's the status of this patch? If you think that draft 2 is correct, then I'll add it to the next patch countdown. http://codereview.appspot.com/4564042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows glissandi to span multiple lines. (issue4564042)
Sorry - this patch is obsolete. The new one is at: http://codereview.appspot.com/4527086 Sorry for not having removed the old one, and yes, please add the new one to the countdown (it has gone through a round of commentary). Cheers, MS On Jun 24, 2011, at 4:28 PM, percival.music...@gmail.com wrote: On 2011/05/30 07:38:19, mike_apollinemike.com wrote: I'm flying to Ireland today will attempt to crunch this during the flight. This was almost a month ago. Are you sailing to Ireland instead of flying? ;) What's the status of this patch? If you think that draft 2 is correct, then I'll add it to the next patch countdown. http://codereview.appspot.com/4564042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch meister
On Thu, Jun 23, 2011 at 09:31:45PM -0600, Colin Campbell wrote: I could take it on, Graham. In some ways it's just a bit further and more formal than the screening I've been trying to do. ok, great! I was just discussing the needs work aspect with James because he has an incredibly powerful new computer, so could you get started with the patch countdown? In 24 hours or more (after Sat 13:00 UK time), please send a PATCHES: 48-hour countdown for... email. if you notice any needs_work patch that should/could be review, then by all means change it -- but sending out the patch countdowns takes priority. I'd suggest a minor edit on your blog though: after the list of steps in You can help, you might s/need/mind ; heh, yeah. Thanks, fixed. A related question, though: how do we go about tying issues and patches closer together? At the moment, I don't want to cause any disruption to the current development. It would be extremely valuable either to *require* that anything on reitveld have a formal issue number, even if it's a dev contributing a hey, look what I wrote enhancement, or to look for a different platform which combines issue tracking with patch management. We certainly want to look for a different platform; that's on the GOP list. As it sits, reitveld doesn't manage projects, only developers, and the issues on code.google.com don't reflect all the issues/patched needing attention. Should we start a GOP discussion, at least to get the views of the developer community on record? At the moment, let's blunder forward as usual. Yes, this means more work for you, me, and James... but it's only about 15-30 minutes of extra admin overhead each week, and there's bigger fish to fry in GOP. I think we'll get around to a GOP discussion about this stuff in August? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replace Tab with 8 Spaces for .py files (issue4627062)
k-ohara5a5a at oco.net writes: The bad news is, you replaced tabs by 4 columns when we needed 8 column. The good news is, so far as I can see, there were no un-wanted changes (no cases were we needed a literal tab). But the GOP says use 4 spaces per indentation level! http://codereview.appspot.com/4627062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds ly:engraver-property to engraver-scheme (issue1878048)
On Fri, Jun 24, 2011 at 11:40 AM, mts...@gmail.com wrote: Reviewers: , Message: I found this 10-month old patch of mine laying around. It still seems relevant, so I'm sending it to the list. Lemme know what y'all think. What would this be used for? Normally in Scheme you'd have a context with already exports its properties. Engraver::get_property is just a convenience for the C++ side. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix for issue 1706. (issue4662047)
On 2011/06/24 06:22:48, MikeSol wrote: On 2011/06/23 17:48:23, hanwenn wrote: * Test missing. * Should print programming_error if dir == CENTER. * I'd use linear_combination on dir instead, so it is symmetric in up/down. Done, done, and done. Cheers, MS Mike I ran a reg test against this new beam code and I get significant differences on test-output-distance.ly http://codereview.appspot.com/4662047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix for issue 1706. (issue4662047)
On 2011/06/24 15:51:14, J_lowe wrote:
Mike I ran a reg test against this new beam code and I get significant
differences on
test-output-distance.ly
Umm...
http://lilypond.org/doc/v2.15/Documentation/contributor/regtest-comparison
... maybe we should change the background of @warning{} boxes to be #F00
?
That said, this patch apparently removes 5
warning: MIDI channel wrapped around
warning: remapping modulo 16
which seems weird to me. But hey, it's removing a misleading-looking
warning, so that's a good thing, right? :)
Cheers,
- Graham
http://codereview.appspot.com/4662047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds ly:engraver-property to engraver-scheme (issue1878048)
thanks, added as http://code.google.com/p/lilypond/issues/detail?id=1708 http://codereview.appspot.com/1878048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replace Tab with 8 Spaces for .py files (issue4627062)
Am Freitag, 24. Juni 2011, 15:38:21 schrieb Benjamin Peterson: k-ohara5a5a at oco.net writes: The bad news is, you replaced tabs by 4 columns when we needed 8 column. The good news is, so far as I can see, there were no un-wanted changes (no cases were we needed a literal tab). But the GOP says use 4 spaces per indentation level! Exactly. But tab != indentation level. In particular, some editors simply replace all sequences of eight spaces by one tab (that's one coding style that we want to get rid of). So, whenever you see a tab in the code, it does not mean indent one level, but it rather means exactly eight spaces. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Fix for issue 1706. (issue4662047)
Oops From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of pkx1...@gmail.com [pkx1...@gmail.com] Sent: 24 June 2011 16:51 To: mts...@gmail.com; carl.d.soren...@gmail.com; hanw...@gmail.com Cc: re...@codereview.appspotmail.com; lilypond-devel@gnu.org Subject: Re: Fix for issue 1706. (issue4662047) On 2011/06/24 06:22:48, MikeSol wrote: On 2011/06/23 17:48:23, hanwenn wrote: * Test missing. * Should print programming_error if dir == CENTER. * I'd use linear_combination on dir instead, so it is symmetric in up/down. Done, done, and done. Cheers, MS Mike I ran a reg test against this new beam code and I get significant differences on test-output-distance.ly Sorry Mike (and everyone) I misread the CG. That one always changes :) Otherwise ok. james ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replace Tab with 8 Spaces for .py files (issue4627062)
On Fri, Jun 24, 2011 at 01:38:21PM +, Benjamin Peterson wrote: k-ohara5a5a at oco.net writes: The bad news is, you replaced tabs by 4 columns when we needed 8 column. The good news is, so far as I can see, there were no un-wanted changes (no cases were we needed a literal tab). But the GOP says use 4 spaces per indentation level! In the old/bad style that emacs produced, one tab was used to represent 8 spaces. Yes, it was doubly confusing. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replace Tab with 8 Spaces for .py files (issue4627062)
[slightly offtopic tab size rant ;-)] On Fri, Jun 24, 2011 at 04:44:21PM +0100, Graham Percival wrote: In the old/bad style that emacs produced, one tab was used to represent 8 spaces. Yes, it was doubly confusing. Well, no. People and/or editors who used one tab per indentation level (and probably fiddling with the displayed *tab* width other than 8 spaces) where confused. Whenever I see any file that needs a tab width other than 8 spaces to display correctly (be it programs, be it configuration files), I get *very* upset. That said, as people today don't know the difference between tab width and indentation, it's still good to forbid tabs at all in lilypond ;-) Ciao, Kili ps: when I started working on unix (in the late 80ths), I abused tabs for indentation, too. But it took me only a few months to recognize that error. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds ly:engraver-property to engraver-scheme (issue1878048)
Passes reg tests http://codereview.appspot.com/1878048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Tuning fixes
I've found and patched two problems with the pitch bend
tuning code:
1) The pitch isn't always rounded to the nearest equally
tempered value, so the result looks strange in a sequencer,
and artifacts caused by the pitch bends are more severe.
2) The tuning is rounded to cents before the pitch bends
are calculated. It may not be a big deal, but there's no
need for it, and the code's simpler calculating the bends
directly.
I don't think either of these are registered issues. As
I'm new with Git, the two issues are mixed in the two
patches. Problem (1) is fixed in get_semitone_pitch().
It's just a question of rounding off the result.
Everything else is for problem (2).
Graham
From d402cd356203205f4863ad35f67ae23ff3422a03 Mon Sep 17 00:00:00 2001
From: Graham Breed gbr...@gmail.com
Date: Fri, 24 Jun 2011 00:12:52 +0100
Subject: [PATCH 1/2] Pitch bends of full precision centered on zero.
---
configure.in |2 +-
lily/midi-item.cc | 13 -
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/configure.in b/configure.in
index cf0178f..1ea0428 100644
--- a/configure.in
+++ b/configure.in
@@ -140,7 +140,7 @@ STEPMAKE_PYTHON_DEVEL(REQUIRED)
STEPMAKE_PATH_PROG(GHOSTSCRIPT, gs, OPTIONAL, 8.60)
-STEPMAKE_PATH_PROG(FONTFORGE, fontforge, REQUIRED, 20100501)
+STEPMAKE_PATH_PROG(FONTFORGE, fontforge, REQUIRED, 20090923)
STEPMAKE_PATH_PROG(FONTFORGE, fontforge, OPTIONAL, 20110222)
STEPMAKE_PATH_PROG(T1ASM, t1asm, REQUIRED)
diff --git a/lily/midi-item.cc b/lily/midi-item.cc
index 1fcb259..bbc4691 100644
--- a/lily/midi-item.cc
+++ b/lily/midi-item.cc
@@ -28,10 +28,8 @@
#include string-convert.hh
#include warn.hh
-#define PITCH_WHEEL_TOP 0x3FFF
#define PITCH_WHEEL_CENTER 0x2000
-#define PITCH_WHEEL_BOTTOM 0x
-#define PITCH_WHEEL_RANGE (PITCH_WHEEL_TOP - PITCH_WHEEL_BOTTOM)
+#define PITCH_WHEEL_SEMITONE 0X1000
Midi_item *
Midi_item::get_midi (Audio_item *a)
@@ -193,14 +191,14 @@ Midi_note::get_fine_tuning () const
+ audio_-transposing_.tone_pitch ()) * Rational (2);
tune -= Rational (get_semitone_pitch ());
- tune *= 100;
+ tune *= PITCH_WHEEL_SEMITONE;
return (int) double (tune);
}
int
Midi_note::get_semitone_pitch () const
{
- return int (double ((audio_-pitch_.tone_pitch ()
+ return int (0.5 + double ((audio_-pitch_.tone_pitch ()
+ audio_-transposing_.tone_pitch ()) * Rational (2)));
}
@@ -214,10 +212,7 @@ Midi_note::to_string () const
// print warning if fine tuning was needed, HJJ
if (get_fine_tuning () != 0)
{
- finetune = PITCH_WHEEL_CENTER;
- // Move pitch wheel to a shifted position.
- // The pitch wheel range (of 4 semitones) is multiplied by the cents.
- finetune += (PITCH_WHEEL_RANGE *get_fine_tuning ()) / (4 * 100);
+ finetune = PITCH_WHEEL_CENTER + get_fine_tuning();
str += ::to_string ((char) (0xE0 + channel_));
str += ::to_string ((char) (finetune 0x7F));
--
1.7.0.4
From 888b2f2ab042e0cd966f53a21e027a1d385ac818 Mon Sep 17 00:00:00 2001
From: Graham Breed gbr...@gmail.com
Date: Fri, 24 Jun 2011 18:05:38 +0100
Subject: [PATCH 2/2] Small pitch bends correct and tested.
Pitch bends are not rounded to cents.
---
lily/midi-item.cc |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/lily/midi-item.cc b/lily/midi-item.cc
index bbc4691..02bdd7a 100644
--- a/lily/midi-item.cc
+++ b/lily/midi-item.cc
@@ -198,8 +198,9 @@ Midi_note::get_fine_tuning () const
int
Midi_note::get_semitone_pitch () const
{
- return int (0.5 + double ((audio_-pitch_.tone_pitch ()
- + audio_-transposing_.tone_pitch ()) * Rational (2)));
+ double tune = double ((audio_-pitch_.tone_pitch ()
+ + audio_-transposing_.tone_pitch ()) * Rational (2));
+ return (tune 0)? int (tune + 0.5): int(tune - 0.5);
}
string
--
1.7.0.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements multiple-line non-cross-staff glissandi (issue4527086)
no problems in reg tests. http://codereview.appspot.com/4527086/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tuning fixes
On Fri, Jun 24, 2011 at 06:17:07PM +0100, Graham Breed wrote: I've found and patched two problems with the pitch bend tuning code: Thanks, Janek will upload these to rietveld. However, for patch 1 he will first remove the change to configure.in; we now require at least fontforge 20100501. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replace Tab with 8 Spaces for .py files (issue4627062)
On Fri, Jun 24, 2011 at 07:49:02PM +0200, Matthias Kilian wrote: [slightly offtopic tab size rant ;-)] On Fri, Jun 24, 2011 at 04:44:21PM +0100, Graham Percival wrote: In the old/bad style that emacs produced, one tab was used to represent 8 spaces. Yes, it was doubly confusing. Well, no. People and/or editors who used one tab per indentation level (and probably fiddling with the displayed *tab* width other than 8 spaces) where confused. No, it's worse than that. We had .py files which used: 1 indent level = 4 spaces 2 indent levels = 1 tab 3 indent levels = 1 tab + 4 spaces That is, IMNSHO, at least doubly confusing. Whenever I see any file that needs a tab width other than 8 spaces to display correctly (be it programs, be it configuration files), I get *very* upset. I get very upset when I see any file that needs a tab width to be X spaces at all. If somebody wants to use tabs to indicate indentation, great! X tabs = X levels of indentation. If somebody wants to use spaces to indicated indentation, that's fine! X spaces = K*X levels of indentation, where K is a constant. That's cool, I can swing with that. But don't mix the systems. And using a tab to represent 8 spaces is not a saving grace. In my personal code, I sometimes do this: def foo(x, y): \tbar_baz(x, \ty \t) but I'd never try to pass that off in a shared source project. (and I'm finally in the process of repenting from tab ways and switching all my .py files to 4-spaces. Yes, it took me 4 years to get around to reading those how to set up vim for python blog posts) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \breakDynamicSpan breaks with \break (bounds of spanner are invalid)
I'm currently trying to understand what exactly is the cause of bugs #1259 and
#1433:
http://code.google.com/p/lilypond/issues/detail?id=1259
http://code.google.com/p/lilypond/issues/detail?id=1433
Actually, both are symptoms of the same problem: Both set early_end_ in the
dynamic-align-engraver.cc, so that the DynamicLineSpanner is bounded after the
current/next moment. This works fine as long as the whole spanner is in one
line. As soon as there is a line break during the spanner's (pre-truncating)
lifetime, the error message appears.
It actually indicates that the DynamicTextSpanner (or the Hairpin) is longer
than its parent DynamicLineSpanner.
These error checks are in Spanner::do_break_processing, which is only called
for breaks, so the error is printed only at line breaks.
What do you think would be the correct solution?
I notice that when I simply comment out in lily/spanner.cc the lines:
-) continue; (line 120)
-) span-suicide(); (line 133)
then the output looks just as expected (of course, I get the warnings/errors).
However, I suppose these checks are there for a reason, so simply removing
them would probably cause other problems...
Or would the correct solution be to set the bound not only for the line
spanner when truncating it in
Dynamic_align_engraver::stop_translation_timestep, but also to set the same
bound for all child spanners?
I have tried this code instead of line_set_bound(d,bound), but that does not
change a thing:
line_-set_bound (d, bound);
setSpanner *::iterator it;
for ( it=running_.begin() ; it != running_.end(); it++ )
{
(*it)-set_bound (d, bound);
}
line_-set_bound (d, bound);
Is this the completely wrong approach or why are the child spanners still not
contained in the parent DynamicLineSpanner?
Any idea how to properly fix the problem?
Thanks,
Reinhold
Am Donnerstag, 2. Dezember 2010, 19:17:10 schrieb Reinhold Kainhofer:
The regtest input/regression/dynamics-alignment-breaker.ly for
\breakDynamicSpan works fine, but as soon as there are line breaks during a
dynamic spanner, it breaks with error messages:
Programmierfehler: Spanner `Hairpin' is not fully contained in parent
spanner. Ignoring orphaned part
Programmierfehler: bounds of spanner are invalid
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \breakDynamicSpan breaks with \break (bounds of spanner are invalid)
Am Freitag, 24. Juni 2011, 22:06:04 schrieb Reinhold Kainhofer: I'm currently trying to understand what exactly is the cause of bugs #1259 and #1433: http://code.google.com/p/lilypond/issues/detail?id=1259 http://code.google.com/p/lilypond/issues/detail?id=1433 [...] It actually indicates that the DynamicTextSpanner (or the Hairpin) is longer than its parent DynamicLineSpanner. These error checks are in Spanner::do_break_processing, which is only called for breaks, so the error is printed only at line breaks. Of course, I realized that the final bounds for the hairpins and dynamic text spans are set when they are really ended, so setting the bound when the line spanner is shortened will be overwritten later on and does not have an effect. So, shortening the dynamic spanners is not possible as a solution and it is perfectly legal that the spanners are longer than the parent line spanner. I realized that the only possible way is to mark the line spanner as shortened. As this is the only legal case when the parent might be shorter than the children, I tried to include an additional check for that case in Spanner::do_break_processing. Unfortunately, the offending hairpin/dynamictext spanners do not have any X- parent set in Spanner::do_break_processing, so setting a flag on shortened dynamic line spanners is also not possible... Any ideas? Thanks, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dynamic + text aligned: BEST solution?
On Thu, Jun 23, 2011 at 1:53 PM, Graham Percival gra...@percival-music.ca wrote: Please stop capitalizing patch. If you're referring to issue 1264, the patch broke the build, and in any case it's postponed until GLISS. Er, no it didn't. (TBH, I do remember Neil noticing a very minor, unrelated error though.) The only reason why I didn't push forward is because you said it was a GLISS thing... And since it's now integrated in my own framework as a hackish superset on top of LilyPond, I've been happily and selfishly using it for months without feeling the need to unearth it upstream :-) It might be a good idea to learn some scheme, or at the very least do some more experimentation. I mean, ultimately what matters is the quality of the output. Try a few different commands in your scores, look at the output, and pick the one you like the best. Xavier, this code is actually quite easy to understand; we have two arguments dynamic and string, both of which are actually text strings. The 'tweaks part is only there to add extra horizontal space, based on the string-length of the string argument., and the 'text property of the AbsoluteDynamicEvent we create is, well, the text that will be printed (in this particular case, a markup that include the dynamic argument, and the additional string as italic text). If you have some time, please do read http://lilypond.org/doc/v2.15/Documentation/extending/scheme-in-lilypond and http://www.gnu.org/software/guile/manual/ it makes for a fascinating reading reading experience, at least if you're anything like me. Feel free to ask me directly if you need more explanations about this code or what I'm using now: http://git.savannah.gnu.org/cgit/opus-libre.git/tree/bin/text.scm#n26 Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dynamic + text aligned: BEST solution?
On Sat, Jun 25, 2011 at 12:44:30AM +0200, Valentin Villenave wrote: On Thu, Jun 23, 2011 at 1:53 PM, Graham Percival gra...@percival-music.ca wrote: Please stop capitalizing patch. If you're referring to issue 1264, the patch broke the build, and in any case it's postponed until GLISS. Er, no it didn't. (TBH, I do remember Neil noticing a very minor, unrelated error though.) oops, I didn't click through enough old messages comment 1, on draft 1: http://codereview.appspot.com/2220041/ patch set 2 fixed it Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Add feta-flags to build system (issue4662055)
Reviewers: Janek Warchol, Message: Here is a revision of Janek's patch to separate feta-flags from feta-noteheads. I believe that it works properly; I rebuilt the fonts and the flags look fine. To test, you will need to do rm mf/out/* make before testing a lilypond file. Description: Add feta-flags to build system Put noteheads and flags in different fonts, but have them both built at the same time, so black_notehead_width can be common across both files. If either font changes, both will be rebuilt, but only one rebuild should happen. Please review this at http://codereview.appspot.com/4662055/ Affected files: M mf/GNUmakefile M mf/bigcheese.pe.in A mf/feta-flags-generic.mf A mf/feta-flags11.mf A mf/feta-flags13.mf A mf/feta-flags14.mf A mf/feta-flags16.mf A mf/feta-flags18.mf A mf/feta-flags20.mf A mf/feta-flags23.mf A mf/feta-flags26.mf M mf/feta-noteheads-generic.mf M mf/feta-noteheads-test-generic.mf M mf/feta-noteheads.mf M scripts/build/gen-emmentaler-scripts.py M scripts/build/mf-to-table.py ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
