Ambitus snippet
I think the snippet at: http://lilypond.org/doc/v2.19/Documentation/snippets/contexts-and-engravers#contexts-and-engravers-defining-an-engraver-in-scheme_003a-ambitus-engraver is rather complex to be included in the docs: I don't see why one would want to rewrite existing capability? Anyone object to its removal from the docs? (I'd create it on the LSR assuming it works there). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1805: AmbitusAccidental needs avoid-slur, needed when the notes in the ambitus have a slur (issue 4904049)
LGTM, but the regession test needs work http://codereview.appspot.com/4904049/diff/3001/input/regression/ambitus-slur.ly File input/regression/ambitus-slur.ly (right): http://codereview.appspot.com/4904049/diff/3001/input/regression/ambitus-slur.ly#newcode3 input/regression/ambitus-slur.ly:3: texidoc = Ambitus also works with slurs. plus so no misleading warnings are issued. http://codereview.appspot.com/4904049/diff/3001/input/regression/ambitus-slur.ly#newcode10 input/regression/ambitus-slur.ly:10: c'4( e') On 2011/09/05 15:55:30, Neil Puttock wrote: need an accidentalled note here It's not necessary to produce the unwanted error http://codereview.appspot.com/4904049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1805: AmbitusAccidental needs avoid-slur, needed when the notes in the ambitus have a slur (issue 4904049)
LGTM.
http://codereview.appspot.com/4904049/diff/3001/input/regression/ambitus-slur.ly
File input/regression/ambitus-slur.ly (right):
http://codereview.appspot.com/4904049/diff/3001/input/regression/ambitus-slur.ly#newcode3
input/regression/ambitus-slur.ly:3: texidoc = Ambitus also works with
slurs.
prefer
ambitus accidentals are ignored for slur avoidance
http://codereview.appspot.com/4904049/diff/3001/input/regression/ambitus-slur.ly#newcode8
input/regression/ambitus-slur.ly:8: \new Score {
remove
http://codereview.appspot.com/4904049/diff/3001/input/regression/ambitus-slur.ly#newcode10
input/regression/ambitus-slur.ly:10: c'4( e')
need an accidentalled note here
http://codereview.appspot.com/4904049/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1805: AmbitusAccidental needs avoid-slur, needed when the notes in the ambitus have a slur (issue 4904049)
passes Make and reg tests http://codereview.appspot.com/4904049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 7/10/11 3:09 PM, Neil Puttock n.putt...@gmail.com wrote:
On 7 July 2011 23:22, carl.d.soren...@gmail.com wrote:
On 2011/07/07 16:12:08, Neil Puttock wrote:
LGTM, though the regtest is still a bit messy.
What do you consider messy about the regtest?
Just a few nitpicks:
+\score{
+ \context Staff=default {
+ \context{
+ \consists Ambitus_engraver
+ \consists Mensural_ligature_engraver
Ahh, thanks. Fixed now:
{
\new Voice \with {
\consists Ambitus_engraver
\consists Mensural_ligature_engraver
} {
\[ c'\longa c''\longa \]
}
}
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 10 July 2011 23:34, Carl Sorensen c_soren...@byu.edu wrote:
Ahh, thanks. Fixed now:
{
\new Voice \with {
\consists Ambitus_engraver
\consists Mensural_ligature_engraver
Heh, you didn't have to do this; I meant the missing quotation marks
around the engraver names. :)
(and now you've added a spurious sequential block ;)
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 7/10/11 4:41 PM, Neil Puttock n.putt...@gmail.com wrote:
On 10 July 2011 23:34, Carl Sorensen c_soren...@byu.edu wrote:
Ahh, thanks. Fixed now:
{
\new Voice \with {
\consists Ambitus_engraver
\consists Mensural_ligature_engraver
Heh, you didn't have to do this; I meant the missing quotation marks
around the engraver names. :)
Ahh -- oh, well. The new version *is* shorter.
(and now you've added a spurious sequential block ;)
And removed it.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
This has had a 48-hour countdown, and can be pushed and closed, please. Colin http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 7/9/11 7:55 PM, colinpkcampb...@gmail.com colinpkcampb...@gmail.com wrote: This has had a 48-hour countdown, and can be pushed and closed, please. Issue 1715 issue marked fixed; Rietveld issue closed Commit: 4fd0de625eba203265241fca20c504724013f534 Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
LGTM, though the regtest is still a bit messy. http://codereview.appspot.com/4667055/diff/14001/scm/define-grob-interfaces.scm File scm/define-grob-interfaces.scm (right): http://codereview.appspot.com/4667055/diff/14001/scm/define-grob-interfaces.scm#newcode128 scm/define-grob-interfaces.scm:128: A note-head that can become part of a ligature. note head http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 2011/07/07 16:12:08, Neil Puttock wrote: LGTM, though the regtest is still a bit messy. What do you consider messy about the regtest? scm/define-grob-interfaces.scm:128: A note-head that can become part of a ligature. note head Done Thanks, Carl http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 2011/07/04 22:31:18, Carl wrote: OK, so I've added ligature-interface to NoteHead, and everything seems to work now. Erm, can I take back what I said yesterday? :) This looks really weird now, since it appears we're acknowledging ligature grobs. I think ligature-head-interface would be less confusing for the acknowledgers. Cheers, Neil http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 2011/07/04 01:54:40, Carl wrote: Instead of filtering out bad events, I chose to filter in only events with ligature interfaces. That's a lot of internal_has_interface () calls. :) You might as well create a new interface just for NoteHead (e.g., ligature-head-interface). Cheers, Neil http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 2011/07/04 20:30:10, Neil Puttock wrote: On 2011/07/04 01:54:40, Carl wrote: Instead of filtering out bad events, I chose to filter in only events with ligature interfaces. That's a lot of internal_has_interface () calls. :) I wondered about that. But I think the first one that is true will stop the evaluation, so at the present only one would be called. The original way you suggested was to have two internal_has_interface () calls; this one only adds one. You might as well create a new interface just for NoteHead (e.g., ligature-head-interface). We already have the unused ligature-interface. What if I just added ligature-interface to NoteHead? Thanks, Carl http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 4 July 2011 21:57, carl.d.soren...@gmail.com wrote: The original way you suggested was to have two internal_has_interface () calls; this one only adds one. But for the invalid heads, all three calls would be made (and of course, for a NoteHead itself only the first interface check will ever happen, so the other calls are redundant). We already have the unused ligature-interface. What if I just added ligature-interface to NoteHead? Sounds fine to me. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 2011/07/04 21:22:58, Neil Puttock wrote: On 4 July 2011 21:57, mailto:carl.d.soren...@gmail.com wrote: We already have the unused ligature-interface. nbsp;What if I just added ligature-interface to NoteHead? Sounds fine to me. OK, so I've added ligature-interface to NoteHead, and everything seems to work now. Thanks, Carl http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
Reviewers: ,
Message:
Here is a proposed patch for fixing issue 1715. It works by checking
for event-cause before acknowledging a notehead, thus ignoring
AmbitusNoteHeads
Description:
Fix segfault with ambitus and ligature (Issue 1715)
Check for an event-cause before acknowledging note_head. This
prevents trying to make a ligature from the AmbitusNoteHeads.
Also includes regression test.
Please review this at http://codereview.appspot.com/4667055/
Affected files:
A input/regression/ambitus-with-ligature.ly
M lily/ligature-engraver.cc
Index: input/regression/ambitus-with-ligature.ly
diff --git a/input/regression/ambitus-with-ligature.ly
b/input/regression/ambitus-with-ligature.ly
new file mode 100644
index
..49c1f27ab7d3afa0caa2693fd8f6fef5f3c2eb79
--- /dev/null
+++ b/input/regression/ambitus-with-ligature.ly
@@ -0,0 +1,29 @@
+\version 2.14
+
+\header {
+ texidoc =
+A @code{\Voice} should be able to contain both an @code{Ambitus_engraver}
+and a @code{Mensural_ligature_engraver} without segfaulting.
+
+}
+
+testnotes = {
+ \relative c' {
+\[ c\longa c'\longa \] %This is a ligature; we are interpreting it as
two whole notes
+ }
+}
+
+\score{
+ {
+\context Staff=default {
+ \testnotes
+}
+ }
+ \layout {
+\context{
+ \Voice
+ \consists Ambitus_engraver
+ \consists Mensural_ligature_engraver
+}
+ }
+}
Index: lily/ligature-engraver.cc
diff --git a/lily/ligature-engraver.cc b/lily/ligature-engraver.cc
index
be4917f0c735ec5da9078c875af32a0317ce35ea..756b7bbc7d44569ff873d77c5f89e1d45d7092ae
100644
--- a/lily/ligature-engraver.cc
+++ b/lily/ligature-engraver.cc
@@ -143,7 +143,7 @@ Ligature_engraver::process_music ()
ligature_start_mom_ = now_mom ();
- // TODO: dump cause into make_item/spanner.
+ // TODO: dump cause into make_item/spanner.
// announce_grob (ligature_, events_drul_[START]-self_scm ());
}
}
@@ -196,14 +196,13 @@ Ligature_engraver::current_ligature ()
void
Ligature_engraver::acknowledge_note_head (Grob_info info)
{
- if (ligature_)
-{
- primitives_.push_back (info);
- if (info.grob () brew_ligature_primitive_proc != SCM_EOL)
- {
+ if (info.event_cause ())
+if (ligature_)
+ {
+primitives_.push_back (info);
+if (info.grob () brew_ligature_primitive_proc != SCM_EOL)
info.grob ()-set_property (stencil, brew_ligature_primitive_proc);
- }
-}
+ }
}
void
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
Hi Carl, This LGTM, though the regtest could do with a bit of tidying. A more correct approach would be to filter interfaces since the Ligature_engraver also potentially acknowledges PitchTrillGroup. It's probably not worth the bother though: it does have an event-cause and is ignored by the ligature engravers; furthermore, it's unlikely \pitchedTrill would be used in conjunction with such ligatures. Cheers, Neil http://codereview.appspot.com/4667055/diff/2001/lily/ligature-engraver.cc File lily/ligature-engraver.cc (right): http://codereview.appspot.com/4667055/diff/2001/lily/ligature-engraver.cc#newcode199 lily/ligature-engraver.cc:199: if (info.event_cause ()) // Ignore AmbitusNoteHead which has no event_cause if (info.event_cause () ligature_) http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 2011/07/03 21:25:58, Neil Puttock wrote: Hi Carl, This LGTM, though the regtest could do with a bit of tidying. Yeah, I thought of that, but I was too lazy. I just took what was in the tracker. OK, I'll trim it up some more. A more correct approach would be to filter interfaces since the Ligature_engraver also potentially acknowledges PitchTrillGroup. What do you mean filter interfaces? As long as I'm working on it I might as well get it right. Thanks, Carl http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 2011/07/03 21:32:45, Carl wrote: On 2011/07/03 21:25:58, Neil Puttock wrote: Hi Carl, This LGTM, though the regtest could do with a bit of tidying. Yeah, I thought of that, but I was too lazy. I just took what was in the tracker. OK, I'll trim it up some more. A more correct approach would be to filter interfaces since the Ligature_engraver also potentially acknowledges PitchTrillGroup. What do you mean filter interfaces? As long as I'm working on it I might as well get it right. Use info.grob ()-internal_has_interface (...) to filter out the AmbitusNoteHead and PitchTrillGroup (via ambitus-interface and axis-group-interface). http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 2011/07/03 21:39:16, Neil Puttock wrote: On 2011/07/03 21:32:45, Carl wrote: On 2011/07/03 21:25:58, Neil Puttock wrote: Hi Carl, This LGTM, though the regtest could do with a bit of tidying. Yeah, I thought of that, but I was too lazy. I just took what was in the tracker. OK, I'll trim it up some more. A more correct approach would be to filter interfaces since the Ligature_engraver also potentially acknowledges PitchTrillGroup. What do you mean filter interfaces? As long as I'm working on it I might as well get it right. Use info.grob ()-internal_has_interface (...) to filter out the AmbitusNoteHead and PitchTrillGroup (via ambitus-interface and axis-group-interface). Oops, TrillPitchGroup. http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
Passes make and reg test James http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
Instead of filtering out bad events, I chose to filter in only events with ligature interfaces. I'm not sure my line-breaking is correct on the internal_has_interface () calls, but we'll soon have fixcc.py working, right? :) If it isn't right, please help me know how to fix it. I also trimmed the regtest. Thanks, Carl http://codereview.appspot.com/4667055/diff/2001/lily/ligature-engraver.cc File lily/ligature-engraver.cc (right): http://codereview.appspot.com/4667055/diff/2001/lily/ligature-engraver.cc#newcode199 lily/ligature-engraver.cc:199: if (info.event_cause ()) // Ignore AmbitusNoteHead which has no event_cause On 2011/07/03 21:25:58, Neil Puttock wrote: if (info.event_cause () ligature_) Done. http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
Hi Janek, I'd be much happier with this change if you used a callback for 'gap instead of inserting new code into the print function. That way it's easy for users to override the default behaviour without adding more properties. Cheers, Neil http://codereview.appspot.com/4609041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
http://codereview.appspot.com/4609041/diff/12001/scm/define-grobs.scm File scm/define-grobs.scm (right): http://codereview.appspot.com/4609041/diff/12001/scm/define-grobs.scm#newcode141 scm/define-grobs.scm:141: (woot . 1) On 2011/06/17 07:18:49, MikeSol wrote: This seems like 1337 $p34k - I have never heard woot in any other context. Perhaps change to something more descriptive? Of course! I had no idea for the name and decided to use a placeholder and ask you instead of wasting 15 minutes on something so simple (i was quite tired when i wrote this code). http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm File scm/output-lib.scm (right): http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode944 scm/output-lib.scm:944: (linear-gap (+ (max gap-property 0.3) -0.45 On 2011/06/17 07:18:49, MikeSol wrote: Indentation: the -0.45 should be on the next line lined up with the left-parenthesis of (max. Done. http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode950 scm/output-lib.scm:950: (unwooted (max (min calculated-gap gap-property) (/ gap-property 4.5))) On 2011/06/17 07:18:49, MikeSol wrote: 80 column max Done. http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode951 scm/output-lib.scm:951: (gap (+ (* unwooted woot) (* gap-property (- 1 woot On 2011/06/17 07:18:49, MikeSol wrote: This codes a lot of properties. I'm fine with the code (though I'd need to see a regtest). Can you try using a details property (like for the Beam grob) that stores all of these values? Umm, I don't want to define properties like linear-gap, calculated-gap etc. They are just temporary variables so that the code calculating final gap is easier to read. Had i not used them, i would have to write everything explicitely like this (with better indentation perhaps): (gap (+ (* (max (min (if ( (+ (max (ly:grob-property grob 'gap 0.35) 0.3) -0.45 (* 0.2 (- (interval-start (ly:grob-extent head-up common Y)) (interval-end (ly:grob-extent head-down common Y) 0.2) (+ (max (ly:grob-property grob 'gap 0.35) 0.3) -0.45 (* 0.2 (- (interval-start (ly:grob-extent head-up common Y)) (interval-end (ly:grob-extent head-down common Y) (+ (* (floor (/ (- (+ (max (ly:grob-property grob 'gap 0.35) 0.3) -0.45 (* 0.2 (- (interval-start (ly:grob-extent head-up common Y)) (interval-end (ly:grob-extent head-down common Y) 0.2) 0.25)) 0.25) 0.2)) (ly:grob-property grob 'gap 0.35)) (/ (ly:grob-property grob 'gap 0.35) 4.5)) (ly:grob-property grob 'woot 1)) (* (ly:grob-property grob 'gap 0.35) (- 1 (ly:grob-property grob 'woot 1) looks suicidal... When i noticed that point-max and point-min don't seem to be any properties but only a sort of temporary variables, i used this idea for my piece of code. Maybe i didn't understand how this works... http://codereview.appspot.com/4609041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
2011/6/17 James Lowe james.l...@datacore.com: Hello tongueWhat about 'glyph-space-distance-within-staff-affinity-thing'?/in cheek Isn't that more in keeping with the new spacing terminology. Huh? I don't understand. The / tags don't match! :P ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
Hi Karin,
i'm back from my short vacation.
2011/6/17 karin.hoeth...@googlemail.com:
the description explains clearly how to use the parameters gap and woot.
So, it is a good starting point to understanding the scheme code that
follows.
Good!
Yes, the quanting stays the same.
I couldn't find the verb to quant in a dictionary. Is it short for
to quantize?
Yes. It's used a lot in beaming code.
If so, it might be clearer to change the description in output-lib.scm.
Good point, it's better to avoid abbreviations.
Finally, I tested the gap adjustment for several intervals. For a fifth:
\new Staff \with { \consists Ambitus_engraver } {
c' g'
}
the bottom of the ambitus line is very close to the lower note in the
default case. Is this on purpose? I would expect the ambitus line to be
more or less centered between note heads.
Have you zoomed the output to check it? I suppose its a rasterization
problem; a lot of things seem to be wrong when output is watched
unzoomed on a computer screen (for example one stem in the attachment
looks two times thicker than the other, while in fact it's exactly the
same).
Thanks for review!
Janek
attachment: bad rasterization.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
On Jun 21, 2011, at 3:04 PM, lemniskata.bernoull...@gmail.com wrote: http://codereview.appspot.com/4609041/diff/12001/scm/define-grobs.scm File scm/define-grobs.scm (right): http://codereview.appspot.com/4609041/diff/12001/scm/define-grobs.scm#newcode141 scm/define-grobs.scm:141: (woot . 1) On 2011/06/17 07:18:49, MikeSol wrote: This seems like 1337 $p34k - I have never heard woot in any other context. Perhaps change to something more descriptive? Of course! I had no idea for the name and decided to use a placeholder and ask you instead of wasting 15 minutes on something so simple (i was quite tired when i wrote this code). http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm File scm/output-lib.scm (right): http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode944 scm/output-lib.scm:944: (linear-gap (+ (max gap-property 0.3) -0.45 On 2011/06/17 07:18:49, MikeSol wrote: Indentation: the -0.45 should be on the next line lined up with the left-parenthesis of (max. Done. http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode950 scm/output-lib.scm:950: (unwooted (max (min calculated-gap gap-property) (/ gap-property 4.5))) On 2011/06/17 07:18:49, MikeSol wrote: 80 column max Done. http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode951 scm/output-lib.scm:951: (gap (+ (* unwooted woot) (* gap-property (- 1 woot On 2011/06/17 07:18:49, MikeSol wrote: This codes a lot of properties. I'm fine with the code (though I'd need to see a regtest). Can you try using a details property (like for the Beam grob) that stores all of these values? Umm, I don't want to define properties like linear-gap, calculated-gap etc. They are just temporary variables so that the code calculating final gap is easier to read. Had i not used them, i would have to write everything explicitely like this (with better indentation perhaps): (gap (+ (* (max (min (if ( (+ (max (ly:grob-property grob 'gap 0.35) 0.3) -0.45 (* 0.2 (- (interval-start (ly:grob-extent head-up common Y)) (interval-end (ly:grob-extent head-down common Y) 0.2) (+ (max (ly:grob-property grob 'gap 0.35) 0.3) -0.45 (* 0.2 (- (interval-start (ly:grob-extent head-up common Y)) (interval-end (ly:grob-extent head-down common Y) (+ (* (floor (/ (- (+ (max (ly:grob-property grob 'gap 0.35) 0.3) -0.45 (* 0.2 (- (interval-start (ly:grob-extent head-up common Y)) (interval-end (ly:grob-extent head-down common Y) 0.2) 0.25)) 0.25) 0.2)) (ly:grob-property grob 'gap 0.35)) (/ (ly:grob-property grob 'gap 0.35) 4.5)) (ly:grob-property grob 'woot 1)) (* (ly:grob-property grob 'gap 0.35) (- 1 (ly:grob-property grob 'woot 1) looks suicidal... When i noticed that point-max and point-min don't seem to be any properties but only a sort of temporary variables, i used this idea for my piece of code. Maybe i didn't understand how this works... What I meant is that every time you use a magic number (i.e. 0.35), consider making it user-tweakable unless you are absolutely sure that there is no utility in changing that number. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
- Original Message - From: Janek Warchoł lemniskata.bernoull...@gmail.com Have you zoomed the output to check it? I suppose its a rasterization problem; a lot of things seem to be wrong when output is watched unzoomed on a computer screen (for example one stem in the attachment looks two times thicker than the other, while in fact it's exactly the same). Don't forget that it's important to do this with the PDF output. The way PDF viewers and the PNG generator convert the PDF to images does often cause the apparent oddities you're talking about. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
2011/6/21 m...@apollinemike.com m...@apollinemike.com: What I meant is that every time you use a magic number (i.e. 0.35), consider making it user-tweakable unless you are absolutely sure that there is no utility in changing that number. Ah, you meant this! :) well, i think that 0.35 in (ly:grob-property grob 'gap 0.35) means if you have trouble reading gap property, use 0.35, so it's only kind of default value. As for other numbers, i'm sure that making them user-tweakable will be overkill. They simply are coefficients in a function that does a very nitpicky tweak; the function (as a whole) can be controlled by gap-stretchability and i'm sure it's enough. Personally i suppose that noone in the world - except me - will ever care about gap-stretchability value, leave alone the coefficients in the funciton :) thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
On Jun 21, 2011, at 3:31 PM, Janek Warchoł wrote: 2011/6/21 m...@apollinemike.com m...@apollinemike.com: What I meant is that every time you use a magic number (i.e. 0.35), consider making it user-tweakable unless you are absolutely sure that there is no utility in changing that number. Ah, you meant this! :) well, i think that 0.35 in (ly:grob-property grob 'gap 0.35) means if you have trouble reading gap property, use 0.35, so it's only kind of default value. As for other numbers, i'm sure that making them user-tweakable will be overkill. They simply are coefficients in a function that does a very nitpicky tweak; the function (as a whole) can be controlled by gap-stretchability and i'm sure it's enough. Personally i suppose that noone in the world - except me - will ever care about gap-stretchability value, leave alone the coefficients in the funciton :) Sorry sorry - I mis-mis-spoke (I should have read my previous post). What I meant is that these values could be wrapped up into a details property. The argument that user-tweakability is overkill isn't necessarily a bad thing - check out the `details' property for the Slur and Beam grobs. By creating a similar details list, it'd be more LilyPond-esque, which makes the code easier to read (and, on the off chance that someone actually wants to modify this (which is admittedly rare), they'll be able to w/o having to change the source). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: ambitus: special handling of small ambits' lines (issue4609041)
Hello From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Carl Sorensen [c_soren...@byu.edu] Sent: 17 June 2011 00:25 To: lemniskata.bernoull...@gmail.com; tdanielsmu...@googlemail.com; mts...@gmail.com; t.dani...@treda.co.uk; mikesubel...@otherinbox.com Cc: re...@codereview.appspotmail.com; lilypond-devel@gnu.org Subject: Re: ambitus: special handling of small ambits' lines (issue4609041) Thanks for the ideas, Karin. They triggered another one for me. Can we use similar concepts to vertical spacing variables and call it gap-stretchability? -- Yuk! tongueWhat about 'glyph-space-distance-within-staff-affinity-thing'?/in cheek Isn't that more in keeping with the new spacing terminology. ;) James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
Hi Janek,
the description explains clearly how to use the parameters gap and woot.
So, it is a good starting point to understanding the scheme code that
follows.
I added a parameter which controlls this, but no reasonable name for
it
(and for some intermediate stages in the code) comes to my mind.
Any suggestions to what should i change woot and unwooted?
What about gap-adjustment-strength or gap-optimization-strength?
- gap should be contained in the name, since that is the quantity
changed by woot
- adjustment because the gap is optimized
- strength, because the value ranges between 0 and 1 (as opposed to
boolean)
Yes, the quanting stays the same.
I couldn't find the verb to quant in a dictionary. Is it short for
to quantize? If so, it might be clearer to change the description in
output-lib.scm.
Finally, I tested the gap adjustment for several intervals. For a fifth:
\new Staff \with { \consists Ambitus_engraver } {
c' g'
}
the bottom of the ambitus line is very close to the lower note in the
default case. Is this on purpose? I would expect the ambitus line to be
more or less centered between note heads.
hope this helps,
Karin
http://codereview.appspot.com/4609041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
On 6/16/11 4:53 PM, karin.hoeth...@googlemail.com karin.hoeth...@googlemail.com wrote: Hi Janek, the description explains clearly how to use the parameters gap and woot. So, it is a good starting point to understanding the scheme code that follows. I added a parameter which controlls this, but no reasonable name for it (and for some intermediate stages in the code) comes to my mind. Any suggestions to what should i change woot and unwooted? What about gap-adjustment-strength or gap-optimization-strength? - gap should be contained in the name, since that is the quantity changed by woot - adjustment because the gap is optimized - strength, because the value ranges between 0 and 1 (as opposed to boolean) Thanks for the ideas, Karin. They triggered another one for me. Can we use similar concepts to vertical spacing variables and call it gap-stretchability? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
Thanks - much clearer! Two points: a) It would be better to honour the value of 'gap if this is set by the user, rather than change a specifically requested gap value. b) I don't understand why quanting is desired. An ambitus doesn't align with anything. What is your reason? http://codereview.appspot.com/4609041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
2011/6/13 tdanielsmu...@googlemail.com:
Thanks - much clearer!
Two points:
a) It would be better to honour the value of 'gap if this
is set by the user, rather than change a specifically
requested gap value.
My rationale is that it wouldn't make sense to set a big gap and
really want to have it applied to all ambituses. Consider the
following:
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
c' g'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
c' a'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
c' b'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
c' c''
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
c' e''
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
a a''
}
While gap=0.7 works fine for big ambituses (one can easily imagine
that a user may wish such a value), the ambitus of sixth looks
ridiculous without any line inside. I suppose that if someone would
like that look, he would probably switch the line off entirely.
And for small gap the effect is almost unnoticeable.
b) I don't understand why quanting is desired. An ambitus
doesn't align with anything. What is your reason?
I thought that it's best if ambitus line eihter ends precisely inside
staff line, or protrudes from it distinctly. In other words, i judged
that
\new Staff \with { \consists Ambitus_engraver }
{ \override Staff.AmbitusLine #'gap = #0.3 c' b' }
doesn't look nice.
Ofc i'm aware that this is perhaps as nitpicky as it can go :D
Thanks,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
Janek Warchoł wrote Monday, June 13, 2011 2:51 PM
2011/6/13 tdanielsmu...@googlemail.com:
a) It would be better to honour the value of 'gap if this
is set by the user, rather than change a specifically
requested gap value.
My rationale is that it wouldn't make sense to set a big gap and
really want to have it applied to all ambituses. Consider the
following:
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
c' g'
}
...
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
a a''
}
While gap=0.7 works fine for big ambituses (one can easily imagine
that a user may wish such a value), the ambitus of sixth looks
ridiculous without any line inside. I suppose that if someone
would
like that look, he would probably switch the line off entirely.
And for small gap the effect is almost unnoticeable.
Your algorithm is fine as the default behaviour, but it does remove
the
ability for a user to precisely set the gap he wants by setting
'gap,
for whatever reason. This seems counter to Lily's flexible user
control,
but I don't feel too strongly about it. If this is implemented the
description
of 'gap will have to be changed to explain this.
b) I don't understand why quanting is desired. An ambitus
doesn't align with anything. What is your reason?
I thought that it's best if ambitus line eihter ends precisely
inside
staff line, or protrudes from it distinctly. In other words, i
judged
that
\new Staff \with { \consists Ambitus_engraver }
{ \override Staff.AmbitusLine #'gap = #0.3 c' b' }
doesn't look nice.
Ofc i'm aware that this is perhaps as nitpicky as it can go :D
OK. It is! :) Does it scale correctly with large and small values
of
global staff-size?
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
ambitus: special handling of small ambits' lines (issue4609041)
Reviewers: Mike, Description: ambitus: special handling of small ambits' lines Until now, it was not possible to have all ambits look good: either the gaps between ambit line and heads were too big for ambits of 4th and 5th, or they were too small for other ambits. This patch introduces automatic scaling of the gap between heads and line: bigger ambits are left unchanged, but smaller have their gap diminished so that the line is long enough. Please review this at http://codereview.appspot.com/4609041/ Affected files: M scm/output-lib.scm Index: scm/output-lib.scm diff --git a/scm/output-lib.scm b/scm/output-lib.scm index c25edf31f68a93de749a87e69e26cd4dde6dfc3d..dc2ff7a159313545f08fbfcb135a4a11b9f323fa 100644 --- a/scm/output-lib.scm +++ b/scm/output-lib.scm @@ -915,13 +915,44 @@ between the two text elements. (let* ((common (ly:grob-common-refpoint-of-array grob heads Y)) (head-down (ly:grob-array-ref heads 0)) (head-up (ly:grob-array-ref heads 1)) - (gap (ly:grob-property grob 'gap 0.35)) + ;; top of lower ambitus head: + (ground (interval-end (ly:grob-extent head-down common Y))) + ;; bottom of upper ambitus head: + (roof (interval-start (ly:grob-extent head-up common Y))) + ;; total amount of space between ambitus heads - + ;; our task is to decide how much of this space will be occupied + ;; by the ambitus line. We do this by calculating how big the gaps + ;; between ambitus line and ambitus heads will be. + (space-between-heads (- roof ground)) + ;; read the property - this is our starting point; + ;; we are going to adjust it to fit small ambituses better: + (gap-property (ly:grob-property grob 'gap 0.35)) + ;; We calculate a theoretical gap size using a linear function. + ;; the function was determined by trial-and-error; it's main + ;; premises are: gap is proportional to space between heads, + ;; big value in gap property means that small ambituses won't + ;; have any line at all, for values around 0.45 (default) + ;; gap approaches 0 when distance betweeen heads approaches 0, + ;; and it shouldn't reach 0 too soon with very small values. + (proportional (+ (max gap-property 0.3) -0.45 + (* 0.2 space-between-heads))) + ;; ambitus line looks best if the gap value is quanted. + ;; optimal quants are: 0.2 0.45 0.7 0.95 1.2 etc. + (quanted-gap (+ (* (floor (/ (- proportional 0.2) 0.25)) 0.25) 0.2)) + ;; we don't want to quant gap values smaller than 0.2 + ;; (because quanting them would mean making them 0). + (theoretical (if ( proportional 0.2) proportional quanted-gap)) + ;; The above calculations are mainly for small ambituses; + ;; in case of bigger ones they would lead to very big gaps + ;; so we restrict them by the value written in the gap property. + ;; we also don't want gap values too close to 0, hence the max. + (gap (max (min theoretical gap-property) (/ gap-property 4.5))) (point-min (+ (interval-end (ly:grob-extent head-down common Y)) gap)) (point-max (- (interval-start (ly:grob-extent head-up common Y)) gap))) - (if ( point-min point-max) + (if ( (+ point-min 0.1) point-max) ;; don't print lines shorter than 0.1 (let* ((layout (ly:grob-layout grob)) (line-thick (ly:output-def-lookup layout 'line-thickness)) (blot (ly:output-def-lookup layout 'blot-diameter)) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
Oops, i added wrong Mike...
Here is the code i used for testing; i attach a pdf compiled with my fix:
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.45
c' f'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.45
c' g'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.45
c' a'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.45
c' b'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.45
c' c''
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.45
a a''
}
cheers,
Janek
ambit.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 1376 ambitus two accidentals. (issue4099044)
On 2011/01/23 22:35:02, Neil Puttock wrote: Sorry Graham, my comment on the regtest should've been clearer: I wasn't proposing we add that information to the test (since it only applies to the new case fixed by this patch); it's just that the original text is ambiguous (the part about two noteheads, since we can only see one in the altered unison case). Ok, no problem. I pushed the modified regtest text, since it certainly doesn't hurt. Cheers, - Graham http://codereview.appspot.com/4099044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix issue 1376 ambitus two accidentals. (issue4099044)
LGTM.
http://codereview.appspot.com/4099044/diff/1/input/regression/ambitus.ly
File input/regression/ambitus.ly (right):
http://codereview.appspot.com/4099044/diff/1/input/regression/ambitus.ly#newcode8
input/regression/ambitus.ly:8: Two noteheads are displayed even for a
note with two different
Tthe noteheads are printed in overstrike, so there's only one visible;
the accidentals are prevented from colliding.
http://codereview.appspot.com/4099044/diff/1/input/regression/ambitus.ly#newcode30
input/regression/ambitus.ly:30: \new Staff \relative c'{
c' {
http://codereview.appspot.com/4099044/diff/1/lily/ambitus-engraver.cc
File lily/ambitus-engraver.cc (right):
http://codereview.appspot.com/4099044/diff/1/lily/ambitus-engraver.cc#newcode184
lily/ambitus-engraver.cc:184: !((p.steps () == other.steps ())
indent
http://codereview.appspot.com/4099044/diff/1/lily/ambitus-engraver.cc#newcode185
lily/ambitus-engraver.cc:185: (p.get_alteration () !=
other.get_alteration (
indent
http://codereview.appspot.com/4099044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 1376 ambitus two accidentals. (issue4099044)
Reviewers: Neil Puttock,
Message:
On 2011/01/23 18:00:23, Neil Puttock wrote:
LGTM.
Thanks!
I've uploaded patchset 3, which I believe fixes all these.
Cheers,
- Graham
Description:
Fix issue 1376 ambitus two accidentals.
Add regtest for 1376 ambitus accidentals.
When an ambitus consists of a single note with different alterations,
two accidentals should be printed, no matter the key signature.
Please review this at http://codereview.appspot.com/4099044/
Affected files:
M input/regression/ambitus.ly
M lily/ambitus-engraver.cc
Index: input/regression/ambitus.ly
diff --git a/input/regression/ambitus.ly b/input/regression/ambitus.ly
index
03c6a776fbeb89de671ed5518cb94a505632783b..ea715f0e994e7baa093af712033fc926d2c2c9ad
100644
--- a/input/regression/ambitus.ly
+++ b/input/regression/ambitus.ly
@@ -1,10 +1,12 @@
-\version 2.12.0
+\version 2.13.47
\header {
texidoc = Ambitus indicate pitch ranges for voices.
Accidentals only show up if they're not part of key
signature. @code{AmbitusNoteHead} grobs also have ledger lines.
+The noteheads are printed in overstrike, so there's only one
+visible; the accidentals are prevented from colliding.
}
@@ -25,4 +27,8 @@ signature. @code{AmbitusNoteHead} grobs also have ledger
lines.
\key d \major
cis as'
}
+ \new Staff \relative c' {
+\time 2/4
+c4 cis
+ }
Index: lily/ambitus-engraver.cc
diff --git a/lily/ambitus-engraver.cc b/lily/ambitus-engraver.cc
index
d4bc39e7283c2cd9ebcb34944635f1c0cf0a6a76..221c1e8881ee950c70da5af60b29f202236d30ef
100644
--- a/lily/ambitus-engraver.cc
+++ b/lily/ambitus-engraver.cc
@@ -178,7 +178,11 @@ Ambitus_engraver::finalize ()
? robust_scm2rational (scm_cdr (handle), Rational (0))
: Rational (0);
- if (sig_alter == p.get_alteration ())
+ const Pitch other = pitch_interval_[-d];
+
+ if (sig_alter == p.get_alteration ()
+ !((p.steps () == other.steps ())
+ (p.get_alteration () != other.get_alteration (
{
accidentals_[d]-suicide ();
heads_[d]-set_object (accidental-grob, SCM_EOL);
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 1376 ambitus two accidentals. (issue4099044)
On 2011/01/23 18:21:11, Graham Percival wrote: I've uploaded patchset 3, which I believe fixes all these. Sorry Graham, my comment on the regtest should've been clearer: I wasn't proposing we add that information to the test (since it only applies to the new case fixed by this patch); it's just that the original text is ambiguous (the part about two noteheads, since we can only see one in the altered unison case). Cheers, Neil http://codereview.appspot.com/4099044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 1376 ambitus two accidentals. (issue4099044)
LGTM. Carl http://codereview.appspot.com/4099044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
Le 29 août 09 à 06:56, David Kastrup a écrit : Carl Sorensen c_soren...@byu.edu writes: On Aug 28, 2009, at 1:16 PM, Nicolas Sceaux nicolas.sce...@free.fr wrote: According to R5RS, it is an error to modify a literal list. If a function returns '(), the caller won't be allowed to apply a modifying function on the result (eg. append!) IIUC, '() is not a literal list, but a constant that represents the empty list. It is a literal list in my opinion, but one that happens to have no unique and/or modifiable conses. Append will work just fine on it. However, guile does not report modifying a literal list as an error, and actually modifies it, so this is somewhat rhetorical. It is not rhetorical since a modified literal list will actually stay modified when you call the function the next time. Can't happen with '() though. You're right on both points! thanks. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
On 8/28/09 10:56 PM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On Aug 28, 2009, at 1:16 PM, Nicolas Sceaux nicolas.sce...@free.fr wrote: According to R5RS, it is an error to modify a literal list. If a function returns '(), the caller won't be allowed to apply a modifying function on the result (eg. append!) IIUC, '() is not a literal list, but a constant that represents the empty list. It is a literal list in my opinion, but one that happens to have no unique and/or modifiable conses. Append will work just fine on it. It is *not* a literal list. Here is the proof: guile (define a '(4 5)) guile (define b '(4 5)) guile (eq? a b) #f guile (define c '()) guile (define d '()) guile (eq? c d) #t '(4 5) is a literal list, and thus a is not eq? to b, although it is equal? to b On the other hand, c is eq? to d, because '() is a constant, and both c and d are set to the same constant. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
Carl Sorensen c_soren...@byu.edu writes: On 8/28/09 10:56 PM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On Aug 28, 2009, at 1:16 PM, Nicolas Sceaux nicolas.sce...@free.fr wrote: According to R5RS, it is an error to modify a literal list. If a function returns '(), the caller won't be allowed to apply a modifying function on the result (eg. append!) IIUC, '() is not a literal list, but a constant that represents the empty list. It is a literal list in my opinion, but one that happens to have no unique and/or modifiable conses. Append will work just fine on it. It is *not* a literal list. Here is the proof: guile (define a '(4 5)) guile (define b '(4 5)) guile (eq? a b) #f guile (define c '()) guile (define d '()) guile (eq? c d) #t '(4 5) is a literal list, and thus a is not eq? to b, although it is equal? to b Huh? What kind of argument is that supposed to be? (define a 4) (define b 4) (eq? a b) Would you claim that 4 is not a literal integer? '() is literal (namely explicitly specified) and it is a list (namely a cons or nil). '() is not a literal _cons_, and it is not unique. But it certainly is literal (a spelled out value) and a list. On the other hand, c is eq? to d, because '() is a constant, and both c and d are set to the same constant. I think you are just confused about the meaning of literal. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
Le 27 août 09 à 22:38, Neil Puttock a écrit : 2009/8/26 Carl Sorensen c_soren...@byu.edu: The patch looks good to me. Cheers. You code the empty list as (list). I typically code the empty list as '(). It there a preference? I suspect that we ought to be consistent, although it's not highly important. It could be part of the code janitor work, though. It's just something I noticed in a few places internally (these all seem to be changes made by Nicolas) and thought it was clearer, though admittedly I haven't been particularly consistent when deciding between the two forms. :) According to R5RS, it is an error to modify a literal list. If a function returns '(), the caller won't be allowed to apply a modifying function on the result (eg. append!) However, guile does not report modifying a literal list as an error, and actually modifies it, so this is somewhat rhetorical. nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
On Aug 28, 2009, at 1:16 PM, Nicolas Sceaux nicolas.sce...@free.fr wrote: According to R5RS, it is an error to modify a literal list. If a function returns '(), the caller won't be allowed to apply a modifying function on the result (eg. append!) IIUC, '() is not a literal list, but a constant that represents the empty list. However, guile does not report modifying a literal list as an error, and actually modifies it, so this is somewhat rhetorical. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
Carl Sorensen c_soren...@byu.edu writes: On Aug 28, 2009, at 1:16 PM, Nicolas Sceaux nicolas.sce...@free.fr wrote: According to R5RS, it is an error to modify a literal list. If a function returns '(), the caller won't be allowed to apply a modifying function on the result (eg. append!) IIUC, '() is not a literal list, but a constant that represents the empty list. It is a literal list in my opinion, but one that happens to have no unique and/or modifiable conses. Append will work just fine on it. However, guile does not report modifying a literal list as an error, and actually modifies it, so this is somewhat rhetorical. It is not rhetorical since a modified literal list will actually stay modified when you call the function the next time. Can't happen with '() though. guile (define (weird) (append! '(4) '(5))) guile (weird) (4 5) guile (weird) (4 5 . #1#) guile (weird) Backtrace: In standard input: 7: 0* [weird] 4: 1 [append! (4 5 . #1#) (5 . #0#)] standard input:4:17: In procedure last-pair in expression (append! (quote #) (quote #)): standard input:4:17: Circular structure in position 1: (4 5 . #1#) ABORT: (misc-error) guile -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
2009/8/26 Carl Sorensen c_soren...@byu.edu: The patch looks good to me. Cheers. You code the empty list as (list). I typically code the empty list as '(). It there a preference? I suspect that we ought to be consistent, although it's not highly important. It could be part of the code janitor work, though. It's just something I noticed in a few places internally (these all seem to be changes made by Nicolas) and thought it was clearer, though admittedly I haven't been particularly consistent when deciding between the two forms. :) Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Move ambitus print callback to scheme.
LGTM I still indentation diffs though. http://codereview.appspot.com/110047 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Move ambitus print callback to scheme.
2009/8/26 hanw...@gmail.com: I still indentation diffs though. OK, I've redone the indentation in ambitus-engraver.cc using hard tabs to match the current behaviour. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
On 8/25/09 2:28 PM, Neil Puttock n.putt...@gmail.com wrote: Hi, I've just posted a revised patchset which deals with Han-Wen's comments. http://codereview.appspot.com/110047/show The patch looks good to me. I have a question about style, though. You code the empty list as (list). I typically code the empty list as '(). It there a preference? I suspect that we ought to be consistent, although it's not highly important. It could be part of the code janitor work, though. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
'() is preferred, as it evaluates to a constant. (list) is a function call, which might mean different things if you override the definition of list. On Wed, Aug 26, 2009 at 5:43 PM, Carl Sorensenc_soren...@byu.edu wrote: You code the empty list as (list). I typically code the empty list as '(). It there a preference? I suspect that we ought to be consistent, although it's not highly important. It could be part of the code janitor work, though. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
Hi, I've just posted a revised patchset which deals with Han-Wen's comments. http://codereview.appspot.com/110047/show Thanks, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Move ambitus print callback to scheme.
Reviewers: hanwenn, Message: On 2009/08/20 03:12:26, hanwenn wrote: http://codereview.appspot.com/110047/diff/1/11 File scm/output-lib.scm (right): http://codereview.appspot.com/110047/diff/1/11#newcode778 Line 778: (ly:grob-suicide! grob) this does not make sense. did you forget to check the length of the noteheads array? - why would someone not set join-heads? I don't know; I just copied it from the C++ code. Since it's possible to hide the line using 'transparent or 'stencil, I guess it's pretty much redundant anyway. http://codereview.appspot.com/110047/diff/1/11#newcode782 Line 782: (head-up (ly:grob-array-ref heads 1)) you need to check the length of the array I thought this would be unnecessary, since the array must have two elements ordered by pitch if the pitch interval isn't empty; otherwise the engraver suicides the AmbitusLine. Of course, if you prefer, I'll add a check using ly:grob-array-length. http://codereview.appspot.com/110047/diff/1/11#newcode795 Line 795: (x-ext (cons (/ (- width) 2) (/ width 2))) this looks like a nice candidate for a small function (symmetric-interval (/ width 2)) OK. http://codereview.appspot.com/110047/diff/1/11#newcode801 Line 801: (ly:grob-suicide! grob)) it would be nice to explicitly return something, eg '() in the suicide case - with all the nesting it is hard to tell what the final result is. OK. Thanks, Neil Description: Move ambitus print callback to scheme. * implement ambitus::print callback in output-lib.scm * add interface description to define-grob-interfaces.scm * allow user override of padding using grob property 'gap * move 'join-heads to user properties * remove ambitus.cc/.hh * tidy ambitus-engraver.cc * add regression test for 'gap * add convert rule for ly:ambitus::print Please review this at http://codereview.appspot.com/110047 Affected files: A input/regression/ambitus-gap.ly M input/regression/ambitus.ly M lily/ambitus-engraver.cc M lily/ambitus.cc M lily/include/ambitus.hh M python/convertrules.py M scm/define-grob-interfaces.scm M scm/define-grob-properties.scm M scm/define-grobs.scm M scm/output-lib.scm M scm/safe-lily.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Move ambitus print callback to scheme
Hi, Please review this patch, which implements ambitus::print in output-lib.scm and removes the hard-coded ambitus length via the property 'gap. http://codereview.appspot.com/110047/show Thanks, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Move ambitus print callback to scheme.
Nice to see this type of code migrate to Scheme. http://codereview.appspot.com/110047/diff/1/11 File scm/output-lib.scm (right): http://codereview.appspot.com/110047/diff/1/11#newcode778 Line 778: (ly:grob-suicide! grob) this does not make sense. did you forget to check the length of the noteheads array? - why would someone not set join-heads? http://codereview.appspot.com/110047/diff/1/11#newcode782 Line 782: (head-up (ly:grob-array-ref heads 1)) you need to check the length of the array http://codereview.appspot.com/110047/diff/1/11#newcode795 Line 795: (x-ext (cons (/ (- width) 2) (/ width 2))) this looks like a nice candidate for a small function (symmetric-interval (/ width 2)) http://codereview.appspot.com/110047/diff/1/11#newcode801 Line 801: (ly:grob-suicide! grob)) it would be nice to explicitly return something, eg '() in the suicide case - with all the nesting it is hard to tell what the final result is. http://codereview.appspot.com/110047 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Split ambitus engraver?
Hi, I use Lilypond to make diagrams of all the available notes on an accordion. For that I use a single system and switch from bass clef to violin clef (and it would also be feasible to use 8va and 8ve modifiers). Now the problem is that the ambitus is engraved using the first clef of the system, in this case the bass clef, and the upper range is just somewhere in the clouds. In this case it would be nicer if the ambitus were engraved with the actually used clefs for upper and lower range, so that one first depicts the lower part of the range (presumably with a dotted line at the top of the broken off ambitus line a bit above the system to indicate it reaching higher) with its original clef in smaller size, and then the upper range of the ambitus with its original clef in smaller size (with a corresponding dotted line pointing downwards to indicate it reaching some indefinite distance lower). If that is not comprehensible, I can try making a sketch and photographing it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Shouldn't the ambitus engraver prefer his key signature?
Anthony W. Youngman lilyp...@thewolery.demon.co.uk writes: In message 863aeipe74@lola.quinscape.zz, David Kastrup d...@gnu.org writes Hi, the ambitus engraver seemingly picks the first maximum/minimum in the note sequence and stays with it even when the same absolute pitch comes up later with a better match to the ambitus engraver's key signature. Here is a real world example where the ambitus engraver (which is working in C major) picks c flat rather than b as its lowest span. Ugly. Not that I use ambituses, but surely, where there multiple notes of the same pitch (I hate to say absolute pitch, because to take the above example c-flat and b-natural are NOT the same pitch except on the piano), Ambitus engravings are for expressing physical limits. I can't think of a tuning/instrument where enharmonic relations could make a difference. it makes sense to take the lowest (or highest, as appropriate) note - b over c. No. The ambitus should definitely orient itself with its key signature: it makes no sense using accidentals when a natural pitch is there. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Shouldn't the ambitus engraver prefer his key signature?
Hi,
the ambitus engraver seemingly picks the first maximum/minimum in the
note sequence and stays with it even when the same absolute pitch comes
up later with a better match to the ambitus engraver's key signature.
Here is a real world example where the ambitus engraver (which is
working in C major) picks c flat rather than b as its lowest span.
Ugly.
\include deutsch.ly
\new Voice \with {\consists Ambitus_engraver}
{
\clef bass
\key c \major
#(set-accidental-style (quote forget))
\set Staff.printKeyCancellation = ##f
\override Staff.TimeSignature #(quote stencil) = ##f
\partial 64
\skip64
\bar
\key des \major
des, f, as,^\markup{\concat{d\super\flat }}
des, fes, as,^\markup{\concat{d\super\flat m}}
des, f, ces,^\markup{\concat{d\super\flat 7}}
des, fes, b,^\markup{\concat{d\super\flat 0}}
\key as \major
as, c, es,^\markup{\concat{a\super\flat }}
as, ces, es,^\markup{\concat{a\super\flat m}}
as, c, ges,^\markup{\concat{a\super\flat 7}}
as, ces, f,^\markup{\concat{a\super\flat 0}}
\key es \major
es, g, b,^\markup{\concat{e\super\flat }}
es, ges, b,^\markup{\concat{e\super\flat m}}
es, g, des,^\markup{\concat{e\super\flat 7}}
es, ges, c,^\markup{\concat{e\super\flat 0}}
\key b \major
b, d, f,^\markup{\concat{b}}
b, des, f,^\markup{\concat{bm}}
b, d, as,^\markup{\concat{b7}}
b, des, g,^\markup{\concat{b0}}
\key f \major
f, a, c,^\markup{\concat{f}}
f, as, c,^\markup{\concat{fm}}
f, a, es,^\markup{\concat{f7}}
f, as, d,^\markup{\concat{f0}}
\key c \major
c, e, g,^\markup{\concat{c}}
c, es, g,^\markup{\concat{cm}}
c, e, b,^\markup{\concat{c7}}
c, es, a,^\markup{\concat{c0}}
\key g \major
g, h,, d,^\markup{\concat{g}}
g, b, d,^\markup{\concat{gm}}
g, h,, f,^\markup{\concat{g7}}
g, b, e,^\markup{\concat{g0}}
\key d \major
d, fis, a,^\markup{\concat{d}}
d, f, a,^\markup{\concat{dm}}
d, fis, c,^\markup{\concat{d7}}
d, f, h,,^\markup{\concat{d0}}
\key a \major
a, cis, e,^\markup{\concat{a}}
a, c, e,^\markup{\concat{am}}
a, cis, g,^\markup{\concat{a7}}
a, c, fis,^\markup{\concat{a0}}
\key e \major
e, gis, h,,^\markup{\concat{e}}
e, g, h,,^\markup{\concat{em}}
e, gis, d,^\markup{\concat{e7}}
e, g, cis,^\markup{\concat{e0}}
\key h \major
h,, dis, fis,^\markup{\concat{h}}
h,, d, fis,^\markup{\concat{hm}}
h,, dis, a,^\markup{\concat{h7}}
h,, d, gis,^\markup{\concat{h0}}
\key fis \major
fis, ais, cis,^\markup{\concat{f\super\sharp }}
fis, a, cis,^\markup{\concat{f\super\sharp m}}
fis, ais, e,^\markup{\concat{f\super\sharp 7}}
fis, a, dis,^\markup{\concat{f\super\sharp 0}}
}
The output looks as follows:
inline: tones.png
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Shouldn't the ambitus engraver prefer his key signature?
In message 863aeipe74@lola.quinscape.zz, David Kastrup d...@gnu.org writes Hi, the ambitus engraver seemingly picks the first maximum/minimum in the note sequence and stays with it even when the same absolute pitch comes up later with a better match to the ambitus engraver's key signature. Here is a real world example where the ambitus engraver (which is working in C major) picks c flat rather than b as its lowest span. Ugly. Not that I use ambituses, but surely, where there multiple notes of the same pitch (I hate to say absolute pitch, because to take the above example c-flat and b-natural are NOT the same pitch except on the piano), it makes sense to take the lowest (or highest, as appropriate) note - b over c. Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cautionary accidentals in Ambitus
Here's an ugly workaround:
\score{
\relative c {
\clef bass
\once \override Staff.Clef #'stencil = ##f
\once \override Staff.TimeSignature #'stencil = ##f
\partial 4
s4
\bar
\set Staff.forceClef = ##t
\once \override Staff.Clef #'full-size-change = ##t
\time 4/4
\clef bass
\key des \major
des aes des aes |
}
\layout{
\context {
\Voice
\consists Ambitus_engraver
}
}
}
/Mats
Cameron Horsburgh wrote:
Hi folks,
I've recently written a timpani part for a score I'm writing, and I thought I'd
add an ambitus to the beginning of the part to show the necessary tuning (I
know, it's not standard!)
The two notes I want the timps tuned to are aes and des, and the key is des
major. However, because the key signature (which comes _after_ the ambitus)
includes aes and des there are no flats on the ambitus. How do I add cautionary
accidentals?
I notice in the programme reference that Ambitus_engraver has a setting for
cautionary accidentals, but it doesn't tell me how to turn them on or off.
Here's a simple version of my code:
\version 2.9.4
\score{
\relative c {
\clef bass
\key des \major
des aes des aes |
}
\layout{
\context {
\Voice
\consists Ambitus_engraver
}
}
}
--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Cautionary accidentals in Ambitus
Hi folks,
I've recently written a timpani part for a score I'm writing, and I thought I'd
add an ambitus to the beginning of the part to show the necessary tuning (I
know, it's not standard!)
The two notes I want the timps tuned to are aes and des, and the key is des
major. However, because the key signature (which comes _after_ the ambitus)
includes aes and des there are no flats on the ambitus. How do I add cautionary
accidentals?
I notice in the programme reference that Ambitus_engraver has a setting for
cautionary accidentals, but it doesn't tell me how to turn them on or off.
Here's a simple version of my code:
\version 2.9.4
\score{
\relative c {
\clef bass
\key des \major
des aes des aes |
}
\layout{
\context {
\Voice
\consists Ambitus_engraver
}
}
}
--
=
Cameron Horsburgh
/dev/random says:
Dinner not ready: (A)bort (R)etry (P)izza
http://web.netcall.com.au/horsburgh
_ _ _ _ _
/ ___| _ __ ___ (_) | ___| | | |
\___ \| '_ ` _ \| | |/ _ \ | | |
___) | | | | | | | | __/_|_|_|
|/|_| |_| |_|_|_|\___(_|_|_)
=
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cautionary accidentals in Ambitus
Hi,When I write timpani parts I specify the tuning this way:tuning = \markup { \score { \new Staff \with { \remove Time_signature_engraver } { \set Staff.instrument = Tuning:
\clef bass { b,4 d e a } } \layout { ragged-right = ##t } }}\header { poet = \markup { \tuning }}I know it doesn't answer your question, but I thought you might find it interesting anyway.
Regards, Erlend AaslandOn 5/20/06, Cameron Horsburgh [EMAIL PROTECTED] wrote:
Hi folks,I've recently written a timpani part for a score I'm writing, and I thought I'd add an ambitus to the beginning of the part to show the necessary tuning (I know, it's not standard!)
The two notes I want the timps tuned to are aes and des, and the key is des major. However, because the key signature (which comes _after_ the ambitus) includes aes and des there are no flats on the ambitus. How do I add cautionary accidentals?
I notice in the programme reference that Ambitus_engraver has a setting for cautionary accidentals, but it doesn't tell me how to turn them on or off.Here's a simple version of my code:\version
2.9.4\score{\relative c {\clef bass\key des \majordes aes des aes |}\layout{\context {\Voice\consists Ambitus_engraver}
}}--=Cameron Horsburgh/dev/random says:Dinner not ready: (A)bort (R)etry (P)izzahttp://web.netcall.com.au/horsburgh
_ __ _ _/ ___| _ __ ___ (_) | ___| | | |\___ \| '_ ` _ \| | |/ _ \ | | | ___) | | | | | | | |__/_|_|_||/|_| |_| |_|_|_|\___(_|_|_)=
___lilypond-devel mailing listlilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[bug] Ambitus broken as of 2.5.2
Hi! On the lilypond.org website, in section 5.11.7 of the notation manual, version 2.5.2, ambitus does not show noteheads. Maybe, this is also related to the introduction of the symmetric/up/down noteheads in 2.5.2? BTW., not only my Latin dictionary, but also Webster's says that the plural of ambitus is ambitus (with long u), not ambits. Greetings, Jürgen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
ambitus
[EMAIL PROTECTED] writes: This really hurts: fixed. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
ambitus
This really hurts: The term ambitus (plural: ambituses) denotes a range of pitches for ^ a given voice in a part of music. It also may denote the pitch range that a musical instrument is capable of playing. The plural of `ambitus' is `ambitus'. According to http://www.dolmetsch.com/defsa.htm a possible translation to English is `ambit' which would have `ambits' as the plural. Cf. http://encarta.msn.com/dictionary_1861585057/ambit.html. Werner ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Bugfix: Ambitus (Was: Re: ambitus and G_8)
Juergen == Juergen Reuter [EMAIL PROTECTED] writes: Juergen On 11 Jul 2002, Laura Conrad wrote: When I print the attached file, the ambitus is an octave too high. It may be something wierd I'm doing, since I've seen the ambitus engraver work on other files with a G_8 clef, but I don't see what. Juergen Should be fixed with the attached diff. Thanks, it seems to be working fine now. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139 ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Bugfix: Ambitus (Was: Re: ambitus and G_8)
On 11 Jul 2002, Laura Conrad wrote:
When I print the attached file, the ambitus is an octave too high. It
may be something wierd I'm doing, since I've seen the ambitus engraver
work on other files with a G_8 clef, but I don't see what.
Should be fixed with the attached diff. Actually, this was not a problem
with some specific clefs, but rather yet another problem related to the
start/stop_translation_timestep() anomaly (lily may issue a
stop_translation_timestep() before having issued a
start_translation_timestep()).
BTW., your file produces (at least on my machine here) many errors like:
programming error: empty break column? --fixme (Continuing; cross thumbs)
programming error: No spacing entry from LeftEdge to `custos' (Continuing;
cross thumbs)
The latter can be avoided by adding
(custos . (extra-space . 0.0))
to the LeftEdge grob in scm/grob-description.scm. However, since I think
the latter message is a result of something else that went wrong and
under normal circumstances this situation should not occur, I decided not
to include this line in my patch.
Greetings,
Juergen
--- lilypond-1.5.69/lily/ambitus-engraver.ccTue Jul 2 01:52:24 2002
+++ lilypond-1.5.69.NEW/lily/ambitus-engraver.ccTue Jul 23 00:51:27 2002
-64,6 +64,7
{
public:
TRANSLATOR_DECLARATIONS(Ambitus_engraver);
+ virtual void process_music ();
virtual void acknowledge_grob (Grob_info);
virtual void stop_translation_timestep ();
virtual void finalize ();
-71,51 +72,65
private:
void create_ambitus ();
Item *ambitus_p_;
- int isActive;
+ int/*bool*/ is_typeset;
Pitch pitch_min, pitch_max;
};
Ambitus_engraver::Ambitus_engraver ()
{
- ambitus_p_ = 0; isActive = 0;
+ ambitus_p_ = 0;
+ is_typeset = 0;
- // (pitch_min pitch_max) means that pitches are not yet
- // initialized
+ /*
+ * (pitch_min pitch_max) means that pitches are not yet
+ * initialized
+ */
pitch_min = Pitch (0, 0, +1);
pitch_max = Pitch (0, 0, -1);
}
void
-Ambitus_engraver::stop_translation_timestep ()
+Ambitus_engraver::process_music ()
{
+ /*
+ * Ensure that ambitus is created in the very first timestep (on
+ * which lily does not call start_translation_timestep ()).
+ * Otherwise, if a voice begins with a rest, the ambitus grob will
+ * be placed after the rest.
+ */
if (!ambitus_p_) {
-// Create ambitus not before stopping timestep. centralCPosition
-// will then be the same as that for the first timestep.
-//
-// TODO: is this really a good idea? At least, creating the
-// ambitus in start_translation_timestep is a *bad* idea, since we
-// may then oversee a clef that is defined in a staff context if
-// we are in a voice context; centralCPosition would then be
-// assumed to be 0.
create_ambitus ();
}
- if (ambitus_p_ isActive)
+}
+
+void
+Ambitus_engraver::stop_translation_timestep ()
+{
+ if (ambitus_p_ !is_typeset)
{
+ /*
+ * Evaluate centralCPosition not until now, since otherwise we
+ * may then oversee a clef that is defined in a staff context if
+ * we are in a voice context; centralCPosition would then be
+ * assumed to be 0.
+ */
+ SCM c0 = get_property (centralCPosition);
+ ambitus_p_-set_grob_property (centralCPosition, c0);
+
+ /*
+ * Similar for keySignature.
+ */
SCM key_signature = get_property (keySignature);
ambitus_p_-set_grob_property (keySignature, key_signature);
+
typeset_grob (ambitus_p_);
- isActive = 0;
+ is_typeset = 1;
}
}
void
Ambitus_engraver::acknowledge_grob (Grob_info info)
{
- if (!ambitus_p_) {
-create_ambitus ();
- }
- if (!ambitus_p_)
-return;
Item *item = dynamic_cast Item *(info.grob_l_);
if (item)
{
-148,9 +163,7
Ambitus_engraver::create_ambitus ()
{
SCM basicProperties = get_property (Ambitus);
- SCM c0 = get_property (centralCPosition);
- ambitus_p_ = new Item (basicProperties); isActive = 1;
- ambitus_p_-set_grob_property (centralCPosition, c0);
+ ambitus_p_ = new Item (basicProperties); is_typeset = 0;
announce_grob (ambitus_p_, SCM_EOL);
}
-168,9 +181,11
}
else // have not seen any pitch, so forget about the ambitus
{
- // Do not print a warning on empty ambitus range, since this
- // most probably arises from an empty voice, such as shared
- // global timesig/clef definitions.
+ /*
+ * Do not print a warning on empty ambitus range, since this
+ * most probably arises from an empty voice, such as shared
+ * global timesig/clef definitions.
+ */
#if 0
ambitus_p_-warning(empty ambitus range [ignored]);
#endif
[PATCH] Bugfix: Ambitus (Was: Re: ambitus and G_8)
[EMAIL PROTECTED] writes: Should be fixed with the attached diff. Actually, this was not a problem with some specific clefs, but rather yet another problem related to the thanks, applied. BTW., your file produces (at least on my machine here) many errors like: programming error: empty break column? --fixme (Continuing; cross Thumbs) I've removed this error message -- it is triggered far too often, and people will send in reports on anomalous spaces anyway. (custos . (extra-space . 0.0)) to the LeftEdge grob in scm/grob-description.scm. However, since I think the latter message is a result of something else that went wrong and under normal circumstances this situation should not occur, I decided not to include this line in my patch. It happens when you have breakpoints without barlines. I added your entry. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.cs.uu.nl/~hanwen ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus and G_8
On 11 Jul 2002, Laura Conrad wrote: When I print the attached file, the ambitus is an octave too high. It may be something wierd I'm doing, since I've seen the ambitus engraver work on other files with a G_8 clef, but I don't see what. Sounds as if for some reason the clef is not seen from within the voice context. The next couple of days I am quite buisy, but I'll nevertheless try to have a look at it this weekend. Greetings, Juergen ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus questions
On 11 Jul 2002, Laura Conrad wrote: I'm enjoying using the new ambitus engraver; it's fun having that information available by default, without having to do the stuff my incipit-writing script does to get it from the MIDI file. Thanks. It's always nice to hear that a new feature is actually used. :-) My first reaction looking at it is that it's a little too close to the clef. Is this something that can be fixed either by default or by tuning some parameter? Yes, this is one of a couple of known issues regarding spacing and collision handling (see comments in lily/ambitus*.cc for details). You may try to tweak some of the space-alist values (search for ambitus in scm/grob-description.scm), and (depending on breakAlignOrder) maybe also the values of default-break-align-space-alist in scm/basic-properties.scm, but I think I already played around with them with limited success. One of my plans for my website redesign is to have each piece have it's own page, with the incipit for each part. To generate these automatically, I need a way to print the ambitus of a set of notes without printing all the notes. I can think of some things to play with; has anyone solved the problem yet? This currently would require to manually override properties pitch-min and pitch-max in Voice.Ambitus just immediately before outputting the grobs. I think you can do something like that with the \outputproperty directive, but I do not know the details of this command. For the long term, I strive to implement support for automatically generating incipits: the user simply defines the ancient clef, key etc. via properties of an incipit grob; the music (by default from the start of the piece to the first note, including lyrics) should automatically copied by the incipit engraver, with the ancient clef, key, etc. applied to them. But this is just an idea for now; there are many unsolved problems (e.g. copying music during the interpretation phase). Greetings, Juergen ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
ambitus and G_8
When I print the attached file, the ambitus is an octave too high. It may be something wierd I'm doing, since I've seen the ambitus engraver work on other files with a G_8 clef, but I don't see what. tenor.ly Description: Binary data -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139
Re: [PATCH] ambitus engraver
Juergen Reuter [EMAIL PROTECTED] writes: Sorry for the long delay of several weeks; but I still have severe teTeX problems since lily 1.5.59. Currently, I have to manually tweak TEXMF and TEXINPUTS and/or set up various symbolic links to work around font problems. Do you run lilypond from the build directory, or do you install it? There were bugs in both procedures. In any case, setting TEXMF should be enough now, as long as TEXINPUTS et al. are not set, or not set to wrong values. Running lilypond from the build dir should now (.62) be as easy as: ./configure; make export TEXMF=$(pwd)/share/lilypond/version # build dir version # export /usr/share/lilypond/version# installed version unset LILYPONDPREFIX unset MFINPUTS unset TEXINPUT unset TFMFONTS Btw, if 'make web' runs ok, you can always peek how it works. Variables for running lilypond from the build directory are set in ./make/lilypond-vars.make. Another thing: make distclean does not remove directory share in the top level directory. Is this a bug or intended behaviour? Bug, fixed in CVS. Thanks. Greetings, Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] ambitus engraver
Running lilypond from the build dir should now (.62) be as easy as: ./configure; make export TEXMF=$(pwd)/share/lilypond/version # build dir version This is nonsence. If the TEXMF variable doesn't include the default teTeX texmf tree, TeX or LaTeX won't be able to find any of the standard package files. Use a setting similar to the one in buildscripts/out/lilypond-profile instead. Also, since the build directory doesn't match the standard TeX directory structure (see `texdoc tds`), tex/latex won't find any of the font files or other necessary files. /Mats ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] ambitus engraver
Mats Bengtsson [EMAIL PROTECTED] writes:
This is nonsence. If the TEXMF variable doesn't include
the default teTeX texmf tree, TeX or LaTeX won't be able
to find any of the standard package files.
Oops. So, make that:
TEXMF={$(pwd)/lilypond/share/lilypond/version, $(kpsexpand \$TEXMF)}
Use a setting similar to the one in buildscripts/out/lilypond-profile
instead.
Yes, but I just wanted to mention that (wrong) TEXINPUTS, TFMFONTS,
MFINPUTS, override a (correct) TEXMF and still break things.
Also, since the build directory doesn't match the
standard TeX directory structure (see `texdoc tds`),
tex/latex won't find any of the font files or other
necessary files.
How is that? .62/latest CVS should create a valid tds in the build
directory, but I'm not a guru at this (as my prev post also shows).
Jan.
--
Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] ambitus engraver
Also, since the build directory doesn't match the standard TeX directory structure (see `texdoc tds`), tex/latex won't find any of the font files or other necessary files. How is that? .62/latest CVS should create a valid tds in the build directory, but I'm not a guru at this (as my prev post also shows). I don't think! You can read in `kpsewhich texmf.cnf` where the different file types are searched. If $TEXMF is the root of the TDS-compliant tree (in this case the build directory), then .mf files will only be searched below $TEXMF/fonts/source/ or $TEXMF/metafont/, for example. Also, the files mf/out/feta*.tex have to be in some directory where tex/latex searches for input files. /Mats ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] ambitus engraver
On Wed, 26 Jun 2002, Jan Nieuwenhuizen wrote:
Mats Bengtsson [EMAIL PROTECTED] writes:
This is nonsence. If the TEXMF variable doesn't include
the default teTeX texmf tree, TeX or LaTeX won't be able
to find any of the standard package files.
Oops. So, make that:
TEXMF={$(pwd)/lilypond/share/lilypond/version, $(kpsexpand \$TEXMF)}
That will not work either. The problem is, that on some distributions
TEXMF is not at all set, but tex will still find its own files (I guess
by evaluating $0 from the invoking shell before actually running tex).
However, *if* TEXMF is set to some value, it must include the tex
installation path.
It does work (at least if you use this method to point to
the installation directory). The trick is that
'kpsexpand \$TEXMF' reads the value from texmf.cnf if the
environment variable $TEXMF is undefined. This is exactly the
method used in Lilypond since 1.5.4x.
Use a setting similar to the one in buildscripts/out/lilypond-profile
instead.
Yes, but I just wanted to mention that (wrong) TEXINPUTS, TFMFONTS,
MFINPUTS, override a (correct) TEXMF and still break things.
Also, since the build directory doesn't match the
standard TeX directory structure (see `texdoc tds`),
tex/latex won't find any of the font files or other
necessary files.
How is that? .62/latest CVS should create a valid tds in the build
directory, but I'm not a guru at this (as my prev post also shows).
Jan.
I am neither a TeX guru, but my TEXMF has to include at least both,
the install_dir/share/lilypond/1.5.63/fonts *and* the
install_dir/share/lilypond/1.5.63/fonts/afm directory (and probably
also the fonts/source directory, if the fonts have not yet been compiled)
to work. So I guess, there is something wrong with the directory
structure.
Yes, the build directory is definitely not according to TDS.
I also would prefer a structure of the form
install_dir/share/lilypond-1.5.63 rather than
install_dir/share/lilypond/1.5.63, because with the former I ran into
difficulties when using symlinks: I made a symlink 1.5.63 - ., and
/usr/share/directory_where_lily_fonts_usually_go -
/home/reuter/lilypond/share/lilypond and /home/reuter/lilypond -
install_dir. This made (until 1.5.58) it possible to change between
various lilypond installations on the fly by just changing the single link
/home/reuter/lilypond to point to the current version. However, the
symlink 1.5.63 - . turned out to be harmful, because the next time the
tex file database is automatically updated, this leads to endless
recursive file path. As a result, I got a huge cache file in the texmf/db
directory (ca. 20MB), which caused a delay of a some minutes each time
invoking any tex related command...
What I have done is to run directly from the build directory,
using a local texmf-like directory with soft links to the
corresponding directories in the build directory.
As a starting point, I use a directory structure as described
in http://lilypond.org/wiki/?MakingPatches with a soft link
'lilypond' pointing to the build directory of the current
version. In the directory above the build directories, I also
have a directory 'localtexmf' with the following contents:
localtexmf/dvips - ../lilypond/mf/out/
localtexmf/fonts/source - ../../lilypond/mf/
localtexmf/fonts/afm - ../../lilypond/mf/out/
localtexmf/fonts/pk - ../../lilypond/mf/out/
localtexmf/fonts/tfm - ../../lilypond/mf/out/
localtexmf/fonts/type1 - ../../lilypond/mf/out/
localtexmf/tex/
localtexmf/tex/fetadefs - ../../lilypond/mf/out/
localtexmf/tex/tex - ../../lilypond/tex/
where '-' denotes a soft link.
With this setup, I can easily change between versions by just
moving the single link 'lilypond'.
/Mats
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] ambitus engraver
Mats Bengtsson [EMAIL PROTECTED] writes:
Yes, the build directory is definitely not according to TDS.
[..]
What I have done is to run directly from the build directory,
using a local texmf-like directory with soft links to the
corresponding directories in the build directory.
Uh, we *are* talking about
TEXMF={$(pwd)/share/lilypond/version, $(kpsexpand \$TEXMF)}
ie,
build-dir/share/lilypond/version
that's created by
make builddir-setup
right?
It seems I didn't read every line of the ChangeLog recently,
so I hadn't noticed this new feature. Sorry about the
confusion.
Since I will keep setting a link lilypond to point to the
current build-dir and I'd prefer to get all settings correct
by just changing this single link, I'd actually prefer if the
directory was build-dir/share/lilypond/, i.e. with no
version specific path name except for the build directory
itself. Did you have any special reason to add that extra
directory level?
/Mats
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] ambitus engraver
On Wed, 26 Jun 2002, Mats Bengtsson wrote: ... Since I will keep setting a link lilypond to point to the current build-dir and I'd prefer to get all settings correct by just changing this single link, I'd actually prefer if the directory was build-dir/share/lilypond/, i.e. with no version specific path name except for the build directory itself. I fully agree, for the same reasons. :-) Greetings, Juergen ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] ambitus engraver
Mats Bengtsson [EMAIL PROTECTED] writes: Since I will keep setting a link lilypond to point to the current build-dir and I'd prefer to get all settings correct by just changing this single link, Yes. I had that setup too, and I thought it sucked, because you can't run 1.4 and 1.5 alongside eachother. Of course, you should use what you like best, but it would be good if the advertised build-dir solution that come with lily, work too. I'd actually prefer if the directory was build-dir/share/lilypond/, i.e. with no version specific path name except for the build directory itself. But that's not convenient, because you *have* to set LILYPONDPREFIX. If you include the version, it's very convenient to have lily's datadir point to the right place, so the executable will work from any terminal. That's handy if you run different lily versions all the time. The datadir includes the version, for reasons below. Did you have any special reason to add that extra directory level? Yes, it's the more standard thing to do if you want to support different versions to be installed. Having /usr/[local/]share/lilypond/version enables you to install and run several /usr/bin/lilypond-version alongside eachother. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] ambitus engraver
Hi, all!
Here finally comes the ambitus engraver. Sorry for the long delay of
several weeks; but I still have severe teTeX problems since lily 1.5.59.
Currently, I have to manually tweak TEXMF and TEXINPUTS and/or set up
various symbolic links to work around font problems.
This is the last new feature that I wanted to be put in before 1.6. Now I
am going to fix/enhance broken things like time signature and baroque
notehead style.
BTW., to solve the time signature problems, I still would like to
extend the \time syntax. However, since my original proposal was
considered being too over-engineered (and anyway would take too much time
for 1.6), I would like to implement a small solution, adding syntax of the
form \time n[a:b]/d (as an optional extension of the current form \time
n/d) just to be able to address shapes C and O including their
slashed and dotted variants. Would that be ok?
Another thing: make distclean does not remove directory share in the
top level directory. Is this a bug or intended behaviour?
Greetings,
Juergen
diff -Naur lilypond-1.5.63/ChangeLog lilypond-1.5.63.NEW/ChangeLog
--- lilypond-1.5.63/ChangeLog Mon Jun 24 01:26:22 2002
+++ lilypond-1.5.63.NEW/ChangeLog Tue Jun 25 22:24:35 2002
@@ -1,3 +1,10 @@
+2002-06-25 Juergen Reuter [EMAIL PROTECTED]
+
+ * input/test/ambitus.ly, lily/ambitus-engraver.cc,
+ lily/ambitus.cc, lily/include/ambitus.hh, ly/engraver-init.ly,
+ scm/basic-properties.scm, scm/grob-description.scm,
+ scm/grob-property-description.scm: added support for ambitus
+
2002-06-24 Han-Wen [EMAIL PROTECTED]
* lily/grob-scheme.cc: new file
diff -Naur lilypond-1.5.63/input/test/ambitus.ly
lilypond-1.5.63.NEW/input/test/ambitus.ly
--- lilypond-1.5.63/input/test/ambitus.ly Thu Jan 1 01:00:00 1970
+++ lilypond-1.5.63.NEW/input/test/ambitus.ly Tue Jun 25 22:08:20 2002
@@ -0,0 +1,45 @@
+\version 1.5.49
+
+upper = \notes \relative c {
+ \clef treble
+ \key c \minor
+ as'' c e bes f cis d e f g f e d f d e
+ f d e e d f d e e d f d e e d f d e
+ f d e e d f d e e d f d e e d f d e
+}
+
+lower = \notes \relative c {
+ \clef treble
+ \key e \major
+ e'2 b4 g a c es fis a cis b a g f e d
+ f e d e f g f e d e f g f e d e f g
+ f e d e f g f e d e f g f e d e f g
+}
+
+\score { \context ChoirStaff {
+
+ \context Staff = one { \upper }
+ \context Staff = three { \lower }
+}
+ \paper {
+ \translator {
+ \ScoreContext
+ breakAlignOrder = #'(
+ instrument-name
+ left-edge
+ ambitus
+ span-bar
+ breathing-sign
+ clef
+ key-signature
+ staff-bar
+ time-signature
+ custos
+ )
+ }
+ \translator {
+ \VoiceContext
+ \consists Ambitus_engraver
+ }
+ }
+}
diff -Naur lilypond-1.5.63/lily/ambitus-engraver.cc
lilypond-1.5.63.NEW/lily/ambitus-engraver.cc
--- lilypond-1.5.63/lily/ambitus-engraver.ccThu Jan 1 01:00:00 1970
+++ lilypond-1.5.63.NEW/lily/ambitus-engraver.ccTue Jun 25 20:51:14 2002
@@ -0,0 +1,180 @@
+/*
+ ambitus-engraver.cc -- implement Ambitus_engraver
+
+ source file of the GNU LilyPond music typesetter
+
+ (C) 2002 Juergen Reuter [EMAIL PROTECTED]
+*/
+
+#include engraver.hh
+#include item.hh
+#include note-head.hh
+#include staff-symbol-referencer.hh
+#include musical-request.hh
+#include pitch.hh
+
+/*
+ * This class implements an engraver for ambitus grobs.
+ *
+ * TODO: There are quite some conceptional issues left open:
+ *
+ * - Many publishers put ambitus _before_ the first occurrence of a
+ * clef. Hence, formally the pitches are undefined in this case. Of
+ * course, one could always silently assume that ambitus pitches refer
+ * to the first occurrence of a clef. Or should we, by default, put
+ * the ambitus always after the first clef, if any?
+ *
+ * - Enharmonically equal pitches: Assume piece contains once a gis,
+ * another time an aes as highest pitch. Which one should be
+ * selected for the ambitus grob? The aes, because it is
+ * musically/notationally higher than gis? Or gis, because (if
+ * using pure temperament) it has a slightly higher frequency? Or
+ * that pitch that come closer to the key signature? But there may be
+ * key signature changes in the piece...
+ *
+ * - Multiple voices in single staff: Assume a vocal piece of music,
+ * where the soprano voice and the alto voice are put into the same
