Re: compilation error
Aredridel wrote: What to do? Maybe we should just change the 'do not compile' attitude a bit, and have 'supported' development platforms with a detailed recipe to compile lily. The contributers of binary releases should make sure that the recipe stays up to date. Would this work? I'd like that attitude change. Lilypond is not -that- hard to compile -- it's easier than Mozilla, easier than GNOME, easier than TeX itself. The dependencies are not well documented in the docs, but the recipe itself isn't too hard (I have it in .spec form for making RPMs for the PLD distribution) -- once you get the prerequisites, the rest fairly flies, especially if you're ignoring packaging issues. I actually find that the depencies are well documented in INSTALL.txt, what information did you miss? Of course, it may sometimes be tricky to find out what RPM/.dpkg contains the necessary programs and files but that's hardly a LilyPond problem. /Mats ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Text spanners that word wrap.
Hi again, I am getting on well with my Braille exploits, but I am looking for some advice on output formatting. Currently, for debug purposes, I'm attaching my Braille to individual notes but progress has made this not now tenable. I have been looking at the text-spanner-engraver code for some inspiration as to typesetting a block of text that word wraps. Since Braille is read as prose and is not formatted as per the characteristics of printed conventional music, I am looking at generating the text for a staff and planting it as a prose section above as discussed previously. However, it *might* be long and I would prefer it to word wrap rather than tramming off the end of the staff and/or continuing with the next system as a break aligned object. Can anybody tell me if there is an easy way to do this as things stand, or will I have to program in a special item formatting object to achieve this? I'm happy to have a go at this if there is no alternative already available. An example of the formatting I'm trying to achieve is here: http://www.brl.org/music/code/bmb/chap16/index.html Although this is a reasonable example, my Braille will be anchored to the left of the staff and span the entire staff length potentially. I'm also open to any other formatting suggestions. I can't really tie the Braille to bar-size texts either (text spanners representing the music in the bar, attached to the beginning of the bar itself) because they will be naturally broken up by other music column based events and not read very well. Even if I did, I would not want the Braille to stretch the bar to fit within the musical column. Regards, Ralph - Tribal Data Solutions has moved, please visit our website for more details http://www.tribaldata.co.uk. This e-mail and any attachments are confidential and are sent on the basis of our copyright, e-mail and security policy which can be inspected by visiting http://www.tribaldata.co.uk/policies.asp. If you are not the intended recipient, please notify the sender and delete this message. Thank you. --- ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Text spanners that word wrap.
Hi again, I am getting on well with my Braille exploits, but I am looking for some advice on output formatting. Currently, for debug purposes, I'm attaching my Braille to individual notes but progress has made this not now tenable. I have been looking at the text-spanner-engraver code for some inspiration as to typesetting a block of text that word wraps. Since Braille is read as prose and is not formatted as per the characteristics of printed conventional music, I am looking at generating the text for a staff and planting it as a prose section above as discussed previously. However, it *might* be long and I would prefer it to word wrap rather than tramming off the end of the staff and/or continuing with the next system as a break aligned object. Can anybody tell me if there is an easy way to do this as things stand, or will I have to program in a special item formatting object to achieve this? I'm happy to have a go at this if there is no alternative already available. An example of the formatting I'm trying to achieve is here: http://www.brl.org/music/code/bmb/chap16/index.html Although this is a reasonable example, my Braille will be anchored to the left of the staff and span the entire staff length potentially. I'm also open to any other formatting suggestions. I can't really tie the Braille to bar-size texts either (text spanners representing the music in the bar, attached to the beginning of the bar itself) because they will be naturally broken up by other music column based events and not read very well. Even if I did, I would not want the Braille to stretch the bar to fit within the musical column. Regards, Ralph - Tribal Data Solutions has moved, please visit our website for more details http://www.tribaldata.co.uk. This e-mail and any attachments are confidential and are sent on the basis of our copyright, e-mail and security policy which can be inspected by visiting http://www.tribaldata.co.uk/policies.asp. If you are not the intended recipient, please notify the sender and delete this message. Thank you. --- ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
info problems
It seems that the GNU mail server doesn't work well currently due to worm attacks. I'm thus resending my mail. Werner == Since installation of info files into a separate directory (/usr/local/info/lilypond/), calling info lilypond no longer works. This is *very* bad. I use texinfo CVS version 2004-02-28. Saying `info' alone gives the following menu entries: * GNU LilyPond: (./lilypond/lilypond). The GNU music typesetter. ... Hitting onto this line gives ./lilypond/lilypond: No such file or directory which is equally bad. Doing a search (in stand-alone info) with C-s no longer works across all info files of Lilypond. Formerly, I did e.g. `C-s transparent' to find all ocurrences which was *very* helpful. Something is really broken here. You probably only use Emacs Info mode without taking care of stand-alone info. Werner ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Please resend email to Arno Waschk
i am experiencing problems with my email account [EMAIL PROTECTED] Please resend bounced messages from the recent weeks, or email you otherwise think might not have recieved me. I was promised by my domain provider that email to my account should not bounce any more. If they still might do, please try [EMAIL PROTECTED] . Thank you for your patience. Yours, Arno Waschk Liebe Freunde, es gibt zur Zeit eigenartige Probleme mit meinem email Konto [EMAIL PROTECTED], das von einigen email-Sendern nicht erreicht wird. Falls Sie email an mich zu schicken versuchten, die mit einer Fehlermeldung zurück kam, oder wenn Sie anderweitig den Verdacht haben, dass eine email mich nicht erreicht haben könnte, möchte ich Sie bitten, diese noch einmal zu schicken. Mein Domain Provider hat mir zugesichert, dass die Probleme nun mehr behoben seien. Notfalls bin ich aich über [EMAIL PROTECTED] erreichbar. Herzlichen Dank und viele Grüsse Arno Waschk ___ 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
hinterfleisch of natural
[Until lilypond-devel works again I will CC all mails to Han-Wen and Janneke. If you know something better please tell me.] [CVS 2004-03-10 9:50 MET] Thanks a lot for fixing the positioning of accidentals! It greatly improves the optical appearance. IMHO there is still a problem with naturals and sharps occurring in a chord at the same time (see attached image): They don't appear vertically aligned; the natural is positioned too near to the note head. Werner PS: The problems with fontforge have been resolved. Since today, fontforge produces valid PFAs again for lilypond fonts. inline: acc.png___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Merging different fonts
When running lilypond (I'm using 2.1.27), if you have 2 voices with
different note head styles (fonts), the program will merge colliding
notes, losing one of the fonts. The problem is shown in this example:
\score { \notes { { d'4 c'4 }
\\ \override NoteHead #'style = #'diamond
{ c'4 c'4 } r2 } }
\paper {
indent = 0.0\mm
raggedright = ##t
}
I created a patch. I also added a property (merge-differently-fonted)
to allow the original behavior. The patch includes the source files as
well as the user manual. I also created a file for the regression
tests. Below are the 1. the patch, and 2. the regression test. I've
been following the mailing list for a few weeks now, and I think this is
the format you want (diff -u, no attachments, etc.). If you want
something else, let me know.
Doug Linhardt
1. The patch
--- ../lilypond-2.1.27/./lily/note-head.cc 2004-03-07
17:03:28.0 -0600
+++ ./lily/note-head.cc 2004-03-07 17:03:28.0 -0600
@@ -121,16 +121,13 @@
Stencil
internal_print (Grob *me, bool with_ledgers)
{
- SCM style = me-get_property (style);
- if (!gh_symbol_p (style))
+ String font_name = Note_head::get_font_name(me);
+ if (font_name == )
{
return Stencil ();
}
- SCM log = gh_int2scm (Note_head::get_balltype (me));
- SCM proc = me-get_property (glyph-name-procedure);
- SCM scm_font_char = scm_call_2 (proc, log, style);
- String font_char = noteheads- + ly_scm2string (scm_font_char);
+ String font_char = noteheads- + font_name;
Font_metric * fm = Font_interface::get_default_font (me);
Stencil out = fm-find_by_name (font_char);
@@ -272,6 +269,23 @@
return m.smobbed_copy ();
}
+String
+Note_head::get_font_name(Grob* me)
+{
+ String ret_val = ;
+
+ SCM style = me-get_property (style);
+ if (gh_symbol_p (style))
+{
+ SCM log = gh_int2scm (Note_head::get_balltype (me));
+ SCM proc = me-get_property (glyph-name-procedure);
+ SCM scm_font_char = scm_call_2 (proc, log, style);
+ ret_val = ly_scm2string (scm_font_char);
+}
+
+ return ret_val;
+}
+
Real
Note_head::stem_attachment_coordinate (Grob *me, Axis a)
@@ -281,16 +295,13 @@
if (brewer == Note_head::print_proc)
{
- SCM style = me-get_property (style);
- if (!gh_symbol_p (style))
- {
- return 0.0;
- }
-
- SCM log = gh_int2scm (Note_head::get_balltype (me));
- SCM proc = me-get_property (glyph-name-procedure);
- SCM scm_font_char = scm_call_2 (proc, log, style);
- String font_char = noteheads- + ly_scm2string (scm_font_char);
+ String font_name = get_font_name(me);
+ if (font_name == )
+{
+ return 0.0;
+}
+
+ String font_char = noteheads- + font_name;
int k = fm-name_to_index (font_char) ;
--- ../lilypond-2.1.27/./lily/note-collision.cc 2004-03-07
17:03:28.0 -0600
+++ ./lily/note-collision.cc2004-03-07 17:03:28.0 -0600
@@ -71,6 +71,8 @@
int upball_type = Note_head::get_balltype (nu);
int dnball_type = Note_head::get_balltype (nd);
+ String up_font = Note_head::get_font_name (nu);
+ String dn_font = Note_head::get_font_name (nd);
/* Do not merge whole notes (or longer, like breve, longa, maxima). */
if (merge_possible (upball_type = 0 || dnball_type = 0))
@@ -88,6 +90,13 @@
!to_boolean (me-get_property (merge-differently-headed)))
merge_possible = false;
+ /* Can only merge different fonts if merge-differently-fonted is
+ set. */
+ if (merge_possible
+ up_font != dn_font
+ !to_boolean (me-get_property (merge-differently-fonted)))
+merge_possible = false;
+
/* Should never merge quarter and half notes, as this would make
them indistinguishable. */
if (merge_possible
@@ -474,4 +483,4 @@
,
- merge-differently-dotted merge-differently-headed
positioning-done);
+ merge-differently-dotted merge-differently-headed
merge-differently-fonted positioning-done);
--- ../lilypond-2.1.27/./lily/include/note-head.hh 2004-03-07
17:03:28.0 -0600
+++ ./lily/include/note-head.hh 2004-03-07 17:03:28.0 -0600
@@ -29,6 +29,7 @@
static bool has_interface (Grob*);
static Real stem_attachment_coordinate (Grob *, Axis a);
static int get_balltype (Grob*) ;
+ static String get_font_name (Grob*) ;
};
#endif // NOTEHEAD_HH
--- ../lilypond-2.1.27/./scm/define-grob-properties.scm 2004-03-07
17:03:28.0 -0600
+++ ./scm/define-grob-properties.scm2004-03-07 17:03:28.0 -0600
@@ -338,6 +338,10 @@
notation for some types of polyphonic music. The value of this setting
is used by @internalsref{note-collision-interface} .)
+ (merge-differently-fonted ,boolean? Merge noteheads in
+collisions, even if they are represented by different fonts. The value
+of this setting is used by @internalsref{note-collision-interface} .)
+
(minimum-distance ,ly:dimension? Minimum distance between rest
and
vertically stacked flats.
[CVS 2004-03-10 9:50 MET] With the current vertical size of flats I think it is not appropriate to allow the same horizontal position if the interval is a sixth -- they almost do touch (see image). If you insist on that, how can I configure this? Werner inline: sixth.png___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
oversized dot in portato
This change: 2004-03-08 Han-Wen Nienhuys [EMAIL PROTECTED] * mf/feta-schrift.mf: thicker dot for portato. makes too fat dots now, especially if the staff size has been reduced. Werner inline: portato.png___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
