Re: 3.0 -- gnome backend
Nicolas Sceaux writes: That's quite strange. I tested on a fresh machine. What versions of fontconfig/gnome/pango do you use? fontconfig is version 2.2.3 gnome is 2.6.1 pango is 1.4.1 ohoh, maybe I should look at guile-gnome.sh again, and get a more recent pango. I'm doing this. Yes. Does lily build with pango and show the gnome canvas? I'm amazed, it needs pango 1.5.2 or newer. LilyPond fonts do appear in the font selection dialog. Ok. This is the same mechanism, also gnome/pango, so the fonts are there. 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://lists.gnu.org/mailman/listinfo/lilypond-devel
unnatural tranpositions
Consider a trumpet 1 in B flat (\tri), quoting trumpet 2 in B flat (\trii). Both voices are entered normally (that is, in C). To make this work, I have to say in trumpet1.ly: \addquote trii \trii \transpose bes c' \tri in \tri: ... \quote trii ... ... in \trii: \transposition d' ... It is the last command which worries me. The d' looks very unnatural: I fear that in more complex situations enharmonic problems can arise due to the doubled transposition: Consider a horn in E... Additionally, I'm not sure whether it sounds correctly if converted to MIDI. Maybe the logic how \transposition and \transpose interact should be changed. Assuming that it should be \transpose bes c' and \transposition bes I suggest that the difference between \transpose and \transposition is applied to material used in \quote, then the quote is transposed. In the example, both trumpet 1 and trumpet 2 are in B flat, so the difference is zero, thus the notes in \quote are simply transposed as is everything else in the trumpet voice. Werner ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0 -- gnome backend
Jan Nieuwenhuizen [EMAIL PROTECTED] writes: Nicolas Sceaux writes: That's quite strange. I tested on a fresh machine. What versions of fontconfig/gnome/pango do you use? fontconfig is version 2.2.3 gnome is 2.6.1 pango is 1.4.1 ohoh, maybe I should look at guile-gnome.sh again, and get a more recent pango. I'm doing this. Yes. Does lily build with pango and show the gnome canvas? I'm amazed, it needs pango 1.5.2 or newer. My mistake. pango 1.4.1 was the debian's one. I have 1.5.0 from (old) CVS. This is the one that was used to compile LilyPond with --enable-gui. I am upgrading to pango 1.5.2. What does BLOEDIGE_RAND mean? bleeding edge? Should I use pango, g-wrap, etc, from CVS/arch or the tar.gz packages? nicolas ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0 -- gnome backend
Nicolas Sceaux [EMAIL PROTECTED] writes: My mistake. pango 1.4.1 was the debian's one. I have 1.5.0 from (old) CVS. This is the one that was used to compile LilyPond with --enable-gui. I am upgrading to pango 1.5.2. What does BLOEDIGE_RAND mean? bleeding edge? Should I use pango, g-wrap, etc, from CVS/arch or the tar.gz packages? Now, I have rebuilt and installed pango, g-wrap, guile-gnome: nicolas:~ pkg-config --modversion pango 1.5.2 nicolas:~ pkg-config --modversion g-wrap-2.0-guile 1.9.1 nicolas:~ pkg-config --modversion guile-gnome-glib 2.5.993 and then built again LilyPond from CVS. but still the same result. Note: this may have nothing to do with gnome and pango, but I can select LilyPond-feta in OOo Writer, and insert F-clef, dacoda signs, etc. nicolas inline: lily-gnome-capture.png___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
stem length algorithm
Even after looking into stem.cc I don't know how the various stem length parameters interact. Can someone please explain how exactly the stem length is computed from the parameters lengths stem-shorten beamed-lengths beamed-minimum-free-lengths beamed-extreme-minimum-free-lengths The documentation of those variables is not sufficient, unfortunately. And what does `beamed-stem-shorten'? Thanks in advance. Werner ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: unnatural tranpositions
\transposition d' ... It is the last command which worries me. The d' looks very unnatural: I'm now convinced that it is a bug, and I've sent a report to bug-lilypond. Werner ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: unnatural tranpositions
I'm now convinced that it is a bug, and I've sent a report to bug-lilypond. Two bug reports are sitting in the queue (I thought that I can directly send attached PNG images as a subscribed list member, ...) Werner ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
[bug] \once \override Score.SystemStartBracket holds forever
Hi! Once Score.SystemStartBracket #'transparent has been overridden to ##t, it seems it is not possible to revert the effect. For an example, look at section 3.4.2 in the manual (in recent CVS; this is not yet on the web site) or, respectively, in the generated file Documentation/user/out-www/lilypond/lily-2054725167.ly. As you can see, the system start bracket is removed from both lines of score, not just the first one. On a similar vein, in the manual it does not get clear what happens with contradicting \override or \set commands (at least I could not find something about this issue). Imagine, for example, two voices that live in the same staff. The first voice sets some context property of the staff context or overrides a grob property of a grob that lives in the staff context. The second voice touches the same properties at the same score time, but with different values. Which voice wins? The manual probably should say something about this (or, even better, maybe in 3.1.x, lily should issue a warning during interpreting phase about conflicting property settings). Of course, the cleanest solution would be to allow property settings only for the current scope of context (which would have some major consequences for lily's syntax, though). On a third vein, I just recognized that \once does not appear in the unified index. It should, I guess (and maybe there should also be a short section in the manual that introduces \once). Greetings, Jürgen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
[bug or doc error] partcombine and stem direction
The docs suggest that if you \partcombine two voices (and they
have different notes), the stems will be in different directions. The
following example (taken from the docs) have the two different
parts joined by a single stem. Are the docs in error, or is this
a bug?
\relative c'' {
\new Staff \partcombine
\relative g' { g g a( b) c c r r }
\relative g' { g g r4 r e e g g }
}
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \version header in manual .ly snippets
On 23-Sep-04, at 3:06 AM, Juergen Reuter wrote: The example templates in section 3 of the manual (Documentation/user/examples.itely) currently contain a '\version 2.3.16' header. Shouldn't this header be automatically inserted when dissecting the .itely file? \version info isn't inserted automatically (it probably isn't needed, since the .itely files are only dissected when you're making the docs, and then you know what version of lily you're using :) However, in the case of examples.itely, the templates are made to be easily copied and pasted into a text file on their own. I wanted to get newbies into the habit of seeing \version foo.bar.baz at the top of their input files. :) Cheers, - Graham ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bug status
On Saturday 25 September 2004 20.36, Graham Percival wrote: On 24-Sep-04, at 2:31 AM, Han-Wen Nienhuys wrote: [EMAIL PROTECTED] writes: Add boxed-rehearsal-mark to this. It is now worse than in 2.2, the bottom line is way off. see attachment. There is something very fishy with this one. The -f ps version is perfect, as is the -f tex. Only when used through lilypond-book, it is wrong. Is this the problem that's in the manual section on Rehearsal marks? http://www.lilypond.org/doc/v2.3/Documentation/user/out-www/lilypond/ Rehearsal-marks.html Yes, it's exactly the same. Erik ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
[bug] \once \override Score.SystemStartBracket holds forever
[EMAIL PROTECTED] writes: Hi! Once Score.SystemStartBracket #'transparent has been overridden to ##t, it seems it is not possible to revert the effect. For an example, look at section 3.4.2 in the manual (in recent CVS; this is not yet on the web site) or, respectively, in the generated file Documentation/user/out-www/lilypond/lily-2054725167.ly. As you can see, the system start bracket is removed from both lines of score, not just the first one. This is intentional. The system start is a single big spanner. It is possible to tweak different parts of the spanner, but that requires some exotic code. On a similar vein, in the manual it does not get clear what happens with contradicting \override or \set commands (at least I could not find something about this issue). Imagine, for example, two voices that live in the same staff. The first voice sets some context property of the staff context or overrides a grob property of a grob that lives in the staff context. The second voice touches the same properties at the same score time, but with different values. Which voice wins? Commands are processed in the order that they appear within the music expression. In this case, whichever voice comes last in the simultaneous expression wins. The manual probably should say something about this (or, even better, maybe in 3.1.x, lily should issue a warning during interpreting phase about conflicting property settings). I disagree. That would create lots of spurious warnings, eg, \voiceOne \stemDown which is IMO perfectly valid will produce a warning. Of course, the cleanest solution would be to allow property settings only for the current scope of context (which would have some major consequences for lily's syntax, though). I think that this solution will create more problems than it intends to solve. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bug status
[EMAIL PROTECTED] writes: On Saturday 25 September 2004 20.36, Graham Percival wrote: On 24-Sep-04, at 2:31 AM, Han-Wen Nienhuys wrote: [EMAIL PROTECTED] writes: Add boxed-rehearsal-mark to this. It is now worse than in 2.2, the bottom line is way off. see attachment. There is something very fishy with this one. The -f ps version is perfect, as is the -f tex. Only when used through lilypond-book, it is wrong. Is this the problem that's in the manual section on Rehearsal marks? http://www.lilypond.org/doc/v2.3/Documentation/user/out-www/lilypond/ Rehearsal-marks.html Yes, it's exactly the same. Take a look at the regression test for part combining. Hopefully that makes it clear what part combining should look like. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
