Re: mensural notation improvements (issue3797046)
One thing I forgot to mention: I've also rewritten dot handling within ligatures. The old code - didn't avoid staff lines - didn't conform actual usage: dotting notes above is not a practice, only if they are first within a flexa, see examples in http://anaigeon.free.fr/mes_facs/fsbarb.jpg http://upload.wikimedia.org/wikipedia/commons/d/d7/Eton_Choirbook.jpg (actually I know one example when the second flexa note is dotted above, but general usage is like the two above, when such notes are dotted behind.) http://codereview.appspot.com/3797046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
On Thu, 2011-01-06 at 08:44 +, benko@gmail.com wrote: > One thing I forgot to mention: I've also rewritten dot handling within > ligatures. The old code > - didn't avoid staff lines > - didn't conform actual usage: dotting notes above is not a practice, > only if they are first within a flexa, see examples in > http://anaigeon.free.fr/mes_facs/fsbarb.jpg > http://upload.wikimedia.org/wikipedia/commons/d/d7/Eton_Choirbook.jpg > > (actually I know one example when the second flexa note is dotted above, > but general usage is like the two above, when such notes are dotted > behind.) > > http://codereview.appspot.com/3797046/ > According to Apel (1962: 99), the general rule would seem to be that the dot should be on the right if it applies to the final note of the whole ligature, but on top if it is anywhere else (flexa or no flexa). He has one example of a flexa followed by several square notes, with a dot above the following square note (i.e. in a position that happens to be also just to the right of the flexa), but the dot is meant to apply to the square note over which it stands, not the flexa. Lukas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Black mensural notation
Am 04.01.2011 11:22, schrieb Lukas Pietsch: > Hi, I'm quite new to Lilypond programming, but I thought I'd jump in at what > seemed to me to be pretty much the deep end, and try if I could get black > mensural notation implemented. Here's what I've come up with so far: > http://lukas-pietsch.de/Music/blackmensural.ly (source file) > http://lukas-pietsch.de/Music/blackmensural.pdf (doc) > > It's all just scheme functions and embedded postscript, and works for me under > the current stable 2.12.3. > > The biggest stumbling block turned out to be black ligatures, which I found no > other way of doing than rewriting from scratch in a rather hackish way, > sidestepping the normal ligature engraver completely; and horizontal spacing, > for which I had to figure out some rather ugly workarounds (probably far from > optimal). > > If anybody finds it useful, please feel free to use or modify. > Lukas, I just wanted to say that I am really impressed! Please keep up the good work. Regards, Robert ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
> > One thing I forgot to mention: I've also rewritten dot handling within > > ligatures. The old code > > - didn't avoid staff lines > > - didn't conform actual usage: dotting notes above is not a practice, > > only if they are first within a flexa, see examples in > > http://anaigeon.free.fr/mes_facs/fsbarb.jpg > > http://upload.wikimedia.org/wikipedia/commons/d/d7/Eton_Choirbook.jpg > > (actually I know one example when the second flexa note is dotted above, > > but general usage is like the two above, when such notes are dotted > > behind.) > > http://codereview.appspot.com/3797046/ > According to Apel (1962: 99), the general rule would seem to be that the dot > should be on the right if it applies to the final note of the whole > ligature, but on top if it is anywhere else (flexa or no flexa). He has one > example of a flexa followed by several square notes, with a dot above the > following square note (i.e. in a position that happens to be also just to > the right of the flexa), but the dot is meant to apply to the square note > over which it stands, not the flexa. When I have time to go to the library, I'll look up Apel again, which codex it is, but if you have a handy scan available (even better: a link, e.g. to IMSLP or DIAMM), I'd love to see it. But let me reiterate: I've seen several codices, and only one diverges from the usage I implemented, and even that diverges only in dotting not only the first but the last note of a flexa above as well. I know that ligatures are not too frequent, dotted notes within ligatures are extremely rare, but even the two examples I linked clearly dot notes contrary to the Apel way. I'll try to find an example where a non-final square note is dotted and the following note is below it (in the linked examples the next notes are above, so the dot of the first note appears _below_ the next note). p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond authors, release notes, announcements
On 2011-01-05 15:17, Reinhold Kainhofer wrote: > Am Mittwoch, 5. Januar 2011, um 13:33:26 schrieb Graham Percival: >> On Wed, Jan 5, 2011 at 11:58 AM, Federico Bruni wrote: >>> Il giorno mer, 05/01/2011 alle 11.36 +0100, Alexander Kobel ha scritto: I tend not to like those assembled logos very much. Most of the time, they end up too clumsy IMHO; more like something quickly hacked together, just for the sake of quoting musical symbols. >>> >>> You mean something like this? (my 5 minute try, really horrible) >> >> That looks quite "busy" to my taste. My latest 5-minute hack is >> something like this: > > Attached is a small modification (created in inkscape rather than lilypond > itself). What I really don't like about it is the different slant of the L, > the l and the p)... Huh, that's a good one, kudos! I personally think the p is just a bit too large; IMHO it should fit to the same x-height as the neighbor letters. In smaller size, I also think that the blackness of L and p is extremely dominant in contrast to the other letters, but this is just from scaling of the PNG. Maybe a "real" markup implementation in Lily would perform better due to the scaled fonts. And I'm not too sure about the "Music typesetting for everyone". It's nicely integrated, and looks very good in a large image. But if the logo goes into the tagline, IMHO it should also look acceptable in a size where the staff lines are at about the same distance as for the default music staves. The "subscript tagline" has certainly less than 1.5 mm height then, and if it's removed, the lower serif of the L gets a bit too dominant for my taste, too. So I suppose we'd need this in two versions, for smaller and larger logos. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mensural notation improvements (issue3797046)
On Thu, 2011-01-06 at 10:49 +0100, Benkő Pál wrote: > > According to Apel (1962: 99), the general rule would seem to be that the dot > > should be on the right if it applies to the final note of the whole > > ligature, but on top if it is anywhere else (flexa or no flexa). He has one > > example of a flexa followed by several square notes, with a dot above the > > following square note (i.e. in a position that happens to be also just to > > the right of the flexa), but the dot is meant to apply to the square note > > over which it stands, not the flexa. > > When I have time to go to the library, I'll look up Apel again, > which codex it is, but if you have a handy scan available (even > better: a link, e.g. to IMSLP or DIAMM), I'd love to see it. > > But let me reiterate: I've seen several codices, and only one > diverges from the usage I implemented, and even that diverges > only in dotting not only the first but the last note of a flexa > above as well. I know that ligatures are not too frequent, > dotted notes within ligatures are extremely rare, but even the > two examples I linked clearly dot notes contrary to the Apel way. > I'll try to find an example where a non-final square note is > dotted and the following note is below it (in the linked examples > the next notes are above, so the dot of the first note appears > _below_ the next note). > > p Yep, I can see the examples you describe, you are right about them contradicting Apel's rule. Unfortunately, the examples Apel gives are schematic self-drawn ones in the text, thus possibly constructed. I could not quickly find a relevant example in any of the actual facsimiles in the book. Lukas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: german website problems
2011/1/6 Graham Percival : > None of these warnings happen in the other languages, so I think > they're all problems in the german source, rather than in our build > system. > > > make website > ... > Initializing settings for web site: [de] > ** closing warning (1 braces missing) (l. 319) > *** Undefined node `Development' in @ref (in > /main/src/lilypond/Documentation//web/news-front.itexi l. 29 in @qq) > *** Undefined node `Development' in @ref (in > /main/src/lilypond/Documentation//web/news-front.itexi l. 46 in @qq) > *** Undefined node `Development' in @ref (l. 165) > *** Undefined node `Development' in @ref (l. 167) > *** Undefined node `Entwicklung' in @ref (in > /main/src/lilypond/Documentation/de/web/download.itexi l. 68) > *** Undefined node `Entwicklung' in @ref (in > /main/src/lilypond/Documentation/de/web/manuals.itexi l. 126 in > @divClass) > *** Undefined node `Entwicklung' in @ref (in > /main/src/lilypond/Documentation/de/web/community.itexi l. 25) > *** Undefined node `Autoren' in @ref (in > /main/src/lilypond/Documentation/de/web/community.itexi l. 28) > *** Undefined node `Veröffentlichungen' in @ref (in > /main/src/lilypond/Documentation/de/web/community.itexi l. 40 in > @divClass) > *** Undefined node `Ältere Neuigkeiten' in @ref (in > /main/src/lilypond/Documentation/de/web/community.itexi l. 44) > *** Unknown node in menu entry `Entwicklung' (in > /main/src/lilypond/Documentation/de/web/community.itexi l. 62) > *** Unknown node in menu entry `Autoren' (in > /main/src/lilypond/Documentation/de/web/community.itexi l. 63) > *** Unknown node in menu entry `Veröffentlichungen' (in > /main/src/lilypond/Documentation/de/web/community.itexi l. 64) > *** Unknown node in menu entry `Ältere Neuigkeiten' (in > /main/src/lilypond/Documentation/de/web/community.itexi l. 65) > WARNING: Unable to load the map file > WARNING: Unable to find node 'Entwicklung' in book . > WARNING: Unable to find node 'Entwicklung' in book . They look like translated refs that do not match node names in other, or the other files are not translated. In this case, the translator should choose one from - translate the target node names - keep refs untranslated - use '-named' macros to make texts appear in your language. Currently used to link to untranslated manuals. The problem here is that is difficult to translate only a few chapters while keeping all refs working. It could take you more work to track all broken links than translate all the implied files. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Potential issue 39 fix
I've included before and after photos. Cheers, MS 0001-Potential-fix-for-issue-39.patch Description: Binary data <><>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond authors, release notes, announcements
Hey Graham, Could you please put me under "programming"? Thanks! Mike On Jan 5, 2011, at 12:44 AM, Graham Percival wrote: > It looks like we're getting close to the first release candidate. > > - could any new contributors check: > http://lilypond.org/authors.html > to make sure they're there? if you have git access, you should > be in "development team", and choose your own title. If not, > you should be listed in "current contributors", in whichever > categories you think is relevant. > Our list of translators looks particularly slim. > Send patches for: > Documentation/included/authors.itexi > > - who wants to write release notes? Do it in the same style as > previous ones. Keep it brief because various places have > size limits. > > - based on the written policy: > http://lilypond.org/doc/v2.13/Documentation/contributor/major-release-checklist > - we're not using any potential requirements. > - I'm not paying any attention to "unsorted" stuff. In >particular, I'm not going to send any announcements anywhere >other than lilypond.org. If you think we should be sending >announcements, then start making/updating a list. > > Cheers, > - Graham > > ___ > lilypond-devel mailing list > lilypond-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
Re: Can't compile docs
- Original Message -
From: "Graham Percival"
To: "Phil Holmes"
Cc:
Sent: Thursday, January 06, 2011 7:19 AM
Subject: Re: Can't compile docs
On Wed, Jan 05, 2011 at 05:30:09PM -, Phil Holmes wrote:
pdfTeX warning (dest): name{Invoking abc2ly} has been referenced but does
not e
xist, replaced by a fixed one
pdfTeX warning (dest): name{Invoking musicxml2ly} has been
referenced but does not exist, replaced by a fixed one
These don't look great, but I think they're normal problems.
cp -p web.texi out-www/web.texi
cp: cannot stat `web.texi': No such file or directory
make[3]: *** [out-www/web.texi] Error 1
make[3]: Leaving directory
`/home/phil/lilypond-git/build/Documentation/de'
This is the actual problem, and the de/ part (German) is
absolutely vital, but I don't know how it's happening.
If you run:
git status
do you see something like this?
# On branch master
# Changed but not updated:
# (use "git add/rm ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working
# directory)
#
# deleted:Documentation/de/web.texi
#
I get this:
# On branch master
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# aborted_edits/
nothing added to commit but untracked files present (use "git add" to track)
if so, the build problem is understandable, and you can fix it by
running:
git reset --hard origin
Might be simpler to delete the git directory and start again?
Do you have a
Documentation/de/web.texi
? (if not, git should notice this, but evidently something really
strange is happening, so if you don't see a problem in git status,
please check manually)
NB: you should have *both* a
Documentation/de/web/ directory (or folder), and
Documentation/de/web.texi file
Yes:
p...@phil-lb2:~/lilypond-git/Documentation/de$ ls
essay GNUmakefilemacros.itexi texidocsweb
essay.tely included notation translations.itexi
web.texi
extending learning notation.tely usage
extending.tely learning.tely search-box.ihtml usage.tely
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can't compile docs
On Thu, Jan 06, 2011 at 02:58:22PM -, Phil Holmes wrote: > - Original Message - From: "Graham Percival" > >if so, the build problem is understandable, and you can fix it by > >running: > > git reset --hard origin > > Might be simpler to delete the git directory and start again? I don't think that'll help. > p...@phil-lb2:~/lilypond-git/Documentation/de$ ls > essay GNUmakefilemacros.itexi texidocsweb > essay.tely included notation translations.itexi > web.texi huh. I'm really confused -- especially because one of the benefits of lilydev is that multiple people have (supposedly) exactly the same system (inside the virtual machine), so if anything's broken, everybody should see it broken in the same way. Could you send me the patch you were working on? I know you said you wiped it and went from a clean source, but maybe I can reproduce your problem by trying to compile your patch... (?) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: lilypond authors, release notes, announcements
Mike, I've added you (and others - going back to end of 2009). I'll submit a patch shortly to Graham who will then push it - I don't have git push access. Regards and Happy New Year! James From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of m...@apollinemike.com [m...@apollinemike.com] Sent: 05 January 2011 12:29 To: Graham Percival Cc: lilypond-devel@gnu.org Subject: Re: lilypond authors, release notes, announcements Hey Graham, Could you please put me under "programming"? Thanks! Mike On Jan 5, 2011, at 12:44 AM, Graham Percival wrote: > It looks like we're getting close to the first release candidate. > > - could any new contributors check: > http://lilypond.org/authors.html > to make sure they're there? if you have git access, you should > be in "development team", and choose your own title. If not, > you should be listed in "current contributors", in whichever > categories you think is relevant. > Our list of translators looks particularly slim. > Send patches for: > Documentation/included/authors.itexi > > - who wants to write release notes? Do it in the same style as > previous ones. Keep it brief because various places have > size limits. > > - based on the written policy: > http://lilypond.org/doc/v2.13/Documentation/contributor/major-release-checklist > - we're not using any potential requirements. > - I'm not paying any attention to "unsorted" stuff. In >particular, I'm not going to send any announcements anywhere >other than lilypond.org. If you think we should be sending >announcements, then start making/updating a list. > > Cheers, > - Graham > > ___ > lilypond-devel mailing list > lilypond-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 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: german website problems
Am 06.01.11 13:31, schrieb Francisco Vila: 2011/1/6 Graham Percival: None of these warnings happen in the other languages, so I think they're all problems in the german source, rather than in our build system. make website ... Initializing settings for web site: [de] ** closing warning (1 braces missing) (l. 319) *** Undefined node `Development' in @ref (in /main/src/lilypond/Documentation//web/news-front.itexi l. 29 in @qq) *** Undefined node `Development' in @ref (in /main/src/lilypond/Documentation//web/news-front.itexi l. 46 in @qq) *** Undefined node `Development' in @ref (l. 165) *** Undefined node `Development' in @ref (l. 167) *** Undefined node `Entwicklung' in @ref (in /main/src/lilypond/Documentation/de/web/download.itexi l. 68) ... WARNING: Unable to load the map file WARNING: Unable to find node 'Entwicklung' in book . WARNING: Unable to find node 'Entwicklung' in book . They look like translated refs that do not match node names in other, or the other files are not translated. In this case, the translator should choose one from - translate the target node names - keep refs untranslated - use '-named' macros to make texts appear in your language. Currently used to link to untranslated manuals. The problem here is that is difficult to translate only a few chapters while keeping all refs working. It could take you more work to track all broken links than translate all the implied files. It appears strange to me to get suddenly this kind of errors when I didn't do changes, especially since news-front.itexi is not translated - so how can there be wrong refs? I would rather guess the missing brace causes these messages, but I cannot find it (line 319 in which file? In web.texi it is the last line which is @bye). Also for example node Development is translated in community.itexi as Entwicklung so this should work? Where can I go looking for a log or something that explains the problem a bit better? Thanks Till PS: In the last changes I did to the website I just added a @div... I had forgotten before, so I cannot see what caused the problems now? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Potential issue 39 fix w/ patch
Thanks Keith, I'm sure that you can change stem length at that point in the code. I'll put together something and send it out. I don't mind the horizontal shift, as simultaneous notes are always horizontally shifted if they are the same notable near neighbors. The problem arises when it causes ambiguity in the rhythm. Anyway, I'll get on your suggestion and will leave it to others to decide which one is prettier. In neither case would the solution be very computationally expensive. Cheers, Mike On Jan 5, 2011, at 23:49, Keith OHara wrote: > Mike Solomon ufl.edu> writes: >> I've included before and after photos. > > Hi Mike. > The hemidemisemiquaver(*) and the minim are supposed to be simultaneous, so I > do not like the horizontal shift. > > There is no mention in issue 39 of the desired output. The only thing I can > imagine wanting done automatically is lengthening the stem. Is it too late > for > that when note-collisions are being handled? > > If the best achievable output is only slightly more preferable than the > collision, but costs significant computation for every note-collision, we > might > want to simply note this one as 'not worth fixing with the methods tried so > far'. > > I'll still try your patch. > -- > Keith > > [*] I'm American, actually, so would normally say 64th note; I just like the > cheap thrill I get out of writing hemidemisemiquaver. > > > > ___ > lilypond-devel mailing list > lilypond-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
Re: mensural notation improvements (issue3797046)
Am 06.01.2011 10:56, schrieb Lukas Pietsch: > On Thu, 2011-01-06 at 10:49 +0100, Benkő Pál wrote: > >>> According to Apel (1962: 99), the general rule would seem to be that the dot >>> should be on the right if it applies to the final note of the whole >>> ligature, but on top if it is anywhere else (flexa or no flexa). He has one >>> example of a flexa followed by several square notes, with a dot above the >>> following square note (i.e. in a position that happens to be also just to >>> the right of the flexa), but the dot is meant to apply to the square note >>> over which it stands, not the flexa. >> >> When I have time to go to the library, I'll look up Apel again, >> which codex it is, but if you have a handy scan available (even >> better: a link, e.g. to IMSLP or DIAMM), I'd love to see it. >> >> But let me reiterate: I've seen several codices, and only one >> diverges from the usage I implemented, and even that diverges >> only in dotting not only the first but the last note of a flexa >> above as well. I know that ligatures are not too frequent, >> dotted notes within ligatures are extremely rare, but even the >> two examples I linked clearly dot notes contrary to the Apel way. >> I'll try to find an example where a non-final square note is >> dotted and the following note is below it (in the linked examples >> the next notes are above, so the dot of the first note appears >> _below_ the next note). >> >> p > > Yep, I can see the examples you describe, you are right about them > contradicting Apel's rule. Unfortunately, the examples Apel gives are > schematic self-drawn ones in the text, thus possibly constructed. I > could not quickly find a relevant example in any of the actual > facsimiles in the book. > Lukas > Lukas, Pál, if it helps to confirm that you are right, I might add my own experience with mensural sources. Composers/writers seem to literally avoid dotted notes in ligatures except (a) at the end of the ligature, or (b) on top of the first note of an obliqua, or (c) both. (a) and (b) are frequent, and there are numerous examples. There are some for (c), e.g. the Eton Choirbook that Pál quoted, or Apel, page 471. Sometimes, (d) a dotted first note of a non-obliqua ligature can be found with the dot on the right of the note. This is usually an ascending ligatura cum opposita proprietate (as in Pál's examples, or Apel, p. 181, or p. 138 for a semi-coloured one). I have never seen this with a descending ligature, and I would be interested if you found an example. I don't know any sources that comply with Apel's dot-above rule, but then again, Apel probably saw more sources than I ever will... Sometimes I have been confused by a punctus divisionis placed in the middle above a ligature, but of course that's something different. Best regards, Robert ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1268 in lilypond: [PATCH] span-bar problem
On Sun, Jan 2, 2011 at 6:33 PM, Benkő Pál wrote: > hi Joe, > need to be careful about what happens when bar-size is set. > > Currently, your patch will break (for example) input/regression/drums.ly > > because it ignores bar-size. > > well, I think extent shouldn't be computed from size > as it loses information, but the other way round. > That's true, but we currently allow users to override bar-size (for example in percussion parts). With your current patch, if the user overrides bar-size, then Bar_line::calc_bar_size and Bar_line::calc_bar_extent will give conflicting results (I was wrong earlier when I said that this would affect the printed bar line, but I still think it's bad for the functions to conflict). > AFAICS the intent of the span bar code is to draw lines > not between staves but from line to line, and my patch > reverts this. > of course there's no difference in general, but there is > if bar lines are to have different extent than that of > their staff; and there is a further difference whether > the bar is shorter or longer than the staff: if longer, > there may be no point in using span bars at all; if > shorter, then perhaps span bars are better placed just > between staves (see spantest5.ly). > I don't think the current intention is documented anywhere. If you want to fix a policy now, that's ok with me. I still don't know exactly how should spantest3 behave > (spantest5 makes me feel it works acceptably), neither > what should happen if different bar types are connected > (see spantest4.ly - I hope this is farthest from a real > world case of all my tests). > > >>> I removed the center setting code and that > >>> (with my patch still active) made my example perfect; > >>> however, the attached complementary test (with bar > >>> lines only within staff, not between them) failed, > >>> but it's perfect with current center setting > >>> (independently whether my original patch is active or not). > > >> Since Bar_line::compound_barline is used in both BarLine and SpanBar, > you > >> will need to find some solution that works for both cases. It won't be > as > >> simple as just enabling or disabling the centering code. > > I moved the centering code from compound_barline to print, > and this way all regtests are OK and all my spantests are > good or at least acceptable. > Thanks, this patch looks good. Just a couple of things I'd like to see: - a comment explaining the positioning of span-bars (ie. between bar-lines or between staves?) - agreement between bar-size and bar-extent. There are two solutions I can see, but feel free to invent your own: - deprecate the bar-size property and use bar-extent from now on. This will require a convert-ly rule. - unset bar-size by default (in scm/define-grob-properties.scm). In calc_bar_extent, check to see if bar-size is set. If it is, use it. Otherwise, use the staff extent Here are a couple other suggestions that I think would improve the code. I'd be happy to commit your patch without them because they reflect problems with the existing code rather than problems with your patch. But if you have time, it would be nice :) - Shouldn't Bar_line::print use bar-extent rather than bar-size? That seems more natural. - The centering issue regarding compound_barline still seems strange. Wouldn't it be nicer if compound_barline took Real bottom and Real top (or maybe Interval) parameters (instead of Real h) and drew a bar line whose Y-extent stretched from bottom to top? That seems like a more intuitive API to me (and unlike the current one, it's self-documenting). Thanks for your work, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Black mensural notation
I tried running it on a current development snapshot this week, but it didn't have enough memory to run nicely and bogged down my computer with swap traffic (I've got 2 MB here). I gave up on it before it finished. Does it take long to compile the PDF on your system? Andrew On Tue, Jan 4, 2011 at 6:14 AM, Lukas Pietsch wrote: > On Tue, 2011-01-04 at 11:49 +0100, Werner LEMBERG wrote: > >> Very impressive! Could you try to make it work with the current >> development version? The next steps could then be adding the missing >> glyph shapes to the lilypond fonts, followed by either writing a new >> engraver or modifying/fixing/correcting the existing ones.q > > Unfortunately, I've had some problems getting any other version than the > current standard package from my Linux distribution cleanly installed on > my system (probably I'm just not Linux-savvy enough). I've now uploaded > a test file http://lukas-pietsch.de/Music/mensuraltest.ly and the > expected output http://lukas-pietsch.de/Music/mensuraltest.pdf, with the > same snippets as in the documentation pdf. If anybody could be so kind > as to try and run that through their Lilypond installation? > > I'd heard about the possibility of writing one's own engravers in > Scheme, which would certainly have been the more elegant way of doing > most of this, but I couldn't find it accessibly documented anywhere and > it didn't seem to be supported on the older versions anyway. > Lukas > > > ___ > lilypond-devel mailing list > lilypond-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
Re: german website problems
On Thu, Jan 06, 2011 at 07:25:48PM +0200, Till Paala wrote: > It appears strange to me to get suddenly this kind of errors when I > didn't do changes, I only check once every couple of months. It might have broken last October (or even earlier). > especially since news-front.itexi is not translated - so how can > there be wrong refs? - es (spanish) docs don't have this problem. - de (german) docs have this problem. Go look at the Spanish (or French) docs, and do whatever they do. > I would rather guess the missing brace causes these messages, but I > cannot find it (line 319 in which file? Dunno. > Also for example node Development is translated in community.itexi > as Entwicklung so this should work? Dunno. Go look at the Spanish docs, and do whatever they do. > Where can I go looking for a log or something that explains the > problem a bit better? Run: make website you might also want to read: http://lilypond.org/doc/v2.13/Documentation/contributor/translating-the-website > PS: In the last changes I did to the website I just added a @div... > I had forgotten before, so I cannot see what caused the problems > now? Did you add a @divEnd as well? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
