Re: documentation error
Erlend Aasland schreef:
A cool feature would be to have an adlib keyword for the repeat
command. For example you could write a bass part like this:
\new ChordNames \chordmode { c1 g:7 c: a2:m7 d:m7 g:7 }
\new Staff {
\clef bass
\relative c { c4^ e f fis \repeat adlib 3 { g^Walking bass ad.
lib f e d } }
}
This would write notes in the two first bars, and then write slashes
without stems in the last two bars (kind of like \repeat percent).
I could do this as a standard sponsored feature.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tremolo positioning
On Tue, 28 Mar 2006 20:20, Han-Wen Nienhuys wrote:
Han-Wen Nienhuys wrote:
Can you resend the patch using more idiomatic code? Thanks!
Also, can you include a small regression test sample, so it's obvious
when we break something?
I'm not quite sure if we reached a conclusion on the default behaviour of
tremolos and I'm also not quite sure what the protocol is for adding things
to interfaces (I added style to stem-tremolo-interface. It can be
'rectangle or 'default) but here is another try anyway. I also enclose a
regression test and an image of the output.
2006-03-28 Joe Neeman [EMAIL PROTECTED]
* lily/stem-tremolo.cc (print): position
the tremolo depending only on the end of the stem
and not on the notehead
(raw_stencil): center, on the middle staff line, the
flag that is closest to the end of the stem (previously
the bottom flag)
(calc_width): add this callback to shorten a tremolo when
it is beamed or it is stemup with a flag
(style): add this callback to make a tremolo rectangular when
it is beamed or it is stemup with a flag
(rotated_box): this is like Lookup::beam but makes a rotated
rectangle instead of a parallelogram
* lily/stem.cc (calc_stem_info): make sure the stem
is long enough to fit the tremolo
(calc-length): reduce the length of tremolo stems since the
tremolo code is now capable of better positioning
* scm/define-grobs.scm: make calc_width the default beam-width
callback for stem-tremolo and add the style callback
\header {
texidoc = Tremolos are positioned a fixed distance from the
end of the beam. Tremolo flags are shortened and made rectangular
on beamed notes or on stem-up notes with a flag. Tremolo flags are
tilted extra on stem-down notes with a flag.
}
\version 2.9.0
\layout {
ragged-right = ##T
}
\relative c' {
c16:32 e: f: a: c,4:8 c4:32 c8:16 \noBeam c16:32 \noBeam c16:64 |
c''16:32 e: f: a: c,4:8 c4:32 c8:16 \noBeam c16:32 \noBeam c16:64 |
}
Index: lily/include/stem-tremolo.hh
===
RCS file: /sources/lilypond/lilypond/lily/include/stem-tremolo.hh,v
retrieving revision 1.34
diff -u -r1.34 stem-tremolo.hh
--- lily/include/stem-tremolo.hh 10 Feb 2006 01:05:05 - 1.34
+++ lily/include/stem-tremolo.hh 29 Mar 2006 12:28:34 -
@@ -19,9 +19,12 @@
static bool has_interface (Grob *);
DECLARE_SCHEME_CALLBACK (dim_callback, (SCM smob));
DECLARE_SCHEME_CALLBACK (calc_slope, (SCM));
+ DECLARE_SCHEME_CALLBACK (calc_width, (SCM));
DECLARE_SCHEME_CALLBACK (print, (SCM));
DECLARE_SCHEME_CALLBACK (height, (SCM));
- static Stencil raw_stencil (Grob *, Real);
+ DECLARE_SCHEME_CALLBACK (style, (SCM));
+ static Stencil rotated_box (Real slope, Real width, Real thick, Real blot);
+ static Stencil raw_stencil (Grob *, Real, Direction stemdir);
static Real get_beam_translation (Grob *me);
};
Index: lily/stem.cc
===
RCS file: /sources/lilypond/lilypond/lily/stem.cc,v
retrieving revision 1.304
diff -u -r1.304 stem.cc
--- lily/stem.cc 2 Mar 2006 10:50:40 - 1.304
+++ lily/stem.cc 29 Mar 2006 12:28:35 -
@@ -335,17 +335,21 @@
+ 2 * t_flag-extent (t_flag, Y_AXIS).length ()
/ ss;
+ /* We don't want to add the whole extent of the flag because the trem
+ and the flag can overlap partly. beam_translation gives a good
+ approximation */
if (durlog = 3)
- {
- Interval flag_ext = flag (me).extent (Y_AXIS);
- if (!flag_ext.is_empty ())
- minlen += 2 * flag_ext.length () / ss;
-
- /* The clash is smaller for down stems (since the tremolo is
- angled up.) */
- if (dir == DOWN)
- minlen -= 1.0;
- }
+{
+ Real beam_trans = Stem_tremolo::get_beam_translation (t_flag);
+ /* the obvious choice is (durlog - 2) here, but we need a bit more space. */
+ minlen += 2 * (durlog - 1.5) * beam_trans;
+
+ /* up-stems need even a little more space to avoid collisions. This
+ needs to be in sync with the tremolo positioning code in
+ Stem_tremolo::print */
+ if (dir == UP)
+minlen += beam_trans;
+}
length = max (length, minlen + 1.0);
}
@@ -798,7 +802,6 @@
return si;
}
-/* TODO: add extra space for tremolos! */
MAKE_SCHEME_CALLBACK(Stem, calc_stem_info, 1);
SCM
Stem::calc_stem_info (SCM smob)
@@ -847,6 +850,13 @@
* staff_space
* length_fraction;
+ Real height_of_my_trem = 0.0;
+ Grob *trem = unsmob_grob (me-get_object (tremolo-flag));
+ if (trem)
+ height_of_my_trem = trem-extent (trem, Y_AXIS).length ()
+/* hack a bit of space around the trem. */
++ beam_translation;
+
/* UGH
It seems that also for ideal minimum length, we must use
the maximum beam count (for this direction):
@@ -859,6 +869,7 @@
Real ideal_minimum_length =
Re: Tremolo positioning
Joe Neeman wrote: On Tue, 28 Mar 2006 20:20, Han-Wen Nienhuys wrote: Han-Wen Nienhuys wrote: Can you resend the patch using more idiomatic code? Thanks! Also, can you include a small regression test sample, so it's obvious when we break something? I'm not quite sure if we reached a conclusion on the default behaviour of tremolos and I'm also not quite sure what the protocol is for adding things to interfaces (I added style to stem-tremolo-interface. It can be 'rectangle or 'default) but here is another try anyway. I also enclose a looks good, although default is usually signaled with '() regression test and an image of the output. thanks. I've added your changes to 2.9 ; I'll probably backport the diff of 2.9.0 to 2.8.1 as a whole. Can you look at the regtests stem-tremolos.ly and stem-tremolo-position.ly (your file), and refactor them so they don't have overlaps? thanks for your patch! -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tremolo positioning
Please note that the property name style currently (hopefully) consistently denotes _font_ style. It is defined with this meaning for noteheads, rests, accidentals, time signatures, flags, and custos. Nowadays, that Lily supports subproperties (cp. manual Sect. 9.1.4 or 9.2.1), maybe, on the long term, the property style should be split into subproperties font and shape or similar? Then you could use subproperty shape of property style for stem tremolos. I _really_ would prefer to keep the naming of properties as consistent as possible. Greetings, Juergen On Wed, 29 Mar 2006, Han-Wen Nienhuys wrote: Joe Neeman wrote: On Tue, 28 Mar 2006 20:20, Han-Wen Nienhuys wrote: Han-Wen Nienhuys wrote: Can you resend the patch using more idiomatic code? Thanks! Also, can you include a small regression test sample, so it's obvious when we break something? I'm not quite sure if we reached a conclusion on the default behaviour of tremolos and I'm also not quite sure what the protocol is for adding things to interfaces (I added style to stem-tremolo-interface. It can be 'rectangle or 'default) but here is another try anyway. I also enclose a looks good, although default is usually signaled with '() regression test and an image of the output. thanks. I've added your changes to 2.9 ; I'll probably backport the diff of 2.9.0 to 2.8.1 as a whole. Can you look at the regtests stem-tremolos.ly and stem-tremolo-position.ly (your file), and refactor them so they don't have overlaps? thanks for your patch! ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improvements to Postscript backend (patches included)
In pango-font.cc, what are ggeo.width and ggeo.x_offset? glyph-string, in output-ps.scm, adds the two together to figure out where to place the next glyph. Is ggeo.width the same as the width PostScript would use to place the next glyph? If so, it would be much cleaner not to add it in, and not have to move back over it. In detail: Current situation: place glyph - move to the left by what I'm guessing might be ggeo.width - move to the right by ggeo.width + ggeo.x_offset - place another glyph. If ggeo.width is the width PostScript uses for glyphshow, we can change it to: place glyph - move to the right by ggeo.x_offset - place another glyph. David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improvements to Postscript backend (patches included)
On 3/28/06, Werner LEMBERG [EMAIL PROTECTED] wrote: - (if cid? - /CIDFont findresource - findfont) I don't understand this? How are CID resources supposed to be loaded now? According to the Postscript reference, selectfont can be used with CID resources as well as regular fonts. But a CID resource is completely useless for us since we don't get the corresponding CID value, AFAIK. In case Pango does the CMap resource handling (this is, we send a Unicode value and Pango returns the CID) we can enable this again. The current code does /fontname /CIDFont findresource 17 scalefont setfont, where 17 is a random number. If I'm not mistaken, this is completely equivalent to /fontname 17 selectfont, except that it's almost certainly slower. David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improvements to Postscript backend (new patch)
I haven't yet found a better name for str4, or written a comment about kerning, but I've made enough improvements that I think it's time to send the patch in again. Diff apparently got sick of all the changes in output-ps.scm, so it did a really lousy job, even with -d. Sorry about that. Reminder: this patch is against 2.8.0. I strongly suggest that you _not_ attempt to apply it to any version of output-ps.scm other than that, because it will fry. I'd like to discuss conventions for PostScript at some point, but right now I have to go. Basic question: should drawing procedures all start at the current point (they don't now)? Should they all start at (0,0) (they don't now)? Or should some start one place and some another place, with some kind of system for deciding? I don't know if I'll be able to do any more work on this for a while, so I'd appreciate if someone else would take care of any small changes that may be necessary (e.g., to variable names). Changelog: Changes to PostScript backend: glyph-string now produces smaller, more readable, and probably faster PostScript Several findfont scalefont setfont instances changed to selectfont Hacked-up string-appends changed to formats. David Feuer pschanges.diff Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tremolo positioning
On Thu, 30 Mar 2006 01:46, Han-Wen Nienhuys wrote: thanks. I've added your changes to 2.9 ; I'll probably backport the diff of 2.9.0 to 2.8.1 as a whole. Before you do, I've just realised that I caused a regression for tremolos on whole notes. I'll fix that today. Can you look at the regtests stem-tremolos.ly and stem-tremolo-position.ly (your file), and refactor them so they don't have overlaps? For some reason I didn't find the stem-tremolos.ly test when I first went looking for regressions... maybe I can just combine them into one file? There are only one or two examples that are in the new regression test and not in the old one. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tremolo positioning
Joe Neeman wrote: On Thu, 30 Mar 2006 01:46, Han-Wen Nienhuys wrote: thanks. I've added your changes to 2.9 ; I'll probably backport the diff of 2.9.0 to 2.8.1 as a whole. Before you do, I've just realised that I caused a regression for tremolos on whole notes. I'll fix that today. Please do. Can you look at the regtests stem-tremolos.ly and stem-tremolo-position.ly (your file), and refactor them so they don't have overlaps? For some reason I didn't find the stem-tremolos.ly test when I first went looking for regressions... maybe I can just combine them into one file? There are only one or two examples that are in the new regression test and not in the old one. Suer. Don't forget to copy the relevant descriptions. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improvements to Postscript backend (patches included)
David Feuer wrote: If ggeo.width is the width PostScript uses for glyphshow, we can change it to: ggeo.width is the kerning info that we get from pango. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improvements to Postscript backend (new patch)
David Feuer wrote: I haven't yet found a better name for str4, or written a comment about kerning, but I've made enough improvements that I think it's time to send the patch in again. Diff apparently got sick of all the changes in output-ps.scm, so it did a really lousy job, even with -d. Sorry about that. Reminder: this patch is against 2.8.0. I strongly suggest that you _not_ attempt to apply it to any version of output-ps.scm other than that, because it will fry. I'd like to discuss conventions for PostScript at some point, but right now I have to go. Basic question: should drawing procedures all start at the current point (they don't now)? Should they all start at (0,0) (they don't now)? Or should some start one place and some another place, with some kind of system for deciding? AFAIK, they all start at (0,0) -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improvements to Postscript backend (patches included)
But a CID resource is completely useless for us since we don't get the corresponding CID value, AFAIK. In case Pango does the CMap resource handling (this is, we send a Unicode value and Pango returns the CID) we can enable this again. The current code does /fontname /CIDFont findresource 17 scalefont setfont, where 17 is a random number. If I'm not mistaken, this is completely equivalent to /fontname 17 selectfont, except that it's almost certainly slower. You are probably right, but this code will (at least temporarily) vanish, I think, since we aren't able currently to handle CIDFont resources directly. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improvements to Postscript backend (new patch)
On 3/29/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: David Feuer wrote: to go. Basic question: should drawing procedures all start at the current point (they don't now)? Should they all start at (0,0) (they don't now)? Or should some start one place and some another place, with some kind of system for deciding? AFAIK, they all start at (0,0) I was including text-drawing procedures as well. Thinking more about it tonight, I've concluded that it's really ugly to have them start anywhere but the current point. If they want to translate, they can do that themselves. Filling the whole file with translations is bad. I'd really appreciate if you'd try to decide ASAP whether to accept my patch. Despite my fears, I've managed to spend some more time improving other aspects of the postscript backend, and I'd like to have a good base to work from. David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tremolo positioning
On Thu, 30 Mar 2006 10:55, Han-Wen Nienhuys wrote:
Joe Neeman wrote:
I've just realised that I caused a regression for tremolos
on whole notes. I'll fix that today.
Please do.
Here we are:
2006-03-30 Joe Neeman [EMAIL PROTECTED]
* lily/stem-tremolo.cc (print): for whole notes (and breves, etc.)
position the tremolo based on the position of the notehead.
* input/regression/stem-tremolo.ly: add example of unbeamed eighth
notes and update the texidoc line with the new positioning rules.
Can you look at the regtests
stem-tremolos.ly and stem-tremolo-position.ly (your file), and refactor
them so they don't have overlaps?
For some reason I didn't find the stem-tremolos.ly test when I first went
looking for regressions... maybe I can just combine them into one file?
There are only one or two examples that are in the new regression test
and not in the old one.
Suer. Don't forget to copy the relevant descriptions.
Index: lily/stem-tremolo.cc
===
RCS file: /sources/lilypond/lilypond/lily/stem-tremolo.cc,v
retrieving revision 1.100
diff -u -r1.100 stem-tremolo.cc
--- lily/stem-tremolo.cc 29 Mar 2006 15:41:44 - 1.100
+++ lily/stem-tremolo.cc 30 Mar 2006 07:18:47 -
@@ -175,6 +175,7 @@
Spanner *beam = Stem::get_beam (stem);
Direction stemdir = get_grob_direction (stem);
+ bool whole_note = Stem::duration_log (stem) = 0;
if (stemdir == 0)
stemdir = UP;
@@ -183,8 +184,11 @@
? Beam::get_beam_translation (beam)
: 0.81;
+ /* for a whole note, we position relative to the notehead, so we want the
+ stencil aligned on the flag closest to the head */
+ Direction stencil_dir = whole_note ? -stemdir : stemdir;
Stencil mol = raw_stencil (me, robust_scm2double (me-get_property (slope),
- 0.25), stemdir);
+ 0.25), stencil_dir);
Interval mol_ext = mol.extent (Y_AXIS);
Real ss = Staff_symbol_referencer::staff_space (me);
@@ -207,6 +211,14 @@
if (stemdir == UP)
end_y -= stemdir * beam_translation * 0.5;
}
+ if (whole_note)
+{
+ /* we shouldn't position relative to the end of the stem since the stem
+ is invisible */
+ vectorint nhp = Stem::note_head_positions (stem);
+ Real note_head = (stemdir == UP ? nhp.back () : nhp[0]);
+ end_y = note_head + stemdir * 2.0;
+}
mol.translate_axis (end_y, Y_AXIS);
return mol.smobbed_copy ();
Index: input/regression/stem-tremolo.ly
===
RCS file: /sources/lilypond/lilypond/input/regression/stem-tremolo.ly,v
retrieving revision 1.35
diff -u -r1.35 stem-tremolo.ly
--- input/regression/stem-tremolo.ly 16 Mar 2006 14:53:03 - 1.35
+++ input/regression/stem-tremolo.ly 30 Mar 2006 07:18:47 -
@@ -5,7 +5,13 @@
Stem tremolos or rolls are tremolo signs that look like beam segments
crossing stems. If the stem is in a beam, the tremolo must be parallel
to the beam. If the stem is invisible (e.g. on a whole note), the
-tremolo must be centered on the note.
+tremolo must be centered on the note. If the note has a flag (eg. an
+unbeamed 8th note), the tremolo should be shortened if the stem is up
+and tilted extra if the stem is down.
+
+The tremolos should be positioned a fixed distance from the end of the
+stems unless there is no stem, in which case they should be positioned
+a fixed distance from the note head.
}
@@ -27,7 +33,7 @@
c,16:32 c: c c a16:32 a: a a
c8:16 g: d: a:
c8:32 f: b: e:
- \transpose c c { f''8:256[ f'8: f'':] }
+ f8:256[ f,8: f':] f: \noBeam f,,: \noBeam c16:32 \noBeam c'':
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
