Re: replacement for pfx2ttf.fontforge
> >>> I+J -> IJ, i + j->ij > >>> > >>> I think those two should be removed also (just think of > >>> Strawinskij). > >> > >> No, those are language dependent (i + j -> ij is done in Dutch) > > > > Hmm. First of all, the default versions of the URW fonts don't > > have a ligature for that, only that buggy bundle which also > > contains the T + M ligature. Second, I'm not aware how to select > > a language for a text string within lilypond so that typographical > > features (from OpenType) for that language are used... > > so, we should figure out how to do that. There is a en_US setting > somewhere in pango-font.cc, I believe. Yep. The question is which kind of interface we should implement. With `we' I mean `you', of course :-) My knowledge of the Pango library is virtually nonexistent. I can add the I+J->IJ stuff for OpenType script `latn', language `NLD ' (Dutch), if you want me to do that. Similarly, I can disable the f+i->fi stuff for languages `TRK ' (Turkish) and `PTG ' (Portuguese) -- I'm not sure about the latter, however. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: pure accidental height
On 12/28/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: Hi, (define pure-print-callbacks (list ly:bar-line::print ly:note-head::print ly:accidental-interface::print ly:dots::print ly:clef::print ly:text-interface::print ly:script-interface::print)) I'm not sure if this appropriate: the accidental does a suicide() in case it is a tie-reminder in the middle of the line. Currently this happens in accidental_interface::after_line_breaking, so the height estimation doesn't cause accidentals to be killed incorrectly, but I suspect it does estimate height incorrectly for tie reminder accidentals. OK, but accidental pure-height is important, so we can't just remove it from the list, we need a pure-height callback. The actual print callback is safe, right? So I can make a callback that checks whether there is a tie and whether it is in the middle of the line and returns ly:grob::stencil-height otherwise? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volta questions
J.P. Mellor wrote: I know there's some question about exactly when the vertical bar on the right side of a (final) volta bracket should be printed. Here's a patch which produces the behavior I suggested -- print it unless the bracket is broken or shortened. What do you mean by shortened? I can't find any examples of mine where Lily prints the right vertical bar. I propose that the right vertical bar not be printed unless the user specifies this less than normal behavior. Have fun, Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volta questions
I know there's some question about exactly when the vertical bar on the right side of a (final) volta bracket should be printed. Here's a patch which produces the behavior I suggested -- print it unless the bracket is broken or shortened. jp volta-bracket.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
bugs and doc finally finished
I've finally finished catching up on all the bug reports and doc submissions. Please check the bug tracker for your favorite bugs; if they're not there, and if the bugs are still in 2.11.6 (when that comes out), then send another bug report to the bugs mailist. Likewise, if there's something missing in the 2.11.6 docs that you submitted to me, please send it again. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New pages for bugs and doc suggestions
Cameron Horsburgh wrote: %% the octovation command doesn't do anything. 'octavation' is misspelled. Thanks. I wonder if it would be worthwhile advising new bughunters to ask -devel or -user if they're not sure it is a bug they have found. Sometimes bugs are just lack of experience with Lily. Generally such cases answer themselves when people try to create their minimally small examples. That's one of the reasons we insist on them. :) If somebody creates a minimally small false bug report, I'll take that as good evidence that I need to update the relevant doc pages. In 'doc adding': "Here is an imaginary example of a perfect documentation report:" Are you saying that perfect doc reports are imaginary ? ;-) Well, I _was_ (I was irritated when I first wrote that). I suppose that's not very encouraging, though. :) I would change the word 'perfect' to, oh I don't know, 'good'? I changed it to "Here is an example of a perfect documentation report:" Again, it might be good to advise prospective doc helpers to check with the lists (or even you directly) if they have an idea for changes. I added that to the "replacing large sections" part. I don't think it's necessary for the small additions. I've updated these in git; it may take an hour or two before they're visible on the website. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
tutorial update
I just rearranged and rewrote part of the tutorial. Since that was my last task before installing Linux on this macbook, and since "make web" is currently broken anyway, I committed without testing. Sorry if I broke anything, but there were special circumstances surrounding this case which should not apply in the future. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volta questions
> "Graham" == Graham Percival <[EMAIL PROTECTED]> writes:
>> volta_test1a.ly - missing vertical line segment on the right
>> side of the volta bracket.
Graham> This isn't done in printed music.
I've got several examples of western printed music where the right
vertical bars are printed.
Graham> There is some logic in this -- the music doesn't stop
Graham> after the 2nd time ending ...
There are several cases where lilypond prints the right vertical bar
even if the music continues. Based on the examples that I have, it
seems the right vertical bar is printed if the entire alternative is
enclosed by the volta bracket. If the volta bracket is shortened
then the right vertical bar is not printed.
>> volta_test2a.ly and volta_test2b.ly - highlight functionality
>> that I'd like to see. I'm not sure what the best way to
>> achieve this is.
Graham> I'm not sure what you're trying to do with this: \repeat
Graham> volta 2 {
Graham>a'2 a'2 | \set Score.repeatCommands = #'((volta "1"))
Graham>b'2 \set Score.repeatCommands = #'((volta #f) (volta
Graham>"2")) d''2 \set Score.repeatCommands = #'((volta #f))
Graham>b'2 | c''2 c''2 |
Graham> }
I probably should have simplified these a bit more. The attached file
is hopefully more to the point. The first time through bars 1,2 and 4
are played and the second time through bars 1,3 and 4 are played. I
think the vertical bars on the right make it more clear by marking
exactly which bars are part of the alternatives.
I have perhaps 100 pieces of printed music which contains alternatives
in the middle of a repeated segment. All of these have vertical bars
on the right.
It would be nice to be able to use the \alternative mechanism rather
than manual repeats. Comments in repeated-music.hh indicate that the
model for repeated music is BODY A BODY B BODY C ==> BODY A B C where
A B C are alternatives. I'm interested in music which can have a form
like BODY A BODY' BODY B BODY' BODY C BODY'. Is it a possibility to
generalize the current model of alternatives to handle this case?
Graham> Are you just trying to get a half-bar alternative repeat?
Graham> If so, you could fake it by adding an s2 (or maybe even
Graham> s2*0) to your alternatives.
The partial bar situation is a special case and is probably more of a
distraction at this point. It will likely become important to me in
the future though.
Thanks,
jp
volta_test2d.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volta questions
Paul Scott wrote: Graham Percival wrote: This isn't done in printed music. There is some logic in this -- the music doesn't stop after the 2nd time ending -- but to be completely logical the left-most vertical segment of the 1st time ending should also be missing (since music doesn't start at the 1st time repeat). Perhaps you were sleepy when you wrote this. :) I was, actually -- it was 7:32PM local time, so I had just woken up. :) The beginning of the first ending is the place where you skip to the second ending the second time and is complete necessary. Whoops, of course! Cheers - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volta questions
Graham Percival wrote: J.P. Mellor wrote: Sure thing! Attached are much shorter examples. Thanks, there are much easier to analyze. volta_test1a.ly - missing vertical line segment on the right side of the volta bracket. This isn't done in printed music. There is some logic in this -- the music doesn't stop after the 2nd time ending -- but to be completely logical the left-most vertical segment of the 1st time ending should also be missing (since music doesn't start at the 1st time repeat). Perhaps you were sleepy when you wrote this. :) The beginning of the first ending is the place where you skip to the second ending the second time and is complete necessary. Anyway, regardless of the internal consistency (or lack thereof) of Western music, LilyPond's behavior here is not a bug. I totally agree that there need not be an end to a second ending and there is usually not a vertical line there. Have fun, Paul Scott ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New pages for bugs and doc suggestions
On Thu, Dec 28, 2006 at 07:15:07PM -0800, Graham Percival wrote: > Could one or two people proofread the new pages on bug reports and doc > suggestions? > > http://lilypond.org/web/devel/participating/bugs > http://lilypond.org/web/devel/participating/documentation-adding > In 'bugs': %% the octovation command doesn't do anything. 'octavation' is misspelled. I wonder if it would be worthwhile advising new bughunters to ask -devel or -user if they're not sure it is a bug they have found. Sometimes bugs are just lack of experience with Lily. In 'doc adding': "Here is an imaginary example of a perfect documentation report:" Are you saying that perfect doc reports are imaginary ? ;-) I would change the word 'perfect' to, oh I don't know, 'good'? Again, it might be good to advise prospective doc helpers to check with the lists (or even you directly) if they have an idea for changes. -- = Cameron Horsburgh = ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \transposedCueDuring
Werner LEMBERG wrote: Could I get a short example of \transposedCueDuring to include in the manual? There isn't any regression test for this, and the NEWS item doesn't have an example. Here it is. Thanks, added. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make/'make web' failure notifications
John Mandereau wrote: After that, I've just tried to compile Lily from latest git master branch, and make fails: ... Writing "lilypond-internals.texi"... error: cannot find description for property accidentals (backend) Han-Wen recently changed a bunch of accidental stuff; evidently he forgot to add something. (maybe an empty string for a description?) I don't think it's your fault. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volta questions
J.P. Mellor wrote:
Sure thing! Attached are much shorter examples.
Thanks, there are much easier to analyze.
volta_test1a.ly - missing vertical line segment on the right side of
the volta bracket.
This isn't done in printed music. There is some logic in this -- the
music doesn't stop after the 2nd time ending -- but to be completely
logical the left-most vertical segment of the 1st time ending should
also be missing (since music doesn't start at the 1st time repeat).
Anyway, regardless of the internal consistency (or lack thereof) of
Western music, LilyPond's behavior here is not a bug.
volta_test1b.ly - with a single alternative the final bar of the
alternative is not printed as a repeat bar.
Hmm. If you modify your file like this,
% \alternative { { a'1 | } }
\alternative { { a'1 | } {a'1 }}
you get the result you wish. I'm not convinced this is a bug, either --
if lilypond _did_ add a repeat in the first case, then it would
logically apply after the 2nd time repeat as well. Then the poor
musicians would get into an infinite loop. :)
I don't think either of these is behaving as they should.
volta_test2a.ly and volta_test2b.ly - highlight functionality that
I'd like to see. I'm not sure what the best way to
achieve this is.
I'm not sure what you're trying to do with this:
\repeat volta 2 {
a'2 a'2 |
\set Score.repeatCommands = #'((volta "1"))
b'2
\set Score.repeatCommands = #'((volta #f) (volta "2"))
d''2
\set Score.repeatCommands = #'((volta #f))
b'2 |
c''2 c''2 |
}
Are you just trying to get a half-bar alternative repeat? If so, you
could fake it by adding an s2 (or maybe even s2*0) to your alternatives.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
New pages for bugs and doc suggestions
Could one or two people proofread the new pages on bug reports and doc suggestions? http://lilypond.org/web/devel/participating/bugs http://lilypond.org/web/devel/participating/documentation-adding Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
make/'make web' failure notifications
Dear LilyPond hackers, The subject says it: I'd like to be notified of make/'make web' failures on the master branch. Could you for example send these notifications to lilypond-cvs@gnu.org again? I can live without them, but they can be handy. If you don't send them again, will make failure reports still be welcomed on this list? I've upgraded GUILE to latest 1.8 CVS snapshot, with the rational patch from http://lilypond.org/vc/gub.darcs/patches. There may be a typo in INSTALL, which says GUILE 1.8.2 is required: it is not yet released!!! Do you mean GUILE 1.8.latest_cvs_snapshot is required? After that, I've just tried to compile Lily from latest git master branch, and make fails: make[2]: Entering directory `/home/lilycvs/git/lily/Documentation/user' cd ./out && /home/lilycvs/git/lily/out/bin/lilypond --verbose /home/lilycvs/git/lily/ly/generate-documentation GNU LilyPond 2.11.6 warning: Relocation: is absolute: argv0=/home/lilycvs/git/lily/out/bin/lilypond warning: Relocation: compile prefix=/home/lilycvs/share/lilypond/2.11.6, new prefix=/home/lilycvs/git/lily/out PATH=/home/lilycvs/git/lily/out/bin (prepend) Setting PATH to /home/lilycvs/git/lily/out/bin:/home/lilycvs/git/lily/lily/out:/home/lilycvs/git/lily/buildscripts/out:/home/lilycvs/git/lily/scripts/out:/home/lilycvs/git/lily/lily/out:/home/lilycvs/git/lily/buildscripts/out:/home/lilycvs/git/lily/scripts/out:/home/lilycvs/bin:/home/john/bin:/home/john/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:: warning: Relocation: framework_prefix=/home/lilycvs/git/lily/out/bin/.. Setting INSTALLER_PREFIX to /home/lilycvs/git/lily/out/bin/.. PATH=/home/lilycvs/git/lily/out/bin/../bin (prepend) Setting PATH to /home/lilycvs/git/lily/out/bin/../bin:/home/lilycvs/git/lily/out/bin:/home/lilycvs/git/lily/lily/out:/home/lilycvs/git/lily/buildscripts/out:/home/lilycvs/git/lily/scripts/out:/home/lilycvs/git/lily/lily/out:/home/lilycvs/git/lily/buildscripts/out:/home/lilycvs/git/lily/scripts/out:/home/lilycvs/bin:/home/john/bin:/home/john/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:: Setting GUILE_MIN_YIELD_1 to 65 Setting GUILE_MIN_YIELD_2 to 65 Setting GUILE_MIN_YIELD_MALLOC to 65 Setting GUILE_INIT_SEGMENT_SIZE_1 to 10485760 Setting GUILE_MAX_SEGMENT_SIZE to 104857600 LILYPOND_DATADIR="/home/lilycvs/share/lilypond/2.11.6" LOCALEDIR="/home/lilycvs/share/locale" Effective prefix: "/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6" PATH="/home/lilycvs/git/lily/out/bin/../bin:/home/lilycvs/git/lily/out/bin:/home/lilycvs/git/lily/lily/out:/home/lilycvs/git/lily/buildscripts/out:/home/lilycvs/git/lily/scripts/out:/home/lilycvs/git/lily/lily/out:/home/lilycvs/git/lily/buildscripts/out:/home/lilycvs/git/lily/scripts/out:/home/lilycvs/bin:/home/john/bin:/home/john/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin::" [/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/lily.scm] [/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/lily-library.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/file-cache.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/define-event-classes.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/define-music-types.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/output-lib.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/c++.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/chord-ignatzek-names.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/chord-entry.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/chord-generic-names.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/stencil.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/markup.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/music-functions.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/part-combiner.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/autochange.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/define-music-properties.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/auto-beam.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/chord-name.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/parser-ly-from-scheme.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/ly-syntax-constructors.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/define-context-properties.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/translation-functions.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/script.scm][/home/lilycvs/git/lily/out/bin/../share/lilypond/2.11.6/scm/midi.scm][/home/lilycvs/gi
Re: volta questions
Here's a patch against the most recent (2.11.4) tarball posted at ttp://lilypond.org/download that fixes the missing repeat bar if only 1 alternative is given with a repeat count > 1. I think I understand what's causing the volta bracket to not be fully printed in some cases. Volta_bracket_interface::modify_edge_height in volta-bracket.cc explicitly sets no_vertical_end true unless the bar is one of the specific types listed. I don't think this is correct behavior. I think the correct behavior would be to set no_vertical_end true only of the volta bracket is shortened or broken. I'm not sure how to detect if the bracket is shortened though. Any comment/suggestions would be appreciated. Thanks, jp volta-repeat-iterator.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
OSX intel py2app
I think I have it working now. I downloaded gub-builder.py from the darcs repository, then did py2applet --make-setup gub-builder.py python2.4 setup.py py2app I now have a 2.1M build/ and a 5.5M dist/ ; with bz2, it's 3.6 megs. Do you want that sent by email? Or should I run py2applet on a different script? (if I run it without any gub-*.py script, it complains that I "must specify either app or plugin") Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: midi2ly key and rests
Please keep emails on the mailist. I don't know how to debug midi2ly myself, and certainly not on windows. However, somebody else the -devel list may be able to help. Cheers, - Graham Helge Kruse wrote: Graham, Thanks for your reply. I wrote a small example based on the midi2ly output. This small example can be converted to lilypond file with respect to the "key" command line option. Now the "\transpose cis c" works as expected and I get plain C major notation. But this fails with the MIDI file. This is very strange. The example is huge, I must admit. So I want to contribute... midi2ly is a python script. Since python is a script language, I should be able to debug it. I have a little experience with python, so I tried it with this command line: python -d C:\Programme\LilyPond\usr\bin\midi2ly.py --key=0:1 LastUnicorn.mid But python doesn’t respect the -d and just runs the script: LY output to `.\LastUnicorn-midi.ly'... Can you advise me how to investigate/debug midi2ly by myself? Best Regards, Helge -Ursprüngliche Nachricht- Von: Graham Percival [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 28. Dezember 2006 10:37 An: Helge Kruse; 'Lilypond bug' Betreff: Re: AW: midi2ly key and rests Helge Kruse wrote: There is no attachment on THIS mail, since the web interface did not offer to include files. I am not member of the bug mailing list. Therefore I hope it's ok to send it to you. There was no attachment to the previous email, either. http://lists.gnu.org/archive/html/lilypond-user/2006-12/msg00784.html Unfortunately it's a complete song with much more than five notes. But the problems remain. Unfortunately we do not have the resources to investigate bug reports which have huge examples. Could you create a small example (perhaps using lilypond's midi capability) that demonstrates the problem with midi2ly? A lilypond -> midi -> failured midi2ly example would be very useful. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \transposedCueDuring
> Could I get a short example of \transposedCueDuring to include in the
> manual? There isn't any regression test for this, and the NEWS item
> doesn't have an example.
Here it is.
Werner
==
\version "2.11.5"
\header { texidoc = "The macro @code{\transposedCueDuring} is
useful to add cues to instruments which use a completely different
octave range (for example, having a cue of a piccolo flute within
a contra bassoon part).
" }
picc = \relative c''' {
\clef "treble^8"
R1 |
c8 c c e g2 |
a4 g g2 |
}
\addquote "picc" { \picc }
cbsn = \relative c, {
\clef "bass_8"
c4 r g r
\transposedCueDuring #"picc" #UP c,, { R1 } |
c4 r g r |
}
<<
\context Staff = "picc" \picc
\context Staff = "cbsn" \cbsn
>>
\paper {
ragged-right = ##t
}
% EOF
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
pure accidental height
Hi, (define pure-print-callbacks (list ly:bar-line::print ly:note-head::print ly:accidental-interface::print ly:dots::print ly:clef::print ly:text-interface::print ly:script-interface::print)) I'm not sure if this appropriate: the accidental does a suicide() in case it is a tie-reminder in the middle of the line. Currently this happens in accidental_interface::after_line_breaking, so the height estimation doesn't cause accidentals to be killed incorrectly, but I suspect it does estimate height incorrectly for tie reminder accidentals. -- 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: volta questions
> "Graham" == Graham Percival <[EMAIL PROTECTED]> writes: Graham> J.P. Mellor wrote: >> I have a few questions about voltas/alternatives. Graham> If you would like to report a bug, please construct a Graham> minimally small example. You can probably fit the problem Graham> into half a dozen lines of lilypond code; the files you Graham> sent are too large to examine. Sure thing! Attached are much shorter examples. volta_test1a.ly - missing vertical line segment on the right side of the volta bracket. volta_test1b.ly - with a single alternative the final bar of the alternative is not printed as a repeat bar. I don't think either of these is behaving as they should. volta_test2a.ly and volta_test2b.ly - highlight functionality that I'd like to see. I'm not sure what the best way to achieve this is. Thanks, jp volta_test1a.ly Description: Binary data volta_test1b.ly Description: Binary data volta_test2a.ly Description: Binary data volta_test2b.ly Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
parenthesized natural + sharp/flat?
Hello Rune, are there realistic cases where a cautionary (parenthesis style) is coupled with natural + sharp/flat, and how bad would it be to notate that like (n) (#) instead of (n#) -- 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: morgenlied flushed up?
(can we move this to -devel?) Jan Nieuwenhuizen escreveu: > Werner LEMBERG <[EMAIL PROTECTED]> writes: > >> This is my `fault'. It has to be corrected manually -- the vertical >> space above the title was simply too large for most pages, especially >> full scores. It's easy to add some space but it was impossible to >> reduce it. > > Does that mean that in effect the top margin has gotten smaller, or > is this titles only? > > Jan. > -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markup commands leaks (Re: Scheme question on strict substitution)
Nicolas Sceaux escreveu: >> Still, the builtin-markup module should export its make-COMMAND-markup >> and COMMAND-markup functions, for they are used in some of the files >> loaded by lily.scm. As these functions will have to be imported in both >> the (lily) modules and the toplevel .ly module, and also some other (scm >> ...) modules, the namespace issue won't be solved anyhow. >> >> I propose that: >> >> 1) builtin markup commands are still defined in the (lily) module and >>exported, using a `define-builtin-markup-command' macro; >> >> 2) user markup commands are defined in the toplevel ly module, by >>creating a `define-markup-command' in markup-init.ly. > > I still have to check whether make web works, but is the following > change OK? See markup.scm and markup-init.ly. > diff --git a/ly/markup-init.ly b/ly/markup-init.ly > new file mode 100644 > index 000..f2461e4 > --- /dev/null > +++ b/ly/markup-init.ly > + (let ((command-proc (toplevel-module-ref ',command-name))) > + ;; register its command signature > + (set! (markup-command-signature command-proc) > + (list ,@signature)) hi, this statement still leaks memory. I think the signature hashtab should be thrown away or put into the local module as well. -- 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: RehearsalMark #'break-align-symbol patch request
Graham Percival escreveu: > Han-Wen Nienhuys wrote: >> Graham Percival escreveu: >>> May I apply this patch? I've had a request to change the default >>> #'break-align-symbol to #'clef, as done in this patch: >> >> doesn't look too bad now that we have the skyline stuff. Please apply, >> but only in 2.11 > > Err... does that mean "apply to ref/heads/master, but don't be surprised > if it doesn't appear in a 2.10 release", or do that mean "apply, but use > a git command other than the normal one" ? :) > > I applied it to master; I hope that's what you meant. yep. In 2.10 this would look a lot worse, due to collisions. -- 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: compiling docs without compiling lilypond
Graham Percival escreveu: > Han-Wen Nienhuys wrote: >> configure's job is to complain about missing stuff for compilation, >> but it actually does create the config.make file necessary for running >> make. >> Just do >> cp GNUmakefile.in GNUmakefile >> >> and do the EXTERNAL_BINARY dance. Can you check if that works? > > Unfortunately not. > > tsubasa:~/usr/src/lilypond gperciva$ make > LILYPOND_EXTERNAL_BINARY=~/Apps/LilyPond.app/Contents/Resources/bin/lilypond > LILYPOND_BOOK_LILYPOND_FLAGS= web > /Users/gperciva/usr/src/lilypond/stepmake/stepmake/generic-targets.make:144: > out/dummy.dep: No such file or directory > GNUmakefile:41: local.make: No such file or directory > make: *** No rule to make target `local.make'. Stop. thanks, fixed in git. You can also do touch local.make -- 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
A few cleanups
Included is a patch that cleans up a (very) few comments, useless
code, and the like.
>From 720134e89a6e2f25b2bc0859382180e181e03989 Mon Sep 17 00:00:00 2001
From: Michael Welsh Duggan <[EMAIL PROTECTED](none)>
Date: Fri, 8 Dec 2006 19:11:17 -0500
Subject: [PATCH] Various code cleanups
---
lily/breathing-sign.cc |5 -
lily/include/ly-smobs.icc |7 ---
lily/ottava-engraver.cc|2 +-
mf/parmesan-accidentals.mf |2 +-
mf/parmesan-flags.mf |2 +-
mf/parmesan-generic.mf |3 +--
mf/parmesan-timesig.mf |2 +-
7 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/lily/breathing-sign.cc b/lily/breathing-sign.cc
index d0acbce..d243f89 100644
--- a/lily/breathing-sign.cc
+++ b/lily/breathing-sign.cc
@@ -41,14 +41,9 @@ Breathing_sign::divisio_minima (SCM smob)
{
Grob *me = unsmob_grob (smob);
Real staff_space = Staff_symbol_referencer::staff_space (me);
- Real staff_size;
Real thickness = Staff_symbol_referencer::line_thickness (me);
thickness *= robust_scm2double (me->get_property ("thickness"), 1.0);
- if (Staff_symbol_referencer::get_staff_symbol (me))
-staff_size = (Staff_symbol_referencer::line_count (me) - 1) * staff_space;
- else
-staff_size = 0.0;
Real blotdiameter = me->layout ()->get_dimension (ly_symbol2scm
("blot-diameter"));
diff --git a/lily/include/ly-smobs.icc b/lily/include/ly-smobs.icc
index 99c09fc..b62a425 100644
--- a/lily/include/ly-smobs.icc
+++ b/lily/include/ly-smobs.icc
@@ -96,9 +96,10 @@
This is local. We don't assign to self_scm_ directly, to assure \
that S isn't GC-ed from under us.
\
\
- We
don't use smobbed_self () to ensure that mark_smob () doesn't have to \
- deal
half-initialized objects: scm_done_malloc ( ) might trigger GC. \
- the
warning in smobs.hh is just to be doubleplus goodly sure \
+ We don't use smobbed_self () to ensure that mark_smob () doesn't \
+ have to deal half-initialized objects: scm_done_malloc ( ) might \
+ trigger GC.the warning in smobs.hh is just to be doubleplus \
+ goodly sure \
*/ \
SCM s; \
SCM_NEWSMOB (s, CL::smob_tag_, this); \
diff --git a/lily/ottava-engraver.cc b/lily/ottava-engraver.cc
index 6afa928..556a349 100644
--- a/lily/ottava-engraver.cc
+++ b/lily/ottava-engraver.cc
@@ -1,5 +1,5 @@
/*
- text-spanner-engraver.cc -- implement Ottava_spanner_engraver
+ ottova-engraver.cc -- implement Ottava_spanner_engraver
source file of the GNU LilyPond music typesetter
diff --git a/mf/parmesan-accidentals.mf b/mf/parmesan-accidentals.mf
index c9f8fba..c09ae5a 100644
--- a/mf/parmesan-accidentals.mf
+++ b/mf/parmesan-accidentals.mf
@@ -1,4 +1,4 @@
-% -*-Fundamental-*-
+% -%-Fundamental-%- -*-Metafont-*-
% parmesan-accidentals.mf -- implement ancient accidentals
%
% source file of LilyPond's pretty-but-neat music font
diff --git a/mf/parmesan-flags.mf b/mf/parmesan-flags.mf
index 1202080..2ee63a0 100644
--- a/mf/parmesan-flags.mf
+++ b/mf/parmesan-flags.mf
@@ -1,4 +1,4 @@
-% -*-Fundamental-*-
+% -%-Fundamental-%- -*-Metafont-*-
% parmesan-flags.mf -- implement ancient flags
%
% source file of LilyPond's pretty-but-neat music font
diff --git a/mf/parmesan-generic.mf b/mf/parmesan-generic.mf
index 0ed8a62..7114bc6 100644
--- a/mf/parmesan-generic.mf
+++ b/mf/parmesan-generic.mf
@@ -1,5 +1,4 @@
-
-% -*-Fundamental-*-
+% -%-Fundamental-%- -*-Metafont-*-
% parmesan-generic.mf -- implement generic stuff: include lots of files,
% but don't set dims.
%
diff --git a/mf/parmesan-timesig.mf b/mf/parmesan-timesig.mf
index 6aa68ab..d02840b 100644
--- a/mf/parmesan-timesig.mf
+++ b/mf/parmesan-timesig.mf
@@ -1,4 +1,4 @@
-% -*-Fundamental-*-
+% -%-Fundamental-%- -*-Metafont-*-
% parmesan-timesig.mf -- implement ancient time signatures
%
% source file of LilyPond's pretty-but-neat music font
--
1.4.4.2
--
Michael Welsh Duggan
([EMAIL PROTECTED])
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RehearsalMark #'break-align-symbol patch request
Han-Wen Nienhuys wrote: Graham Percival escreveu: May I apply this patch? I've had a request to change the default #'break-align-symbol to #'clef, as done in this patch: doesn't look too bad now that we have the skyline stuff. Please apply, but only in 2.11 Err... does that mean "apply to ref/heads/master, but don't be surprised if it doesn't appear in a 2.10 release", or do that mean "apply, but use a git command other than the normal one" ? :) I applied it to master; I hope that's what you meant. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volta questions
J.P. Mellor wrote: I have a few questions about voltas/alternatives. If you would like to report a bug, please construct a minimally small example. You can probably fit the problem into half a dozen lines of lilypond code; the files you sent are too large to examine. Thanks, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Help with git and LilyPond Tutorial
It seems to be more concise, and I'll try it later on. ¡Thanks! Daniel Tonda C. begin:vcard fn:Daniel Tonda Castillo n:Tonda Castillo;Daniel email;internet:[EMAIL PROTECTED] version:2.1 end:vcard ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
