Re: Font license. Was: Waltrop meeting outline
2012/8/28 Mats Bengtsson mats.bengts...@ee.kth.se: Han-Wen Nienhuys wrote: Change font license from GPL to dual licensed OFL / GPL (see http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiid=OFL_web) We have agreement of this from the people who were here: Author: Janek Warchol lemniskata.bernoull...@gmail.com Author: Jan Nieuwenhuizen jann...@gnu.org Author: Marc Hohl m...@hohlart.de (*) - Graham I noticed my name was on the list of font contributors. I don't have any problem with whatever licensing form you choose. Same here. I'm happy to go along with whatever you decide. As an aside, I'd like to take this opportunity to say thanks for all the amazing work you guys do for Lilypond (and especially for getting 2.16 released)! I must admit that the last time I actively used it was probably a few years ago, but just seeing all the improvements and the constant flow of things going on is mindblowing. Kudos to all involved! Best wishes, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ugliness in the Learning Manual
Hi all, 2) list all environment variables used (both internally and externally) in the build system in the CG. Advantage: at least this knowledge is written down somewhere. Disadvantage: the list will not be kept up-to-date. (don't argue; there's absolutely nothing you can say that will make me believe that everybody will keep it up-to-date over the next 20 years) Think it's quite a bit of work, too. I don't know anything about the build system, but isn't it possible to do this automatically? Say, if you rename all lilypond-related environment variables so that they start with LILY_ then why can't you say something like 'env | grep LILY_' and put the output into the CG? Please ignore if this doesn't make any sense, I haven't followed the thread closely so I may be missing something. Cheers, Max P.S.: Since Graham mentioned getting rid of environment variables: only very recently have I started to appreciate the enormous value they have once you work on systems where things are just slightly different than what everyone considers to be standard because everyone uses Ubuntu (I'm exaggerating, of course) - or even just for testing different configurations on the same system. So personally I'd say try to keep them if at all possible. Just my two cents. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: imprecise Taktlinie in german doc (NR)
2010/5/12 Henning Plumeyer h.plume...@web.de: Am 12.05.2010, 20:58 Uhr, schrieb Matthias Kilian k...@outback.escape.de: I'm not an active musician, and only decades ago I did do music with others (orchestra, choir), so I may be wrong, but I've a strong feeling towards `Taktnummern'. It's less ambigous. I've been in hundreds of rehearsals and never heard the word Taktnummern, only Taktzahlen. Same here. :) Although in a rehearsal one would usually just say something like in Takt ... instead of using a construction involving Taktzahlen. Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix #305: Allow dynamics to be positioned independently
Hi Neil,
sorry for the long delay in my follow-up.
As a user, I would normally not include it since I'm not aware of it and
would thus think that manual positioning of hairpins simply doesn't
work (or is buggy). Is there a way to avoid it (e.g., by having
Lilypond automatically detect when two hairpins point in different
directions)?
I'm sure it's feasible, though it's going to increase the complexity
somewhat due to the necessity of caching the previous direction. I'll
see what I can do.
That would be awesome!
Bear in mind though that an explicit command is necessary for
situations where the direction doesn't change (for example, the last
dynamic in the regression test).
Fair enough. But the need of \breakDynamicSpan in such a situation
would be much more obvious to a user, I guess, and even someone not
knowing about the exact command might start looking it up in the
documentation (whereas the abovementioned behaviour simply looks like
a bug).
Also, is there a way to 'activate' \breakDynamicSpan
somehow so that it applies to all future hairpins/dynamics?
It might be possible to redefine dynamic commands to send a break
request automatically, though there is one limitation due to the way
the engraver's coded: you can't have separate alignments for the case
where there's an absolute dynamic directly followed by a span dynamic.
For example, the following snippet wouldn't produce separate alignment
spanners for the forte and hairpin:
\relative c' {
c1_\f^\
c1\!
}
Hmm, okay. I suppose that in most cases people wouldn't want the
hairpin to point in a different direction anyway. Nonetheless, someone
might request it one day. So would you consider this limitation as a
bug?
Thanks again for your work!
Max
P.S.: Your patch hasn't been applied yet, has it?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix #305: Allow dynamics to be positioned independently
2009/10/12 Neil Puttock n.putt...@gmail.com: Please review this patch here: http://codereview.appspot.com/129073/show I've added a general event class, BreakSpanEvent, as the parent class of BreakDynamicSpanEvent since I'd eventually like to implement commands analogous to \breakDynamicSpan for some of the other alignment spanners (e.g., pedals and figured bass). Awesome, thanks for your work, Neil! Just one question: Why is it necessary to explicitly specify the \breakDynamicSpan command? As a user, I would normally not include it since I'm not aware of it and would thus think that manual positioning of hairpins simply doesn't work (or is buggy). Is there a way to avoid it (e.g., by having Lilypond automatically detect when two hairpins point in different directions)? Also, is there a way to 'activate' \breakDynamicSpan somehow so that it applies to all future hairpins/dynamics? Thanks again, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
2009/9/7 Michael Käppler xmichae...@web.de: Hi all, Hmm... was there any progress since July on this topic? I'd like to year if there's anything new... ;) Not really, I'm afraid. The reason is that I've been abroad for a few months and couldn't really work on this for the last couple of weeks. I won't have any access to my computer for another week and will move to England afterwards, so expect it to be on hold for another month or so. But once I've settled on the island, I hope I can spend more time on this. Sorry for the delay. I'll keep you posted. Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `+repage' option for convert?
2009/8/24 Patrick McCarty pnor...@gmail.com: BTW, if anyone can find a better set of options for convert, please let me know. imagemagick has major problems with SVG-PNG conversion, which is why I added all of these other flags. I haven't followed this discussion so I apologize if my comment is not relevant. But I remember seeing a dependency of Inkscape mentioned in a different thread. Have you considered using it for SVG -- PNG conversion? Perhaps it gives better results. Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
2009/8/12 Johannes Schindelin johannes.schinde...@gmx.de: Yep, verified. Many thanks once again! I think this can be very useful for new contributors. I hope so. Maybe you tell me the most common operations, and I'll add the functionality? Hmm, I'm probably not the right person to ask because I guess I'm not the kind of contributor this script is targeted at (I was just interested in how it works and in testing it :-P). Also, I usually prefer the flexibility of working from the command line. But I'm sure there are plenty of others who will have many suggestions! Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
2009/8/11 Johannes Schindelin johannes.schinde...@gmx.de: Okay, I could not resist, so here is something more capable. Thanks for not being more resistable. :-) (And for giving a nice illustration how easy it actually is to write a quick hacked-up GUI - I guess that'll be useful to me on many occasions in the future). It actually only gives you a Clone/Update button that makes sure that a local clone (hardcoded to $HOME/lilypond) is up-to-date, but at least it has a progress bar, and I verified that it works even on Windows (what with its ridiculous insistence to put everything into directories containing spaces). When I try that script, I end up with an empty directory (i.e., only the .git subdirectory is present). Running git status says that all the files in the source tree were deleted. I can thus recreate them by running git reset --hard HEAD. What's happening here? Thanks, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
2009/8/11 Johannes Schindelin johannes.schinde...@gmx.de: It actually worked here, twice. But you have this wonderful output field in the GUI, what does it have to say? I imagine that it gave you some error message or some such (probably due to an older Git version that refuses to update the current 'master' branch -- which has no commit yet, though). Sorry, I should of course have posted the output in the first place: == Initialized empty Git repository in /home/username/lilypond/.git/ From git://repo.or.cz/lilypond * [new branch] master - origin/master warning: You appear to be on a branch yet to be born. warning: Forcing checkout of origin/master. Already on master Branch master set up to track remote branch refs/remotes/origin/master. == So it doesn't give an error, just a warning. But AFAIR I have seen this warning on my non-GUI-based checkouts, too, even though everything worked fine. BTW, my git version is 1.6.0.4 (the latest one that Ubuntu 9.04 has to offer). So I would like to ask you two things: first, what was the error message (there must have been one), and second: could you change the git checkout -b master origin/master to git reset --hard origin/master git config branch.master.remote origin git config branch.master.merge refs/heads/master ? Still no luck. :-( The warning is gone, but the result is as before (directory is empty, 'git status' reports deleted files). Here is the output of the new script: == Initialized empty Git repository in /home/username/lilypond/.git/ From git://repo.or.cz/lilypond * [new branch] master - origin/master HEAD is now at 00c6cac Nitpick: ly:spanner-bound grob name slur - spanner. == Thanks for your help, Max P.S.: It would be nice to let the script print a short message when it's finished so that the user know when to stop waiting. ;-) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
Hi Johannes,
I pushed a new version to git://repo.or.cz/lilypond/dscho.git. You can
download it directly here:
http://repo.or.cz/w/lilypond/dscho.git?a=blob_plain;f=lilycontrib.tcl;hb=lilycontrib
Cool, works like a charm now. Thanks a lot!
One minor comment: For new contributors with no experience in git (or
version control in general) it may seem as though nothing happens
after pressing the button. Thus I'd suggest to add two messages to
indicate that the process was started, along the lines of:
==
proc update_lilypond {} {
global lily_dir
if {![file exists $lily_dir]} {
write_to_output Starting to clone LilyPond repository (this
can take some time) ...\n
file mkdir $lily_dir
git init
git config core.bare false
git remote add -t master \
origin git://repo.or.cz/lilypond.git
git fetch --depth 1
git reset --hard origin/master
git config branch.master.remote origin
git config branch.master.merge refs/heads/master
.update configure -text Update LilyPond
} else {
write_to_output Starting to update LilyPond repository ...\n
git fetch origin
git merge origin/master
}
write_to_output Done.\n
}
==
Cheers,
Max
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
2009/8/11 Johannes Schindelin johannes.schinde...@gmx.de: I actually had to change the --work-tree things, since it is utter garbage. I _know_ why I was opposed to its inclusion. [..] I added two shorter notices, and I also set the busy cursor now. Hehe, sorry for complaining again. But now the script aborts with an error about the missing $lily_dir directory. When I manually create it, the script starts and shows the Update button, but upon pressing the button the script complains that the directory is not a git repository (obviously ...). Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
2009/8/12 Johannes Schindelin johannes.schinde...@gmx.de: Fixed and pushed. Yep, verified. Many thanks once again! I think this can be very useful for new contributors. Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: keyboard navigation in html docs
2009/7/30 Francisco Vila paconet@gmail.com: I think it's possibly to detect keypresses in javascript. Javascript not needed. Links can have a href=... accesskey=n title=Next [n] ... Next/a Cool! I didn't know that. 1) Would it be cool or annoying to press n in the docs to proceed to the next page? Admittedly this would be much more useful in the LM than the NR. Cool, provided that does not interfere with the Firefox's 'search while you type' feature. Agreed. I don't know how the wikipedia example above manages to use alt-P. I have the mentioned Firefox's feature enabled and this works nevertheless. I just had a quick look at a German HTML reference and it says (if I understood correctly) that different browsers use different keyboard modifiers to access the accesskeys. In my version of Firefox (3.0.12) I need to use Alt+Shift, for example (actually, it says that the same is true for Firefox 2.x so I'm wondering why just Alt+P works for you). In any case, it seems that there is no interference with the 'search as you type' feature, so I'd find this pretty cool, too. Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Main page of new website [was: some css tweaks]
Hi all, sorry, this is only going to be a quick reply and I'll be away on the leave for a few days (or perhaps even up to 1-2 weeks), so a more elaborate reply will have to wait until I'm back. I started writing up a longer email, but I realized that what I said was so imprecise (because it's more related to some vague feelings I'm having rather than to specific issues I could put my finger on) that I decided to think about it a bit more thoroughly and get back to you when I have more specific suggestions. My apologies for the noise so far. What about showing ... music notation for everyone in a larger font size, That would definitely be a big improvement, and one which is most easy to achieve. I'd vote for it. BTW, I just noticed that there is now a second subtitle on http://lilypond.org/~janneke/lilypond.org/ which reads free music notation software. IMHO this destroys the slogan-ness of the title to some extent and makes it more clumsy to read because of the additional line. Why not simply increase the font size of ... music notation for everyone? [...] and adding a small cropped excerpt of Lily-generated picture of music at the right of LilyPond title? That might be a good thing, too, although on second thought I tend to agree with Graham's concerns about having two pictures next to the title. Also, I fear that simply pasting some LilyPond output might make the page appear less well-integrated. Although on second thought I may be wrong. Perhaps it's worth a try. You proposed something similar later in your talkative email, did you have in mind something like the attached pitcure? Sorry for having been talkative, I could/should have condensed my thoughts properly before sending this. But it was late, I had had a long day and was tired so I hope you didn't mind me just writing what came to my mind. In any case, I sincerely hope I didn't step on anyone's feet, and in the end it's not my opinion that counts anyway. It was just something I felt and wanted to mention. OK, more to follow when I'm back and have a better idea of what I really want to talk about. :-) All the best and thanks for everyone's hard work! Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond concept glossary?
+2009/7/31 Mark Polesky markpole...@yahoo.com: It would be nice to have some central place that explains some internals concepts. Here are examples of things that a new developer might have to ask about, or perhaps spend a long time disentangling: [...] Any thoughts? +10 :-) Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Main page of new website [was: some css tweaks]
Hi all, Attached are some css tweaks, you can see them in action at http://lilypond.org/~janneke/lilypond.org Following the link reminded me of a comment I already wanted to make a while ago. While we are at changing the design of the website (which I consider a very good thing), I'd strongly suggest that we take the opportunity and make it more easily recognizable *at the first glance* that LilyPond is a *music* notation software. I know that it says so in the subtitle, that there is the explanation What is LilyPond directly beneath it and that the image features some notes and staves in the background. But frankly, even though I was actively looking for it when opening the new page for the first time, it took me a while to find the information what LilyPond actually does. The subtitle is really small so that all you actually read is LilyPond (which doesn't give a clue to uninitiated), the paragraph about LilyPond beneath it almost vanishes among the News and the notes in the image are only recognizable if you actively for look them. Now imagine potential new users who more or less accidentally browse to the website. I may be wrong, but from personal experience I'd say that they decide within the first (few) second(s) if they close the window again or if they want to take a closer look. And if the site doesn't give them a good and decided incentive to stay, they will leave, which I'd find a pity. Don't get me wrong, I like the new design. But I think with a couple of small tweaks it can be made into a real eye- (and new-user-)catcher instead of just a nicely-looking but not overly captivating webpage. Unfortunately, I'm not a graphic designer, so I can't make very good suggestions apart from the points mentioned above. Maybe put a big note next to the title? Perhaps even the image from the introduction, which I think excellently conveys LilyPonds mixture of professionality and aesthetics? BTW, now that I look at it again, I feel that the picture of the lily does not totally get the message across how much emphasis LilyPond puts on good and professional design and quality (and how good it actually is). This was already the case with the old image, and the new one is _a lot_ better, but to me it seems that there is still a gap between the quality of the software and its representation towards the world (via the website). Am I the only one? Sorry, this was a long email for a very simple message. And again, I apologize that my remarks are hardly constructive (maybe others have better suggestions?) . But I'd really like to see a faszinating, well-polished and attractive new site. I think LilyPond deserves it, and this is the opportunity. Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
2009/7/27 Werner LEMBERG w...@gnu.org: - What is a good name for the new articulation? I suggest `vertical stroke'. At least this seems to be the name referred to in the literature for the staccato-like symbol which Mozart uses. OK, considering the many different meanings this symbol can apparently have, I guess that's the most sensible suggestion. - What should be the precise shape (width/height ratio)? Currently I use height = 1 staff_space and width = 1/5 staff_space (see attached sample). Opinions? For Mozart, the stroke should perhaps a bit shorter -- maybe two different symbols? Attached are two samples for long and short strokes with varying width. The long strokes have height = staff_space, the shorter ones height = 0.8*staff_space (is that a reasonable choice?). Each file contains strokes of each type with ten different widths, namely i*0.05*staff_space, for i=1,..,10. Which do you prefer? I tend to lean towards #4 for the shorter ones and #4 or #5 for the longer ones, but that's just my personal aesthetics. I'd be happy about opinions from you guys because I have never seen this symbol in a real score and am simply trying to provide the code. But I'd prefer to leave the choice of the actual appearance to people more knowledgeable in this area. Thanks, Max vstroke_long.pdf Description: Adobe PDF document vstroke_short.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Arrowed accidentals for microtone notation
Hi all, I just rediscovered this old thread during some recent work and realized that there are still some pending updates for the docs concerning microtonal notation. This has got buried for more than half a year (presumably because it was Christmas time when I sent my last email), but I'd appreciate if someone could take a look at it and let me know if it's OK to apply or what should be changed. For details about the discussion at the time, see http://www.mail-archive.com/lilypond-devel@gnu.org/msg19087.html and the replies in that thread. Attached are the patches again (updated to reflect the rearranged docs structure). Thanks, Max 2008/12/21 Maximilian Albert maximilian.alb...@googlemail.com: Hi again, here is some documentation for the arrowed accidentals. Since I found it the most natural way of typesetting, it uses Trevor's notation for up and down arrows (but also mentions the alternative ways discussed before). Please let me know if for some reason Trevor's default names are not desired so that I can rewrite the docs accordingly. Note that the attached patches supersede the one in my last email. Cheers and merry christmas to everyone! Max From 0e521721ec3244bfc994f73d68440b1e4f066458 Mon Sep 17 00:00:00 2001 From: Maximilian Albert maximilian.alb...@gmail.com Date: Sat, 20 Dec 2008 19:34:11 +0100 Subject: [PATCH] New alterations for microtones and default names for notes with arrowed accidentals in english.ly --- ly/english.ly| 59 ++ scm/lily-library.scm |5 scm/output-lib.scm |5 3 files changed, 69 insertions(+), 0 deletions(-) diff --git a/ly/english.ly b/ly/english.ly index fec9b11..1b92d55 100644 --- a/ly/english.ly +++ b/ly/english.ly @@ -125,6 +125,65 @@ pitchnamesEnglish = #`( (btqs . ,(ly:make-pitch -1 6 THREE-Q-SHARP)) (bss . ,(ly:make-pitch -1 6 DOUBLE-SHARP)) (bx . ,(ly:make-pitch -1 6 DOUBLE-SHARP)) + + ;; arrowed accidentals + (cflatdown . ,(ly:make-pitch -1 0 FLAT-MICRO-DOWN)) + (cflatup . ,(ly:make-pitch -1 0 FLAT-MICRO-UP)) + (csharpdown . ,(ly:make-pitch -1 0 SHARP-MICRO-DOWN)) + (csharpup . ,(ly:make-pitch -1 0 SHARP-MICRO-UP)) + (dflatdown . ,(ly:make-pitch -1 1 FLAT-MICRO-DOWN)) + (dflatup . ,(ly:make-pitch -1 1 FLAT-MICRO-UP)) + (dsharpdown . ,(ly:make-pitch -1 1 SHARP-MICRO-DOWN)) + (dsharpup . ,(ly:make-pitch -1 1 SHARP-MICRO-UP)) + (eflatdown . ,(ly:make-pitch -1 2 FLAT-MICRO-DOWN)) + (eflatup . ,(ly:make-pitch -1 2 FLAT-MICRO-UP)) + (esharpdown . ,(ly:make-pitch -1 2 SHARP-MICRO-DOWN)) + (esharpup . ,(ly:make-pitch -1 2 SHARP-MICRO-UP)) + (fflatdown . ,(ly:make-pitch -1 3 FLAT-MICRO-DOWN)) + (fflatup . ,(ly:make-pitch -1 3 FLAT-MICRO-UP)) + (fsharpdown . ,(ly:make-pitch -1 3 SHARP-MICRO-DOWN)) + (fsharpup . ,(ly:make-pitch -1 3 SHARP-MICRO-UP)) + (gflatdown . ,(ly:make-pitch -1 4 FLAT-MICRO-DOWN)) + (gflatup . ,(ly:make-pitch -1 4 FLAT-MICRO-UP)) + (gsharpdown . ,(ly:make-pitch -1 4 SHARP-MICRO-DOWN)) + (gsharpup . ,(ly:make-pitch -1 4 SHARP-MICRO-UP)) + (aflatdown . ,(ly:make-pitch -1 5 FLAT-MICRO-DOWN)) + (aflatup . ,(ly:make-pitch -1 5 FLAT-MICRO-UP)) + (asharpdown . ,(ly:make-pitch -1 5 SHARP-MICRO-DOWN)) + (asharpup . ,(ly:make-pitch -1 5 SHARP-MICRO-UP)) + (bflatdown . ,(ly:make-pitch -1 6 FLAT-MICRO-DOWN)) + (bflatup . ,(ly:make-pitch -1 6 FLAT-MICRO-UP)) + (bsharpdown . ,(ly:make-pitch -1 6 SHARP-MICRO-DOWN)) + (bsharpup . ,(ly:make-pitch -1 6 SHARP-MICRO-UP)) + + (csu . ,(ly:make-pitch -1 0 SHARP-MICRO-UP)) + (csd . ,(ly:make-pitch -1 0 SHARP-MICRO-DOWN)) + (cfu . ,(ly:make-pitch -1 0 FLAT-MICRO-UP)) + (cfd . ,(ly:make-pitch -1 0 FLAT-MICRO-DOWN)) + (dsu . ,(ly:make-pitch -1 1 SHARP-MICRO-UP)) + (dsd . ,(ly:make-pitch -1 1 SHARP-MICRO-DOWN)) + (dfu . ,(ly:make-pitch -1 1 FLAT-MICRO-UP)) + (dfd . ,(ly:make-pitch -1 1 FLAT-MICRO-DOWN)) + (esu . ,(ly:make-pitch -1 2 SHARP-MICRO-UP)) + (esd . ,(ly:make-pitch -1 2 SHARP-MICRO-DOWN)) + (efu . ,(ly:make-pitch -1 2 FLAT-MICRO-UP)) + (efd . ,(ly:make-pitch -1 2 FLAT-MICRO-DOWN)) + (fsu . ,(ly:make-pitch -1 3 SHARP-MICRO-UP)) + (fsd . ,(ly:make-pitch -1 3 SHARP-MICRO-DOWN)) + (ffu . ,(ly:make-pitch -1 3 FLAT-MICRO-UP)) + (ffd . ,(ly:make-pitch -1 3 FLAT-MICRO-DOWN)) + (gsu . ,(ly:make-pitch -1 4 SHARP-MICRO-UP)) + (gsd . ,(ly:make-pitch -1 4 SHARP-MICRO-DOWN)) + (gfu . ,(ly:make-pitch -1 4 FLAT-MICRO-UP)) + (gfd . ,(ly:make-pitch -1 4 FLAT-MICRO-DOWN)) + (asu . ,(ly:make-pitch -1 5 SHARP-MICRO-UP)) + (asd . ,(ly:make-pitch -1 5 SHARP-MICRO-DOWN)) + (afu . ,(ly:make-pitch -1 5 FLAT-MICRO-UP)) + (afd . ,(ly:make-pitch -1 5 FLAT-MICRO-DOWN)) + (bsu . ,(ly:make-pitch -1 6 SHARP-MICRO-UP)) + (bsd . ,(ly:make-pitch -1 6 SHARP-MICRO-DOWN)) + (bfu . ,(ly:make-pitch -1 6 FLAT-MICRO-UP)) + (bfd . ,(ly:make-pitch -1 6 FLAT-MICRO-DOWN)) ) pitchnames = \pitchnamesEnglish diff --git a/scm/lily-library.scm b/scm/lily-library.scm index d1cce2a..22d1123 100644 --- a/scm/lily-library.scm +++ b/scm/lily-library.scm @@ -44,6 +44,11
Re: PATCH: Arrowed accidentals for microtone notation
2009/7/27 Graham Percival gra...@percival-music.ca: I'm not at all certain that these arrows should be indicated with different pitch names -- why not define \accidentalArrowsOn \accidentalArrowsOff or some such commands, then use the regular pitch names? I guess for the same reason why you don't want generic \sharpOn, \sharpOff, \flatOn, \flatOff commands -- because arrowed accidentals indicate a pitch different from the regular one and you would still like to be able to easily use notes with arrowed accidentals along notes with regular accidentals. But I'm not a user of microtonal music at all, so let's wait for the experts to chime in. In addition, the default language in lilypond is Dutch, so I must insist that you add -is -es style pitch names (if there's a compelling reason to use separate pitch names). The main documentation would also need to use those Dutch names. OK, I'll see to providing these once we have an agreement what we really want. Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
2009/7/27 Michael Käppler xmichae...@web.de: Attached are two samples for long and short strokes with varying width. The long strokes have height = staff_space, the shorter ones height = 0.8*staff_space (is that a reasonable choice?). Each file contains strokes of each type with ten different widths, namely i*0.05*staff_space, for i=1,..,10. Which do you prefer? I tend to lean towards #4 for the shorter ones and #4 or #5 for the longer ones, but that's just my personal aesthetics. Me too, #4 or #5. But I think the long stroke could be longer, maybe 1.2*staff_space or so? Like in the attached file? In this case, I'm inclined to favour #5 (or maybe even #6), but I'm only judging this based on the appearance on the screen because I don't have a good printer at hand. Thus any further opinions or suggestions for improvement are still very welcome. Max vstroke_long__1.2_staffspace.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
2009/7/27 Michael Käppler xmichae...@web.de: Additionately, maybe it would be nice to increase the relative thickness of the stroke on smaller staff sizes as it's described in NR 4.2.1 for the Feta font. Otherwise the line will look too thin at smaller staff sizes, I think. Ah, interesting point. I have no clue, though, how to achieve this code-wise (i.e., how to specify different glyph shapes for different font sizes). Can anyone (Werner, perhaps?) point me in the right direction? Also, by what amount is the glyph weight usually increased (what exactly does that mean, anyway)? Thanks, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feature-request / doc-actualization (right-margin)
2009/7/27 Werner mey@web.de:
Are the two sentences in Known issues and warnings in the Horizontal
dimensions section clear enough?
Sorry - I hadn't seen this. It is clear. So the doc is OK.
But the feature-request to provide right-margin remains.
Wondering why this is so difficult that it has been an issue for such
a long time, I took a look at scm/page.scm and played around with the
code there. It turned out that it's relatively easy to make Lilypond
take the setting for right-margin into account (see attached patch)
but I ran into the following problems:
1) The code in scm/page.scm is able to test whether left-margin and/or
right-margin was specified by the user in the \paper block (if this
isn't the case, the value is #f). However, the same doesn't seem to be
true for line-width because this variable _always_ has a value (i.e.,
it cannot be undefined like the other two). Thus I cannot check
whether both the left+right margins *and* the line-width were
specified by the user. As Werner pointed out, we should print a
warning in this case and discard one of the values. BTW, how can I
find out which of the values was specified last in the .ly file so
that that's the one taken into account?
2) With the attached patch, the following works as expected.
=== BEGIN CODE ===
\paper {
left-margin = 2 \cm
right-margin = 3 \cm
}
\relative c' { \repeat unfold 100 { f } }
=== END CODE ===
When adding the line
line-width = 10 \cm
to the \paper block it still kinda works (the line-width value is
simply discarded so that the margins are as specified). Interestingly,
however, the value of line-width still has an effect on the *spacing*
of the notes. Namely, the notes are spaced as if the line-width were
truly 10cm but then the line gets stretched to account for the margin
values. How can this be avoided? Or is it even a feature rather than a
bug? (I can imagine that some users might want to make use of this to
achieve tighter or wider spacing, although I'm not sure that's a good
idea.)
Thanks for any help,
Max
diff --git a/scm/page.scm b/scm/page.scm
index a486219..a9c921f 100644
--- a/scm/page.scm
+++ b/scm/page.scm
@@ -221,15 +221,25 @@
((paper-height (ly:output-def-lookup layout 'paper-height))
(paper-width (ly:output-def-lookup layout 'paper-width))
(lmargin (ly:output-def-lookup layout 'left-margin #f))
+ (rmargin (ly:output-def-lookup layout 'right-margin #f))
+ (lwidth (ly:output-def-lookup layout 'line-width))
(left-margin (if lmargin
lmargin
- (/ (- paper-width
- (ly:output-def-lookup layout 'line-width)) 2)))
+ (if rmargin
+ (- paper-width lwidth rmargin)
+ (/ (- paper-width lwidth) 2
(bottom-edge (- paper-height
(ly:output-def-lookup layout 'bottom-margin)) )
(top-margin (ly:output-def-lookup layout 'top-margin))
)
+(if (and lmargin rmargin)
+ ;; FIXME: If both margins _and_ the line-width was specified
+ ;; in the ly file then we should print a warning here. Also,
+ ;; curiously, setting the line-width still has an effect on
+ ;; the spacing of the notes even when both margins are given.
+ (ly:output-def-set-variable! layout 'line-width (- paper-width lmargin rmargin)))
+
`((paper-height . ,paper-height)
(paper-width . ,paper-width)
(left-margin . ,left-margin)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
2009/7/25 Werner LEMBERG w...@gnu.org: I don't object to add it to the font, so please add it as a feature request. Given that the shape is basically only a rectangle, this should be easy to do. I've got a patch more or less ready but there are a couple of small questions: - What is a good name for the new articulation? - What should be the precise shape (width/height ratio)? Currently I use height = 1 staff_space and width = 1/5 staff_space (see attached sample). Opinions? - Should the corners of the rectangle be sharp (as in the sample file) or rounded; if the latter, by which amount? Thanks, Max line-articulation.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
2009/7/26 Carl Sorensen c_soren...@byu.edu: I think that Werner was saying the feature request is to add a glyph to the font. But while we wait for that to happen, to add a drawn rectangle is a definite benefit. I was talking about adding a glyph to the font, too. But the glyph is basically just a rectangle, and there already exists a function for drawing these (to wit, draw_rounded_block() in feta-macros.mf), so it's not a big deal. It's just a question of fiddling with the parameters and finding a nice name for the glyph. Hence my questions. The corners of the rectangle should *definitely* be rounded (all of LilyPond engraving is rounded). The standard radius is half of line-thickness. OK, thanks. Any suggestions for a name? I can't think of a good one which concisely captures the glyph's meaning (mainly because I don't know what that meaning is :-P). Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
2009/7/24 Valentin Villenave v.villen...@gmail.com: Another point is the horizontal position: If the line is placed above the stem, it seems better to me to have both in one horizontal position (not centered above the NoteHead), though I can't recognize any clear conventions for it up to now. I think this would be a terrible idea. All articulation marks are centered with the note head. As a musician, I'd be terribly confused if I were to suddently encounter an articulation mark that's centered with the stem. It's not correct that articulations are always centered with the note head. See http://code.google.com/p/lilypond/issues/detail?id=218 and the examples attached there. This is precisely what toward-stem-shift was introduced for. :-) Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SVG status update
2009/7/14 Patrick McCarty pnor...@gmail.com: Unfortunately, this would be very difficult. Elements are dumped into the SVG file in the order they occur in the page stencil, and (almost) every one is independently positioned as well. Ah, okay. That's what I though. Out of interest: At the time when these elements get written into the SVG file, do they know about their mutual relationships? E.g., does a beam know which note heads it belongs to (or vice versa)? Some of the related stencils are dumped consecutively (e.g. the horizontal StaffSymbol lines), but I imagine this would require some postprocess optimization, which is an interesting feature request. I'll add this to the wiki. Following my question above, here is another random idea: Would it be possible to (perhaps optionally) set the id attributes of the elements to something meaningful from which at least the function of this element could be deduced, like staffline01 or barline42 or something similar? This could be a first step to enable some postprocessing. BTW, I'm not saying that you should implement this. I'm just interested whether it would be possible. I'm happy to be working on it, and I'm glad you appreciate it. Yes, I do (and apparently I'm not alone). :-) Max P.S.: What's all this about text element being rasterized or converted to paths? I can edit them as regular text elements in Inkscape without problems. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SVG status update
Hi Patrick, Ah, okay. That's what I though. Out of interest: At the time when these elements get written into the SVG file, do they know about their mutual relationships? E.g., does a beam know which note heads it belongs to (or vice versa)? No. The closest thing the elements possess that relates to this is their *grob cause*. For example the NoteHead grob is often the grob cause for the noteheads.s2 glyph. OK, thanks for the explanation. I seem to remember that some time ago I was in a similar situation, where I wanted to find out some elements' parent(s) from my code but was unable to, probably for precisely this reason. Do you happen to know at what stage of the engraving process elements are aware of their mutual relationships, just in case I stumble across this problem again in the future? That's possible, but it would be much easier to insert comments based on the grob cause mentioned above. It would look something like !-- NoteHead -- path transform=translate(...) scale(...) d=... / Would that be reasonable? Sure. But as I said, as far as I'm concerned you don't need to spend time on this right now (you've got lots of other things to do, I suppose). It may even be the case that some people don't want the comments in their files because they blow up the file size. But in case we want to have automatic grouping in the future (either natively or via some postprocessing) it's good to know that inserting comments like this is an option. Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SVG status update
Hi Patrick, So I spent a few hours today hacking on the SVG output, and here are some samples of the current output I have: [...] Great work!! Just a random comment that occurred to me while skimming through your samples: When moving individual elements (like note heads, staff lines, beams, etc.) with the mouse, I noticed that they all moved individually because they are all at the toplevel of the SVG file. Would it be possible to group elements belonging together (visually or conceptually), like the staff lines, note heads with their stems and beams, etc.? I have no clue how Lilypond's SVG output works internally so this may be highly nontrivial (for example, I noticed that the final bar line in bach-schenker is split into three parts, which indicates that these are not drawn in one go, perhaps even at very different time steps). But if it's simple to achieve it might be a good addition. Anyway, thanks again for your excellent work on this. Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: Delete intermediate ps files
2009/7/13 Neil Puttock n.putt...@gmail.com: Thanks, they're both applied. Thanks a lot! So does this close issue 685? What's the status about .log files being created on Windows mentioned there? Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Replace deprecated md5 module by hashlib
2009/7/11 Neil Puttock n.putt...@gmail.com: How about using a `try' block to import conditionally? Thanks for the suggestion. Here is an updated patch, in case peope want to have this (otherwise please ignore). Cheers, Max From 5066717052db35b69af549e1189a88090e12fb78 Mon Sep 17 00:00:00 2001 From: Maximilian Albert maximilian.alb...@gmail.com Date: Sun, 12 Jul 2009 12:22:16 +0900 Subject: [PATCH] Use hashlib instead of deprecated md5 module if Python = 2.5 is present --- scripts/lilypond-book.py |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py index e851a40..ebea918 100644 --- a/scripts/lilypond-book.py +++ b/scripts/lilypond-book.py @@ -29,7 +29,6 @@ TODO: ''' import glob -import md5 import os import re import stat @@ -1235,7 +1234,13 @@ class LilypondSnippet (Snippet): def get_checksum (self): if not self.checksum: -hash = md5.md5 (self.relevant_contents (self.full_ly ())) +# Work-around for md5 module deprecation warning in python 2.5+: +try: +from hashlib import md5 +except ImportError: +from md5 import md5 + +hash = md5 (self.relevant_contents (self.full_ly ())) ## let's not create too long names. self.checksum = hash.hexdigest ()[:10] -- 1.6.0.4 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: Delete intermediate ps files
2009/7/10 Graham Percival gra...@percival-music.ca: I've just got the same error. It's caused by Graham's essay makefile hacking. Sorry, I'll branch a dev/graham and then revert it. OK, thanks. Now the docs compiled fine and I could check that the result of my patch is as intended. Any further comments or are they ready to be applied? Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: Delete intermediate ps files
2009/7/9 Graham Percival gra...@percival-music.ca: Yes, that patch is the only thing needed to fix it. However, does this patch apply cleanly, without disrupting any regtests? Hmm, I tried to run the regression tests via 'make check' (is that the right way to do it?) with the current git version first (i.e., before applying my patch) and got the following error: == make[2]: Entering directory `/home/cilix/code/lilypond/input/regression' /home/cilix/code/lilypond/scripts/build/out/extract_texi_filenames -o /home/cilix/code/lilypond/out/xref-maps out-test/collated-files.texi extract_texi_filenames.py: Processing out-test/collated-files.texi texi2html --I=/home/cilix/code/lilypond/out/xref-maps --I=. --I=./out-test --output=out-test/collated-files.html --init-file=/home/cilix/code/lilypond/lilypond-texi2html.init out-test/collated-files.texi WARNING: Unable to load the map file Undefined subroutine main:: called at /home/cilix/code/lilypond/lilypond-texi2html.init line 743. make[2]: *** [out-test/collated-files.html] Error 25 rm /home/cilix/code/lilypond/out/xref-maps/collated-files.xref-map make[2]: Leaving directory `/home/cilix/code/lilypond/input/regression' make[1]: *** [local-test] Error 2 make[1]: Leaving directory `/home/cilix/code/lilypond/input/regression' make: *** [test] Error 2 == What's going wrong? Thanks for any hints, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: Delete intermediate ps files
2009/7/9 John Mandereau john.mander...@gmail.com: 2009/7/9 Maximilian Albert maximilian.alb...@googlemail.com Hmm, I tried to run the regression tests via 'make check' (is that the right way to do it?) No, see Testing LilyPond in the Contrib Guide or in Application usage, section Install/build from source/compile (don't remember the exact name). Aha! Thanks for pointing me there. I performed the instructions given there and got three differences reported (one of which is in the file tree.gittxt and is due to the new git commit) but I don't see how any of the other two can be related to the deletion of the intermediate ps file. Do you want to take a look at the test output or is it fine to apply the patch since there was no error? I also attached a second patch for the NEWS entry. I couldn't test it, though, since 'make doc' (which I initially thought generates the documentation) produces an error and 'make web' only says make: *** No rule to make target `web'. Stop. :-( Let me know if I can do anything else. Cheers, Max From 2a0adf68f4519678f0bf5f902acb7044dbd2a43e Mon Sep 17 00:00:00 2001 From: Maximilian Albert maximilian.alb...@gmail.com Date: Wed, 8 Jul 2009 13:55:49 +0900 Subject: [PATCH] Delete intermediate ps files by default --- scm/lily.scm |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scm/lily.scm b/scm/lily.scm index 270ed42..53dd685 100644 --- a/scm/lily.scm +++ b/scm/lily.scm @@ -65,7 +65,7 @@ configurations.) Debug cyclic callback chains.) (debug-skylines #f Debug skylines.) -(delete-intermediate-files #f +(delete-intermediate-files #t Delete unusable, intermediate PostScript files.) (dump-profile #f Dump memory and time information for each file.) -- 1.6.0.4 From 88a9943dce2d23c95ff67a8fe383b2a5a7601f27 Mon Sep 17 00:00:00 2001 From: Maximilian Albert maximilian.alb...@gmail.com Date: Thu, 9 Jul 2009 18:04:11 +0900 Subject: [PATCH] Add NEWS entry about automatic deletion of intermediate files --- Documentation/topdocs/NEWS.tely |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/Documentation/topdocs/NEWS.tely b/Documentation/topdocs/NEWS.tely index 0b4bbd4..62d2021 100644 --- a/Documentation/topdocs/NEWS.tely +++ b/Documentation/topdocs/NEWS.tely @@ -62,6 +62,14 @@ which scares away people. @end ignore +...@item Intermediate .ps files which are created by Lilypond +during compilation are now deleted by default. To keep them, +add the line +...@example +#(ly:set-option 'delete-intermediate-files #f) +...@end example +to your input files. + @item Dashed and dotted slurs, phrasing slurs, and ties have been made variable thickness, and partially dashed slurs are now available: -- 1.6.0.4 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: Delete intermediate ps files
2009/7/9 Maximilian Albert maximilian.alb...@googlemail.com: I performed the instructions given there and got three differences reported (one of which is in the file Addendum: After re-running the tests with the additional NEWS entry, there are only two differences, one of which is test-output-distance.ly (which is supposed to always show up, IIUC) and the other one is due to the additional git commit as mentioned. So I guess the new patches pass the test. ;-) Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[Patch] Replace deprecated md5 module by hashlib
Hi, while running the regtests I spotted a warning about the use of the deprecated md5 module in scripts/lilypond-book.py. Attached is a patch which replaces this module by hashlib as recommended in the warning. Cheers, Max From 4985eb582afe1493872073be50486db350ed263f Mon Sep 17 00:00:00 2001 From: Maximilian Albert maximilian.alb...@gmail.com Date: Thu, 9 Jul 2009 21:13:08 +0900 Subject: [PATCH] Use hashlib instead of deprecated md5 module --- scripts/lilypond-book.py |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py index e851a40..0c3d662 100644 --- a/scripts/lilypond-book.py +++ b/scripts/lilypond-book.py @@ -29,7 +29,7 @@ TODO: ''' import glob -import md5 +import hashlib import os import re import stat @@ -1235,7 +1235,7 @@ class LilypondSnippet (Snippet): def get_checksum (self): if not self.checksum: -hash = md5.md5 (self.relevant_contents (self.full_ly ())) +hash = hashlib.md5 (self.relevant_contents (self.full_ly ())) ## let's not create too long names. self.checksum = hash.hexdigest ()[:10] -- 1.6.0.4 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] Replace deprecated md5 module by hashlib
2009/7/9 Jan Nieuwenhuizen janneke-l...@xs4all.nl: On do, 2009-07-09 at 21:41 +0900, Maximilian Albert wrote: Hi, while running the regtests I spotted a warning about the use of the deprecated md5 module in scripts/lilypond-book.py. Attached is a patch which replaces this module by hashlib as recommended in the warning. This won't work with python 2.4, or am I missing something? -- the rest of lily still builds with that... Ah, sorry. In this case please ignore my message. Sorry for the noise. Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Patch: Delete intermediate ps files
2009/7/10 John Mandereau john.mander...@gmail.com: 2009/7/9 Maximilian Albert maximilian.alb...@googlemail.com: 'make doc' (which I initially thought generates the documentation) produces an error Which error? If you can't fix it yourself, please report, including the last 100 lines of make output and other log files as appropriate. You can find them here, along with the error message (at the bottom): http://pastebin.com/m2bcb5c37 Thanks for your help, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Frescobaldi editor
Hi, has anyone tried the Frescobaldi editor for Lilypond? http://www.frescobaldi.org/ I've only had time to play with it for 5 minutes so far but it looks like an extremely easy to use and quit feature-rich editor which is specifically taylored to editing Lilypond files in a simple way. Shouldn't it be mentioned in the docs, too? Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Patch: Delete intermediate ps files
Hi, am I missing something or is the only thing that is needed to solve the first part of issue #685 (see http://code.google.com/p/lilypond/issues/detail?id=685 ) a one-line change as in the attached patch? As for the second part, are log files still created by default? This doesn't seem to be the case with the latest version 2.13.4. Cheers, Max From e7c2bc32829c1e6a9197c893497019a7b2904ded Mon Sep 17 00:00:00 2001 From: Maximilian Albert maximilian.alb...@gmail.com Date: Wed, 8 Jul 2009 13:55:49 +0900 Subject: [PATCH] Delete intermediate ps files by default --- scm/lily.scm |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scm/lily.scm b/scm/lily.scm index 270ed42..53dd685 100644 --- a/scm/lily.scm +++ b/scm/lily.scm @@ -65,7 +65,7 @@ configurations.) Debug cyclic callback chains.) (debug-skylines #f Debug skylines.) -(delete-intermediate-files #f +(delete-intermediate-files #t Delete unusable, intermediate PostScript files.) (dump-profile #f Dump memory and time information for each file.) -- 1.6.0.4 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CM 1.1 git question
2009/2/18 Jonathan Kulp jonlancek...@gmail.com: Ok I found a typo in the git instructions of CG and followed your instructions to create the patch using git. Seems to have worked great! I remember the times when I was still feeling uncomfortable with git. The thing is that when you are used to non-distributed version control systems like subversion, you are scared to do a commit because you think you might mess up a central repository. But as Carl wrote, with git the worst you can do is mess up your own repository (and normally you won't ;-)) as long as you don't do git push. So the best thing to do in order to get familiar with git is to create a dummy repository in a separate directory along with some test files and happily commit, branch, merge, etc. This way you will get a feeling for how git behaves. I always found it very useful to inspect the individual commits and branches with gitk (or qgit if you prefer). It's much easier to see what git did when you have a graphical representation. Also, two things which I learned very late but which are incredibly useful: 1) git commit --amend: instead of creating a new commit, this adds the currently staged changes to the head commit and allows you to edit the commit message. *Very* useful for updating commits if you forgot some changes or misspelled the commit message. 2) Interactive rebasing. When you specify the flag -i during git rebase then an editor opens and shows the commits which would be rebased. You can then rearrange them, squash several commits together or mark them for editing (in which case the rebasing process stops at that particular commit and allows you to do further changes before continuing). By now I use git for almost any work (even writing applications) and it has incredibly boosted my productivity because I don't need thousands of backup copies any more and I have become much more courageous to apply some changes because I know I can always undo them. Have fun exploring! Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CM 1.1 git question
2009/2/19 Jonathan Kulp jonlancek...@gmail.com: I'd like to try to get comfortable with git on a project of my own, something that doesn't have an online repo. How do I create a local git version of a directory on my machine? Just for the record (perhaps someone else is interested, too) - you simply cd to the directory in question and type git init. That's all there is to it. :-) Of course, you need to git add all the files you want to keep track of afterwards and commit them so that the initial state of the repository is saved. Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CM 1.1 git question
2009/2/19 Jonathan Kulp jonlancek...@gmail.com: Thanks Carl Maximilian for this help. I've got it going now. At the moment I don't see all the advantages of it for this project but I'm getting used to the git commands and conventions at least. As I said, I also use git to track a lot of ordinary work, even if it only consists in writing a single large text file. Normally I don't need git's functionality and it just feels like a tiny bit of extra work. But the biggest advantage is that it kind of frees the mind. You just don't need to worry about should I better formulate the passage in this or in that way?. You just do it one way and if it turns out to be bad (and if you have committed your stuff in logical chunks) then you go back to an earlier revision and start over. The really good thing is that content doesn't get lost and you can always revive it. It's a big lilypond-book project so it has tons of extra files that get created when I compile and I'm not sure if I want git tracking all those or not. No, you don't (since you don't edit them directly). Similarly, you wouldn't want to track object files in a software project - you only keep track of the source files. It seems unnecessary to track anything but the source code files. Correct. After I compile, though, and then do git status I get an enormous number of untracked files created since the last commit. You should create a file called .gitignore (note the initial dot) in the toplevel directory of the source tree which is tracked by git. In there you list all the files which you don't want to be tracked. You can use asterisks as well (as in *.txt). Then git will ignore these files and only show the status of the remaining ones. Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: which fontforge version?
2009/2/11 Jan Nieuwenhuizen janneke-l...@xs4all.nl: while working on an update of the openbsd port of lilypond, i see lots of fontforge whinings like this one: Internal Error in accidentals.flat.arrowdown: monotonic is both needed and unneeded. Indeed, these glyphs were recently added and seem to have issues. Max, what's the status on this? Frankly, I have no clue what this warning means. I noticed this, too, when working on the glyphs but it also occurred with a bunch of other glyphs which have resided within lilypond for a long time, so I thought it didn't have anything to do with my particular work. Hopefully it is really caused by the rounding errors Werner mentioned. Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Discourse on the Consumption of Dog Food
If the instructions are unclear, misleading, or just plain wrong, so much the better -- this will force us (by us I mean the main developers) to fix the CG. Just a few random nitpicks so far (I haven't read the whole thing, though): - The last word in 7.3 must read ineffective instead of inefective. - In the third item in 7.4.11 it should be E.g. instead of Eg after the first sentence. - In the fourth item in 7.4.11, is the call to message() really correct? Shouldn't 'Calculating line breaks...' also be surrounded by quotation marks? - In the second item on p. 25 in 7.4.11 two closing parentheses are missing after warning (out of tune: - Just as a thought, since you mention grep in section 7.3.2 you might just as well add a comment that -i can be helpful if you're unsure about the capitalization of function names. And a bit less nitpicky: In 7.5.4 it should be mentioned where .gdbinit files need to be placed in order to make them work. Great work everyone! I'm looking forward to when the CG will be fully fleshed out. Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide volunteers needed
2009/1/18 Graham Percival gra...@percival-music.ca: HIGH PRIORITY: - can somebody maoing check the maoing git commands in CG 1 already? Either somebody with a big internet connection, or somebody who knows git so intimiately that he can state with absolute certainty that the commands work. Done. All of them work fine (but se the comment on 1.3.1 below). Note that I only performed the commands marked with a FIXME (in sections 1.1.2 - 1.1.4) and had a look at the other ones which didn't involve a lot of sophisticated stuff (I didn't bother with GUB, for example). I didn't do any further testing, nor did I figure out what the correct commands in section 1.1.4 should be. Also, I couldn't review section 1.5 as I'm on Linux exclusively. Two comments regarding the CG in general: 1) The link on the intro page of the CG, i.e., at http://www.kainhofer.com/~lilypond/Documentation/devel/contrib-guide/index.html which points to the one big page version is broken, and so is the link to the PDF version (although both links work fine from one level higher, i.e., from http://www.kainhofer.com/~lilypond/Documentation/devel/index.html ). 2) I very much like well-structured documents. However, I find it slightly annoying to have to descend _three_ levels before getting to the first piece of text. Two levels would be acceptable IMHO, but personally I'd prefer if section 1.1 (say) could be displayed on a single page comprising subsections 1.1.1 - 1.1.7 (still including the table of contents, of course, so that they can be quickly navigated to). I find it difficult to have to go back after reading just a single short paragraph (or even sentence). And here are a few questions/comments on specific sections: 1.2.2: One precautionary question: Do unexpected things happen if the user is working on a branch other than master (and has local changes)? Should git pull origin only be performed on the master branch? I'm not familiar enough with git internals to judge this. 1.2.3: I'd add something along the lines of In files where conflicts occurred, the critical parts are marked with ... === ... . Of course, there is a lot more to say, but this might already help. 1.2.4: I know that you (Graham) said that you won't bother with that section, but anyway: Paragraph No. 5 refers to a git fetch command above which was never mentioned before. The same presumably applies to the git checkout command above in the next paragraph (which I guess doesn't refer to the commands in sections 1.1.2 - 1.1.4 where git checkout was used, too). Moreover, the last paragraph refers to this README when there is no README document there. 1.3.1: AFAICT the second command git-format-patch HEAD doesn't do anything because HEAD is the latest commit the user did, i.e., it already includes his changes. Thus there is no diff which could be produced. I suppose it should be changed to git-format-patch master instead (or whatever branch he is working on). Am I missing something? git gurus please correct me. Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide volunteers needed
2009/1/18 Graham Percival gra...@percival-music.ca: On Sun, Jan 18, 2009 at 03:47:34PM +0100, Maximilian Albert wrote: 2009/1/18 Graham Percival gra...@percival-music.ca: - can somebody maoing check the maoing git commands in CG 1 already? Either somebody with a big internet connection, or Done. All of them work fine (but se the comment on 1.3.1 below). By work fine, I also want to know that: - future pulls work with simply git pull or git pull origin (whatever is listed in that section) - creating patches works with whatever the command is (whether that's git-format-patch HEAD or MASTER or whatever) Should this take the possibility into account that people are able to create their own branches? Or would it be OK to assume they work on master (because if they know how to create branches they also know how to use these commands)? Anyway, when I reset --hard the master branch to a previous commit (so that it differs from remotes/origin/master and I don't have to wait for any of the developers to commit something to the remote branch) then both git pull and git pull origin work fine to synchronize master and remotes/origin/master again. This only applies if there are no local changes, though. In case there are, then issuing either command produces a merge commit so that the commit graph now looks like this: * master after merging |\ | \ | \ * * remotes/origin/master (on the right) \ | \| * | I'm not sure if this constellation can cause problems when producing patches. It seems that the command git-format-patch origin works fine, though (Rainer, thanks for pointing out that this should be the correct command). I personally prefer to checkout the remote branch before pulling and then doing a rebase: git-checkout remotes/origin/master git-pull git-rebase remotes/origin/master master This produces a linear history, which I personally find cleaner. :-) But I suppose that git-format-patch origin does the right thing in both situations. I don't know what you prefer to be included in the CG. - git push or git push origin or whatever works for users with commit ability. This isn't directed at you (I don't think you can test point #3), Correct. Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide volunteers needed
2009/1/18 Reinhold Kainhofer reinh...@kainhofer.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Sonntag, 18. Januar 2009 15:47:34 schrieb Maximilian Albert: 1.3.1: AFAICT the second command git-format-patch HEAD doesn't do anything because HEAD is the latest commit the user did, i.e., it already includes his changes. Thus there is no diff which could be produced. I suppose it should be changed to git-format-patch master instead (or whatever branch he is working on). This won't work either, because master==HEAD ;-) Whoops, you are of course right. I normally work on a separate branch and keep master synchronized with remotes/origin/master, that's why it usually works for me. :-) I suppose it should rather be git-format-patch origin for one patch for each local commit or git-format-patch HEAD^1 for just the last local commit. Correct. Or else git-format-patch -n for the last n local commits (i.e., git-format-patch -1 for only the last local commit). Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contributor Guide volunteers needed
2009/1/18 Graham Percival gra...@percival-music.ca: I've had problems with just git pull... This only applies if there are no local changes, though. ... ah, for precisely for this reason. :) In case there are, then issuing either command produces a merge commit so that the commit graph now looks like this: * master after merging |\ | \ | \ * * remotes/origin/master (on the right) \ | \| * | I'm not sure if this constellation can cause problems when producing patches. It seems that the command git-format-patch origin works fine, though (Rainer, thanks for pointing out that this should be the correct command). See, I've been using git for a few years now, and I only barely understand what you're talking about. (not because I'm an idiot; just because I've never been willing to put any time or effort towards learning any git theory. If I can use it like cvs -- checkout, add, commit, update -- then I'm happy) Honestly, I feel like anything else than a git expert. Anyway, probably my ASCII-arts above are not very clear. Perhaps this better illustrates what I mean. 1) Start with a repository where master and remotes/origin/master are identical (if they are not, you can say git-checkout -b test remotes/origin/master to create a branch called 'test'; in this case, replace 'master' with 'test' everywhere in the following steps). 2) git-reset --hard HEAD^ This discards the most recent commit on master so that master and remotes/origin/master now differ by precisely one commit. 3) Do a simple change in one of the files (e.g., add a line or something - doesn't really matter). 4) git-commit -a -m Test commit on master 5) git pull (or git pull origin, I suppose they work identically) -- this creates the merge commit 6) Fire up gitk and look at the commit graph; it should look similar to what I tried to mimic in my ASCII arts. On the other hand, if you do the following instead: 1) - 4) as above 5) git-checkout remotes/origin/master 6) git pull 7) git-rebase remotes/origin/master master then you will see in gitk that master now sits nicely on top of remotes/origin/master. That's what I meant when I said linear history. But as mentioned, I don't suppose there is any difference between the two methods as far as git-format-patch is concerned. However, I don't know whether git-format-patch gets confused when the user makes several commits with several pulls in between as in the first method above. Hmm, I just saw that that the second method gives a warning in step 5) saying that remotes/origin/master is not a local branch (well, obviously) and explaining how to create one if desired. I don't know if this will confuse newcomers. git-checkout remotes/origin/master git-pull git-rebase remotes/origin/master master This produces a linear history, which I personally find cleaner. :-) But I suppose that git-format-patch origin does the right thing in both situations. I don't know what you prefer to be included in the CG. Mao. I'm totally lost now. See above. I hope it made things a bit clearer. Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.12.1 panic list
2008/12/28 Graham Percival gra...@percival-music.ca: I'm planning a 2.12.1 release soon; we're unofficially thinking of this as the real 2.12 stable release. Compared to current master, what are the remaining last-minute changes that people want, and when do you think you'll have them committed? AFAICT, there is not yet any documentation on the new arrowed accidentals. I sent a couple of patches a while ago but it still needs to be approved, mostly because it also adds new names for notes with arrowed accientals. See http://lists.gnu.org/archive/html/lilypond-devel/2008-12/msg00485.html Also, I think the NEWS entry hasn't been applied yet. When I tried to dig up the corresponding email, I realized that I had sent it to Werner alone, so I'm attaching the patch again for inspection. Thanks, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.12.1 panic list
2008/12/30 Maximilian Albert maximilian.alb...@googlemail.com:
Also, I think the NEWS entry hasn't been applied yet. When I tried to
dig up the corresponding email, I realized that I had sent it to
Werner alone, so I'm attaching the patch again for inspection.
Sorry, forgot to attach the file (thanks, Francisco!).
Max
From 712409b11475c0c041ca0169c100f69ce06302a5 Mon Sep 17 00:00:00 2001
From: Maximilian Albert ci...@daphne.(none)
Date: Wed, 17 Dec 2008 22:00:20 +0100
Subject: [PATCH] Add entry for arrowed accidentals in NEWS.tely.
---
Documentation/topdocs/NEWS.tely | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/topdocs/NEWS.tely b/Documentation/topdocs/NEWS.tely
index f18656a..d2fefae 100644
--- a/Documentation/topdocs/NEWS.tely
+++ b/Documentation/topdocs/NEWS.tely
@@ -520,6 +520,35 @@ prevent uneven vertical spacing.
}
@end lilypond
+...@item
+Extending LilyPond's existing support for microtones, there are
+now arrowed accidentals for the notation of microtonal alterations.
+To use them, redefine the @code{glyph-name-alist} property of
+...@code{accidental} as in the following example which uses quartertones
+to typeset arrowed accidentals. Alternatively, it is possible to
+define separate names for all notes with arrowed accidentals (see
+...@code{ly/makam.ly} for boilerplate code).
+
+...@lilypond[]
+microAccs = #'((0 . accidentals.natural)
+ (-1/2 . accidentals.flat)
+ (1/2 . accidentals.sharp)
+
+ (1 . accidentals.doublesharp)
+ (-1 . accidentals.flatflat)
+
+ (3/4 . accidentals.sharp.arrowup)
+ (1/4 . accidentals.sharp.arrowdown)
+ (-1/4 . accidentals.flat.arrowup)
+ (-3/4 . accidentals.flat.arrowdown))
+
+\relative c'' {
+ #(set-accidental-style 'modern)
+ \override Accidental #'glyph-name-alist = #microAccs
+ geseh geh aih aisih
+}
+...@end lilypond
+
@end itemize
--
1.5.4.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bug with skipTypesetting and lyrics
Hi, sorry for the delay in replying - the time since Christmas was filled with work and music. :-) My question is: could tieMelismaBusy be set somewhere else so that this also happens when music is not processed for typesetting? Or is there another way to make skipTypesetting work properly with lyrics? Any hints are appreciated. You could try setting it in process_music(), but you should run the test suite to make sure you are not changing other behaviors. As I wrote, I think it is already set in process_music(). A second place where tieMelismaBusy is set is in start_translation_timestep(), although I'm not sure which of both location is relevant for this bug. In any case, from my limited understanding of the code it seems that any function which sets tieMelismaBusy is digged rather deeply into the calling chain so that there is no easy way to bypass higher-level functions while still getting tieMelismaBusy set properly. On the other hand, lyrics recognize individual notes even with skipTypesetting = ##t (although I don't really understand how this works), so I imagine there should be a way to recognize ties as well. Any hints where to start? Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Flags for 128th notes
Hi, after working on the arrowed accidentals I thought I'd give the missing flags for 128th notes a try, which I believe were requested a while ago (see issue 508). As always, comments are welcome. Regards, Max From c5bff1e8dbf1313661d647756b5f6c58f731c0db Mon Sep 17 00:00:00 2001 From: Maximilian Albert maximilian.alb...@gmail.com Date: Sun, 21 Dec 2008 00:20:24 +0100 Subject: [PATCH] Add 128th flags --- mf/feta-banier.mf| 79 ++ scm/define-grobs.scm |4 +- 2 files changed, 81 insertions(+), 2 deletions(-) diff --git a/mf/feta-banier.mf b/mf/feta-banier.mf index 729dd1d..f593c6f 100644 --- a/mf/feta-banier.mf +++ b/mf/feta-banier.mf @@ -247,6 +247,45 @@ fet_beginchar (64th Flag (up), u6); fet_endchar; +fet_beginchar (128th Flag (up), u7); + save flare, hip_depth_ratio, hip_width, foot_depth, foot_width_ratio; + save flagspace, total_depth, flag_count; + + flag_count = 5; + flare = .85 staff_space; + flagspace# = .93 staff_space#; + hip_depth_ratio = .72; + hip_width# = upflag_width# - hip_thickness# / 2; + total_depth# = 6.25 staff_space#; + foot_width_ratio = .8; + + (flag_count - 1) * flagspace# + foot_depth# = total_depth#; + + define_pixels (hip_width, foot_depth); + define_whole_vertical_pixels (flagspace); + + set_char_box (0, hip_width# + right_upflag_space#, + total_depth# + foot_thickness# / 2, stemthickness# / 2); + + draw_flag ((0, -(flag_count - 1) * flagspace), flare, + (hip_width, foot_depth), + hip_depth_ratio, foot_width_ratio, + hip_thickness, foot_thickness, 1); + + add_flag (flagspace, flare, .97, 1.00, 1.3, + hip_thickness, foot_thickness); + add_flag (flagspace, flare, 1.00, 1.00, 1.25, + hip_thickness, foot_thickness); + add_flag (flagspace, flare, 1.00, 1.00, 1.25, + hip_thickness, foot_thickness); + add_flag (flagspace, flare, 0.95, 1.05, 1.25, + hip_thickness, foot_thickness); + + draw_square_block ((-0.5 stemthickness_rounded, 0), + (0, -5 staff_space_rounded)); +fet_endchar; + + fet_beginchar (8th (down), d3); save flare, hip_depth_ratio, hip_width, foot_depth, foot_width_ratio; save flagspace, total_depth, flag_count; @@ -468,4 +507,44 @@ fet_beginchar (64th (down), d6); y_mirror_char; fet_endchar; + +fet_beginchar (128th (down), d7); + save flare, hip_depth_ratio, hip_width, foot_depth, foot_width_ratio; + save flagspace, total_depth, flag_count; + + flag_count = 5; + flare = .8 staff_space; + flagspace# = .9 staff_space#; + hip_depth_ratio = .85; + hip_width# = downflag_width# - hip_thickness# / 2; + total_depth# = 5.25 staff_space#; + foot_width_ratio = .98; + + (flag_count - 1) * flagspace# + foot_depth# = total_depth#; + define_pixels (hip_width, foot_depth); + define_whole_vertical_pixels (flagspace); + + set_char_box (0, hip_width# + right_downflag_space#, + total_depth# + foot_thickness# / 2, stemthickness# / 2); + + draw_flag ((0, -(flag_count - 1) * flagspace), flare, + (hip_width, foot_depth), + hip_depth_ratio, foot_width_ratio, + hip_thickness, foot_thickness, 0); + + add_flag (flagspace, flare, .97, 1.20, 1.175, + hip_thickness, foot_thickness); + add_flag (flagspace, flare, .97, 1.10, 1.175, + hip_thickness, foot_thickness); + add_flag (.98 flagspace, flare, .91, 1.05, 1.2, + hip_thickness, foot_thickness); + add_flag (.98 flagspace, flare, .91, 1.05, 1.2, + hip_thickness, foot_thickness); + + draw_square_block ((-0.5 stemthickness_rounded, 0), + (0, -5 staff_space_rounded)); + + y_mirror_char; +fet_endchar; + fet_endgroup (flags); diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm index 4009f6e..c7059d0 100644 --- a/scm/define-grobs.scm +++ b/scm/define-grobs.scm @@ -1641,8 +1641,8 @@ (details . ( ;; 3.5 (or 3 measured from note head) is standard length - ;; 32nd, 64th flagged stems should be longer - (lengths . (3.5 3.5 3.5 4.5 5.0)) + ;; 32nd, 64th, 128th flagged stems should be longer + (lengths . (3.5 3.5 3.5 4.5 5.0 6.0)) ;; FIXME. 3.5 yields too long beams (according to Ross and ;; looking at Baerenreiter examples) for a number of common -- 1.5.4.3 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Bug with skipTypesetting and lyrics
Hi, it seems that lyrics are confused by ties when skipTypesetting is switched on. Consider the attached example - it works perfectly as is, but when the first line is changed to skipTypesetting = ##t, all remaining lyrics are shifted one note to the left, presumably because the tie on the second note is not taken into consideration (when inserting more ties, the lyrics are shifted even further). I tried to look a bit into the issue, and the problem seems to be that lyrics only skip noteheads when tieMelismaBusy is set to ##t, but setting this property happens in Tie_engraver::process_music which is not called when skipTypesetting = ##t. As far as I can see from my quick tests and inspections, the root call which is disabled by skipTypesetting is the line precomputed_recurse_over_translators (context (), PROCESS_MUSIC, UP); in Score_engraver::one_time_step. This recursively calls precomputed_recurse_over_translators for the Staff and Voice contexts, and only when all this happens is the call to Tie_engraver::process_music performed. My question is: could tieMelismaBusy be set somewhere else so that this also happens when music is not processed for typesetting? Or is there another way to make skipTypesetting work properly with lyrics? Any hints are appreciated. Thanks, Max skipTypesetting_lyrics_bug.ly Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Convert-ly rules
Hi, I just ran convert-ly over an old score (typeset with v2.8.6) which contained the following line: \override TextSpanner #'edge-text = #(cons (markup #:bigger #:bigger #:bigger #:upright rit. ) ) Now the \bigger command was removed recently (replaced by \larger). A corresponding convert-ly rule does exist, but it explicitly checks for the backslash in front of the command. So the above line was left unchanged, which made lilypond choke. Should convert-ly rules be formulated so that Scheme-version of commands like the above are also taken into account? Which other commands does this affect? Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Convert-ly rules
2008/12/22 Maximilian Albert maximilian.alb...@googlemail.com: Should convert-ly rules be formulated so that Scheme-version of commands like the above are also taken into account? Never mind, I just saw that the rule for \center-align already has this. So here is a patch for \bigger. In fact, the former reads str = re.sub (r([\\:]+)center-align, r\1center-column, str) so it allows multiple backslashes/colons. Is this necessary? Max From 5db6bd105fff85341737dde7ee7c98e302c6a01c Mon Sep 17 00:00:00 2001 From: Maximilian Albert maximilian.alb...@gmail.com Date: Mon, 22 Dec 2008 17:00:26 +0100 Subject: [PATCH] Make convert-ly rule for \bigger - \larger also recognize :bigger --- python/convertrules.py |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/python/convertrules.py b/python/convertrules.py index f86165c..38f84a5 100644 --- a/python/convertrules.py +++ b/python/convertrules.py @@ -2820,7 +2820,7 @@ def conv (str): @rule ((2, 11, 62), makam-init.ly - makam.ly, \\bigger - \\larger) def conv (str): str = re.sub (r'\\include(\s+)makam-init.ly', r'\\include\1makam.ly', str) -str = re.sub (r\\bigger, r\\larger, str) +str = re.sub (r([\\:])bigger, r\1larger, str) return str @rule ((2, 11, 64), systemSeparatorMarkup - system-separator-markup,\n\ -- 1.5.4.3 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: [PATCH] Flags for 128th notes
2008/12/22 Graham Percival gra...@percival-music.ca: The actual error is probably about 50-200 lines above the end of the build. I'm guessing a font error here, with admittedly very little evidence to go by. (hence the guessing :) Try make web log.txt Aha! Indeed the error occurred much earlier. It said that the file epsf.tex was missing. After installing the Ubuntu package texlive-generic-recommended, it works fine. Thanks for your help! Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Arrowed accidentals for microtone notation
Hi again, here is some documentation for the arrowed accidentals. Since I found it the most natural way of typesetting, it uses Trevor's notation for up and down arrows (but also mentions the alternative ways discussed before). Please let me know if for some reason Trevor's default names are not desired so that I can rewrite the docs accordingly. Note that the attached patches supersede the one in my last email. Cheers and merry christmas to everyone! Max From a54922b8d12e3c30b2f0053068f68b14e5efa940 Mon Sep 17 00:00:00 2001 From: Maximilian Albert maximilian.alb...@gmail.com Date: Sat, 20 Dec 2008 19:34:11 +0100 Subject: [PATCH] New alterations for microtones and default names for notes with arrowed accidentals in english.ly --- ly/english.ly| 59 ++ scm/lily-library.scm |5 scm/output-lib.scm |5 3 files changed, 69 insertions(+), 0 deletions(-) diff --git a/ly/english.ly b/ly/english.ly index 4f7983c..bb185fb 100644 --- a/ly/english.ly +++ b/ly/english.ly @@ -125,6 +125,65 @@ pitchnamesEnglish = #`( (btqs . ,(ly:make-pitch -1 6 THREE-Q-SHARP)) (bss . ,(ly:make-pitch -1 6 DOUBLE-SHARP)) (bx . ,(ly:make-pitch -1 6 DOUBLE-SHARP)) + + ;; arrowed accidentals + (cflatdown . ,(ly:make-pitch -1 0 FLAT-MICRO-DOWN)) + (cflatup . ,(ly:make-pitch -1 0 FLAT-MICRO-UP)) + (csharpdown . ,(ly:make-pitch -1 0 SHARP-MICRO-DOWN)) + (csharpup . ,(ly:make-pitch -1 0 SHARP-MICRO-UP)) + (dflatdown . ,(ly:make-pitch -1 1 FLAT-MICRO-DOWN)) + (dflatup . ,(ly:make-pitch -1 1 FLAT-MICRO-UP)) + (dsharpdown . ,(ly:make-pitch -1 1 SHARP-MICRO-DOWN)) + (dsharpup . ,(ly:make-pitch -1 1 SHARP-MICRO-UP)) + (eflatdown . ,(ly:make-pitch -1 2 FLAT-MICRO-DOWN)) + (eflatup . ,(ly:make-pitch -1 2 FLAT-MICRO-UP)) + (esharpdown . ,(ly:make-pitch -1 2 SHARP-MICRO-DOWN)) + (esharpup . ,(ly:make-pitch -1 2 SHARP-MICRO-UP)) + (fflatdown . ,(ly:make-pitch -1 3 FLAT-MICRO-DOWN)) + (fflatup . ,(ly:make-pitch -1 3 FLAT-MICRO-UP)) + (fsharpdown . ,(ly:make-pitch -1 3 SHARP-MICRO-DOWN)) + (fsharpup . ,(ly:make-pitch -1 3 SHARP-MICRO-UP)) + (gflatdown . ,(ly:make-pitch -1 4 FLAT-MICRO-DOWN)) + (gflatup . ,(ly:make-pitch -1 4 FLAT-MICRO-UP)) + (gsharpdown . ,(ly:make-pitch -1 4 SHARP-MICRO-DOWN)) + (gsharpup . ,(ly:make-pitch -1 4 SHARP-MICRO-UP)) + (aflatdown . ,(ly:make-pitch -1 5 FLAT-MICRO-DOWN)) + (aflatup . ,(ly:make-pitch -1 5 FLAT-MICRO-UP)) + (asharpdown . ,(ly:make-pitch -1 5 SHARP-MICRO-DOWN)) + (asharpup . ,(ly:make-pitch -1 5 SHARP-MICRO-UP)) + (bflatdown . ,(ly:make-pitch -1 6 FLAT-MICRO-DOWN)) + (bflatup . ,(ly:make-pitch -1 6 FLAT-MICRO-UP)) + (bsharpdown . ,(ly:make-pitch -1 6 SHARP-MICRO-DOWN)) + (bsharpup . ,(ly:make-pitch -1 6 SHARP-MICRO-UP)) + + (csu . ,(ly:make-pitch -1 0 SHARP-MICRO-UP)) + (csd . ,(ly:make-pitch -1 0 SHARP-MICRO-DOWN)) + (cfu . ,(ly:make-pitch -1 0 FLAT-MICRO-UP)) + (cfd . ,(ly:make-pitch -1 0 FLAT-MICRO-DOWN)) + (dsu . ,(ly:make-pitch -1 1 SHARP-MICRO-UP)) + (dsd . ,(ly:make-pitch -1 1 SHARP-MICRO-DOWN)) + (dfu . ,(ly:make-pitch -1 1 FLAT-MICRO-UP)) + (dfd . ,(ly:make-pitch -1 1 FLAT-MICRO-DOWN)) + (esu . ,(ly:make-pitch -1 2 SHARP-MICRO-UP)) + (esd . ,(ly:make-pitch -1 2 SHARP-MICRO-DOWN)) + (efu . ,(ly:make-pitch -1 2 FLAT-MICRO-UP)) + (efd . ,(ly:make-pitch -1 2 FLAT-MICRO-DOWN)) + (fsu . ,(ly:make-pitch -1 3 SHARP-MICRO-UP)) + (fsd . ,(ly:make-pitch -1 3 SHARP-MICRO-DOWN)) + (ffu . ,(ly:make-pitch -1 3 FLAT-MICRO-UP)) + (ffd . ,(ly:make-pitch -1 3 FLAT-MICRO-DOWN)) + (gsu . ,(ly:make-pitch -1 4 SHARP-MICRO-UP)) + (gsd . ,(ly:make-pitch -1 4 SHARP-MICRO-DOWN)) + (gfu . ,(ly:make-pitch -1 4 FLAT-MICRO-UP)) + (gfd . ,(ly:make-pitch -1 4 FLAT-MICRO-DOWN)) + (asu . ,(ly:make-pitch -1 5 SHARP-MICRO-UP)) + (asd . ,(ly:make-pitch -1 5 SHARP-MICRO-DOWN)) + (afu . ,(ly:make-pitch -1 5 FLAT-MICRO-UP)) + (afd . ,(ly:make-pitch -1 5 FLAT-MICRO-DOWN)) + (bsu . ,(ly:make-pitch -1 6 SHARP-MICRO-UP)) + (bsd . ,(ly:make-pitch -1 6 SHARP-MICRO-DOWN)) + (bfu . ,(ly:make-pitch -1 6 FLAT-MICRO-UP)) + (bfd . ,(ly:make-pitch -1 6 FLAT-MICRO-DOWN)) ) pitchnames = \pitchnamesEnglish diff --git a/scm/lily-library.scm b/scm/lily-library.scm index 8176db1..7ebf478 100644 --- a/scm/lily-library.scm +++ b/scm/lily-library.scm @@ -41,6 +41,11 @@ (define-safe-public DOUBLE-SHARP 1) (define-safe-public SEMI-TONE 1/2) +(define-safe-public SHARP-MICRO-DOWN 499/1000) +(define-safe-public SHARP-MICRO-UP 501/1000) +(define-safe-public FLAT-MICRO-UP -499/1000) +(define-safe-public FLAT-MICRO-DOWN -501/1000) + ;; moments diff --git a/scm/output-lib.scm b/scm/output-lib.scm index 6a54777..a91453a 100644 --- a/scm/output-lib.scm +++ b/scm/output-lib.scm @@ -391,6 +391,11 @@ centered, X==1 is at the right, X == -1 is at the left. (1/4 . accidentals.sharp.slashslash.stem) (-1/4 . accidentals.mirroredflat) (-3/4 . accidentals.mirroredflat.flat) + + (499/1000
Re: PATCH: Arrowed accidentals for microtone notation
Hi Trevor, thanks for the suggestion. Here is a patch to implement this (it simply defines new alterations of +/- 499/1000 and +/- 501/1000, which I assume are unlikely to be used for anything else). I don't know if the patch is likely to get officially accepted, but at least it should give you or others who build from git a way to easily use the accidentals in the way you described. If it makes it into the official repository, I can of course update the example in NEWS.tely to reflect the new syntax. If anyone wants to provide similar names for other languages, they just need to imitate the changes in english.ly. Cheers, Max P.S.: Is there something wrong with the git repository? Each time I want to pull I get the following error message: git.sv.gnu.org[0: 199.232.41.69]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) 0001-New-alterations-for-microtones-and-default-names-for.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Arrowed accidentals for microtone notation
2008/12/14 Werner LEMBERG w...@gnu.org: Can we please make sure to include at least one example of input syntax in the newsfile? Well, it's Maximilian's turn... Yup, sorry. During the last couple of days I didn't have access to the computer I presently work on (and won't have for another few days), whence the delay in my response. Werner, thanks a lot for applying and cleaning up the patches! I should have taken care of using the right the coding style in the first place. As for the input syntax, that's a good point anyway. So far I only used the arrowed accidentals by tweaking the maqam example and defining separate names for all combinations of notes with all kinds of arrowed accidentals (see the attached file micro1.ly). The drawback is that the microtonal notes are associated with a certain pitch and that one has to add a huge list of note name definitions at the beginning of the file. One could also redefine the +/- 1/4 and +/- 3/4 alterations to use the arrowed accidentals, as in the attached file micro2.ly. The drawback ist that one cannot use the regular quartertone accidentals any more since they are overridden by the new definition (and microtones are still attached to a specific pitch). Do you think we should provide standard names for all the notes with microtonal alterations? These would have to be localized, right? (which I don't know how to do properly since I'm not familiar with the naming conventions in other languages.) Or should we require the user to make his own definitions each time (s)he wants to use these accidentals? Which of these methods should be included in the news file as an example for the recommended syntax? Max micro1.ly Description: Binary data micro2.ly Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix for bug #218 (center staccato over stem instead of notehead)
2008/12/13 Han-Wen Nienhuys hanw...@gmail.com:
No need to test 3 values, 0.0 and != 0.0 should be enough. Be sure to
test both stem up and stem down.
Use only 1 note for each situation (or, if you need to test beams, 2).
Alright, the adapted patch #2 is attached. Obviously I put too much
focus on making a regression test more visually appealing than minimal
and functional...
Max
From 0c6dbec079e43eeceaa695b0b30b2c6dab14b01a Mon Sep 17 00:00:00 2001
From: Maximilian Albert ci...@dike.(none)
Date: Sat, 13 Dec 2008 00:42:22 +0100
Subject: [PATCH] Add regression test for 'toward-stem-shift property
---
input/regression/script-shift.ly | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 input/regression/script-shift.ly
diff --git a/input/regression/script-shift.ly b/input/regression/script-shift.ly
new file mode 100644
index 000..c617703
--- /dev/null
+++ b/input/regression/script-shift.ly
@@ -0,0 +1,22 @@
+
+\header {
+
+ texidoc = The @code{toward-stem-shift} property controls the precise
+horizontal location of scripts that are placed above an upstem or below
+a downstem note (@code{0.0} means centered on the note head, @code{1.0}
+means centered on the stem).
+
+
+\version 2.11.65
+\layout {
+ indent = 0\mm
+ ragged-right = ##t
+}
+\relative c''
+{
+ \override Script #'toward-stem-shift = #0.0
+ a4^. c_.
+
+ \override Script #'toward-stem-shift = #1.0
+ a4^. c_.
+}
--
1.5.4.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix for bug #218 (center staccato over stem instead of notehead)
2008/12/17 Neil Puttock n.putt...@gmail.com:
2008/12/16 Maximilian Albert maximilian.alb...@googlemail.com:
Alright, the adapted patch #2 is attached. Obviously I put too much
focus on making a regression test more visually appealing than minimal
and functional...
Looks OK, but your \header block isn't closed.
Whoops, corrected in the attached patch (where the layout block is
removed, too).
Thanks,
Max
From e1dee2e16f02e575caee8cadfa4608f7473fbfaf Mon Sep 17 00:00:00 2001
From: Maximilian Albert ci...@dike.(none)
Date: Sat, 13 Dec 2008 00:42:22 +0100
Subject: [PATCH] Add regression test for 'toward-stem-shift property
---
input/regression/script-shift.ly | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
create mode 100644 input/regression/script-shift.ly
diff --git a/input/regression/script-shift.ly b/input/regression/script-shift.ly
new file mode 100644
index 000..bbe6b02
--- /dev/null
+++ b/input/regression/script-shift.ly
@@ -0,0 +1,18 @@
+
+\header {
+ texidoc = The @code{toward-stem-shift} property controls the precise
+horizontal location of scripts that are placed above an upstem or below
+a downstem note (@code{0.0} means centered on the note head, @code{1.0}
+means centered on the stem).
+
+}
+
+\version 2.11.65
+\relative c''
+{
+ \override Script #'toward-stem-shift = #0.0
+ a4^. c_.
+
+ \override Script #'toward-stem-shift = #1.0
+ a4^. c_.
+}
--
1.5.4.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Arrowed accidentals for microtone notation
Hi Werner, Hehe, still not perfect. Sorry for being such a PITA :-) If you weren't, I'd ask you to be. ;-) Lilypond wouldn't be what it is if it weren't for people like Han-Wen, you and the other developers who aim for the highest possible quality standards. Vice versa I apologize for giving you so much opportunity to discover bugs and buglets. ;-) The `natural.arrowdown' glyph correctly extends the vertical bar outlines into exactly the same direction, while the `natural.arrowboth' extends the stem into a slightly different direction, which is not correct. I noticed this, too, but I thought it was due to rounding errors caused by metafont since I passed exactly the same direction as an argument for both glyphs. I now made a correction which I hope fixes this issue but please double check to be sure. Additionally, the upper left point of the lower horizontal bar `jumps' if compared between natural glyphs with and without an up-arrow. The same is true for the lower right point of the upper horizontal bar for glyphs with and without a down-arrow. This is fixed in the attached revised version of the patches. Please let further suggestions be coming. :-) Thanks and best regards, Max patch_arrowed_accidentals.tar.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix for bug #218 (center staccato over stem instead of notehead)
2008/12/10 Han-Wen Nienhuys hanw...@gmail.com:
Some random comments:
Thanks for these suggestions! They are implemented in the attached
patches. Please let me know if you'd like some further corrections.
- have a look at scm/script.scm to set defaults just for staccato.
Following Neil's suggestions, I set the default for staccato to 0.5
and left all other scripts alone.
- shifted suggests a boolean property. toward-stem-shift ?
Renamed.
- do not use 'pos' - it's the name for vertical offsets in half staffspace.
OK. Lacking a better idea, I chose note-head-location and
stem-location instead. I hope it's not too clumsy.
- use explicit type checks (ie. number? rather than (not null?))
The number check was eliminated by Neil's suggestion to use a default value.
I now use ly:grob? to check whether a stem grob exists.
-(if (equal? dir1 dir2) can move to before the stem-pos init
Done.
- add a regtest. Should be short, with a short doc string explaining
the functionality.
Done (patch #2). I hope it meets the requirements for a regtest.
Please let me know if anything is missing or wrong.
Max
From 3cb4d8d3c53d318c6a388bd325382975c077f8af Mon Sep 17 00:00:00 2001
From: Maximilian Albert ci...@dike.(none)
Date: Sat, 13 Dec 2008 00:52:27 +0100
Subject: [PATCH] New grob-property 'shifted-towards-stem (allows scripts to be placed anywhere between the note head and the stem)
---
lily/script-interface.cc |1 +
scm/define-grob-properties.scm |4
scm/output-lib.scm | 19 ++-
scm/script.scm |1 +
4 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/lily/script-interface.cc b/lily/script-interface.cc
index a525500..af2b8f9 100644
--- a/lily/script-interface.cc
+++ b/lily/script-interface.cc
@@ -129,6 +129,7 @@ ADD_INTERFACE (Script_interface,
positioning-done
script-priority
script-stencil
+ toward-stem-shift
slur
slur-padding
);
diff --git a/scm/define-grob-properties.scm b/scm/define-grob-properties.scm
index b697af3..d9e5691 100644
--- a/scm/define-grob-properties.scm
+++ b/scm/define-grob-properties.scm
@@ -551,6 +551,10 @@ value @code{-1} means left aligned, @code...@tie{}centered, and
values may also be specified.)
(self-alignment-Y ,number? Like @code{self-alignment-X} but for
the y...@tie{}axis.)
+ (toward-stem-shift ,number? Amount by which scripts are shifted
+toward the stem if their direction coincides with the stem direction.
+...@code{0.0} means keep the default position (centered on the note head),
+...@code{1.0} means centered on the stem. Interpolated values are possible.)
(shorten-pair ,number-pair? The lengths to shorten a
text-spanner on both sides, for example a pedal bracket. Positive
values shorten the text-spanner, while negative values lengthen it.)
diff --git a/scm/output-lib.scm b/scm/output-lib.scm
index b93edda..1b231d4 100644
--- a/scm/output-lib.scm
+++ b/scm/output-lib.scm
@@ -669,4 +669,21 @@ centered, X==1 is at the right, X == -1 is at the left.
(define-public (script-interface::calc-x-offset grob)
(ly:grob-property grob 'positioning-done)
- (ly:self-alignment-interface::centered-on-x-parent grob))
+ (let* ((shift (ly:grob-property grob 'toward-stem-shift 0.0))
+ (note-head-location (ly:self-alignment-interface::centered-on-x-parent grob))
+ (note-head-grob (ly:grob-parent grob X))
+ (stem-grob (ly:grob-object note-head-grob 'stem)))
+(+ note-head-location
+ ;; If the property 'toward-stem-shift is defined and the script has the
+ ;; same direction as the stem, move the script accordingly. Since scripts can
+ ;; also be over skips, we need to check whether the grob has a stem at all.
+ (if (ly:grob? stem-grob)
+ (let ((dir1 (ly:grob-property grob 'direction))
+ (dir2 (ly:grob-property stem-grob 'direction)))
+ (if (equal? dir1 dir2)
+ (let* ((common-refp (ly:grob-common-refpoint grob stem-grob X))
+ (stem-location (ly:grob-relative-coordinate stem-grob common-refp X)))
+ (* shift (- stem-location
+ note-head-location)))
+ 0.0))
+ 0.0
diff --git a/scm/script.scm b/scm/script.scm
index eb2fad5..5e2a2a9 100644
--- a/scm/script.scm
+++ b/scm/script.scm
@@ -111,6 +111,7 @@
(side-relative-direction . -1)
(quantize-position . #t)
(avoid-slur . inside)
+ (toward-stem-shift . 0.5)
(padding . 0.20)
(script-priority . -100)))
(tenuto .
--
1.5.4.3
From d310eaa9789aafb5e6f09d2e6baa20adba0bf72c Mon Sep 17 00:00:00 2001
From: Maximilian Albert ci...@dike.(none)
Date: Sat, 13 Dec 2008 00:42:22 +0100
Subject: [PATCH] Add regression test for 'toward-stem-shift property
---
input/regression/script-shift.ly | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
create mode 100644 input/regression/script-shift.ly
diff --git a/input/regression/script-shift.ly
Re: major feature request (tablature)
2008/12/10 Werner LEMBERG [EMAIL PROTECTED]: Since you put 'scheme' in single quotes, I suspect you don't know about Scheme programming. Scheme is a Lisp-like programming language. ()()((()))()()((( I hope not, that kinda stuff leaves me with a headache, thank the gods for programming editors with () balancing. Much more important is proper indenting. Very true. Also, Scheme code is _not_ read by looking at the parentheses. Instead, you read it by looking at the indention (which tells you at which 'level' of the code you are). You'll realize that pretty soon you entirely forget about the parentheses. Scheme's parentheses are rather easy to handle if you write code like this during development: (foo (bla ... bla ) ) and fold it later to (foo (bla ... bla)) In fact, I personally find it just as easy to write/read the latter form directly, again because it is the _indentation_ which tells me how a particular piece of code is related to the rest. BTW, you can quickly become addicted to the way you start thinking when programming in Scheme. It's offers you a wholly new paradigm which breaks down a couple of walls you have built yourself up by programming in other languages. I highly recommend giving it a try (especially if you're an experienced programmer). There are excellent tutorials and books out there (although unfortunately I don't have any web addresses at hand). Coming from the Lisp side, I can highly recommend Paul Graham's books ANSI Common Lisp and On Lisp which IMHO are fluent to read and didactically excellent. But as I said, there are plentiful other resources. Also, keep in mind that Scheme is only a Lisp dialect which means that a couple of things behave differently, so in your case it's probably good to dive into Scheme directly. Good luck and especially: have fun! Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Arrowed accidentals for microtone notation
2008/12/9 Werner LEMBERG [EMAIL PROTECTED]: [...] I managed to find a workaround and hope that the attached patches finally fix all the issues. Still a buglet: The stemwidth of the down arrow in the `natural.arrowboth' glyph is too thick if compared to the other arrowed natural signs. Everything else looks fine. Finally one with an instantaneous fix. :-) Indeed I used to check for up- XOR down-arrow before I added the accidentals with arrows in both direction. The attached version of the patches corrects this. BTW, your hint about quick font creation and especially using Ctrl+brackets to switch between consecutive glyphs in fontforge was priceless. Thanks for that and for continuing support and detailed investigations! Max patch_arrowed_accidentals.tar.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix for bug #218 (center staccato over stem instead of notehead)
2008/12/8 Neil Puttock [EMAIL PROTECTED]: This seems to work fine. :) I've run regtests with and without a default for staccati, and both compile without any problems (see the attached image for the expected change in staccato-pos.ly when 'shifted-towards-stem is set to 0.5 in script.scm). Awesome to hear and thanks for testing! What do you guys think, should a default value be set, and if so which one? I guess something between 0.5 and 0.75 would be sensible, according to Reinholds findings. Since LilyPond uses American English for docs/properties, shifted-toward-stem is probably better. + (let* ((shift (ly:grob-property grob 'shifted-towards-stem)) If you set a default value here, then you won't have to check whether it's null later: Thanks for these suggestions, I will include them in the next patch. [...] what would I need to write instead of \override Script #'shifted-towards-stem = #'1.0 if I wanted to enable shifting only for staccato marks, say? Something like this should do it: #(define ((shift-articulation type amount) grob) (let ((artic (ly:event-property (ly:grob-property grob 'cause) 'articulation-type))) (if (equal? type artic) amount 0))) \override Script #'shifted-towards-stem = #(shift-articulation staccato 1) Great! With what you had written in your last email, something along these lines should have crossed my mind... Could it be worthwhile to wire this function into lilypond itself, since I suppose that most people would want to change the property only for specific scripts? Or is it sufficient to put it into the docs somewhere (perhaps in the corresponding LSR snippet itself)? Best regards, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix for bug #218 (center staccato over stem instead of notehead)
Hi Neil,
thanks a lot for your further very helpful ideas. Attached is a patch
for a new approach which implements your suggestion to define a new
property. It's called 'shifted-towards-stem and can take any real
value, where 0.0 means to keep the default position (centered on the
note-head) and 1.0 means centered on the stem (intermediate values are
of course possible). I also added a check whether the grob in question
actually possesses a stem, so it works well for skips, too (perhaps
there is a more Lilypond-ish way of doing things but as far as I could
test, it works).
Since Reinhold said it would be best to make the shifting optional and
off by default, I didn't set any properties in script.scm. But the
shifting can of course be overridden in the .ly file itself (see
attached example). My only question is, how can I set the property for
individual script types instead of all scripts at once, i.e. what
would I need to write instead of
\override Script #'shifted-towards-stem = #'1.0
if I wanted to enable shifting only for staccato marks, say?
Max
P.S.: In case this gets approved in one form or the other, what would
be necessary to document it properly? Add a LSR example, a regression
test, something else? Anything I need to keep in mind when writing
these?
From 383b8f1bf05af263fb8049bc41b1895e59de3a2d Mon Sep 17 00:00:00 2001
From: Maximilian Albert [EMAIL PROTECTED](none)
Date: Sun, 7 Dec 2008 15:09:21 +0100
Subject: [PATCH] New grob-property 'shifted-towards-stem (allows scripts to be placed anywhere between the note head and the stem)
---
lily/script-interface.cc |1 +
scm/define-grob-properties.scm |4
scm/output-lib.scm | 20 +++-
3 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/lily/script-interface.cc b/lily/script-interface.cc
index a525500..8195ccc 100644
--- a/lily/script-interface.cc
+++ b/lily/script-interface.cc
@@ -129,6 +129,7 @@ ADD_INTERFACE (Script_interface,
positioning-done
script-priority
script-stencil
+ shifted-towards-stem
slur
slur-padding
);
diff --git a/scm/define-grob-properties.scm b/scm/define-grob-properties.scm
index b697af3..98dde0e 100644
--- a/scm/define-grob-properties.scm
+++ b/scm/define-grob-properties.scm
@@ -551,6 +551,10 @@ value @code{-1} means left aligned, @[EMAIL PROTECTED], and
values may also be specified.)
(self-alignment-Y ,number? Like @code{self-alignment-X} but for
the [EMAIL PROTECTED])
+ (shifted-towards-stem ,number? Amount by which scripts are shifted
+towards the stem if their direction coincides with the stem direction.
[EMAIL PROTECTED] means keep the default position (centered on the note head),
[EMAIL PROTECTED] means centered on the stem. Interpolated values are possible.)
(shorten-pair ,number-pair? The lengths to shorten a
text-spanner on both sides, for example a pedal bracket. Positive
values shorten the text-spanner, while negative values lengthen it.)
diff --git a/scm/output-lib.scm b/scm/output-lib.scm
index b93edda..34768e5 100644
--- a/scm/output-lib.scm
+++ b/scm/output-lib.scm
@@ -669,4 +669,22 @@ centered, X==1 is at the right, X == -1 is at the left.
(define-public (script-interface::calc-x-offset grob)
(ly:grob-property grob 'positioning-done)
- (ly:self-alignment-interface::centered-on-x-parent grob))
+ (let* ((shift (ly:grob-property grob 'shifted-towards-stem))
+ (note-head-pos (ly:self-alignment-interface::centered-on-x-parent grob))
+ (note-head-grob (ly:grob-parent grob X))
+ (stem-grob (ly:grob-object note-head-grob 'stem)))
+(+ note-head-pos
+ ;; If the property 'shifted-towards-stem is defined and the script has the
+ ;; same direction as the stem, move the script accordingly. Since scripts can
+ ;; also be over skips, we need to check whether the grob has a stem at all.
+ (if (or (null? shift)
+ (null? stem-grob))
+ 0.0
+ (let* ((dir1 (ly:grob-property grob 'direction))
+ (dir2 (ly:grob-property stem-grob 'direction))
+ (common-refp (ly:grob-common-refpoint grob stem-grob X))
+ (stem-pos (ly:grob-relative-coordinate stem-grob common-refp X)))
+ (if (equal? dir1 dir2)
+ (* shift (- stem-pos
+ note-head-pos))
+ 0.0))
--
1.5.4.3
shifted_scripts.ly
Description: Binary data
attachment: shifted_scripts.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix for bug #218 (center staccato over stem instead of notehead)
2008/12/7 Till Rettig [EMAIL PROTECTED]: This is great news, I remember I have a piece where the dots are for a realy long passage on the top and they look so strange centered by the head. But, as Reinhold pointed out, I think they should still be slightly off the stem by some amount. Actually I would hope you figure out how to apply this only to staccato dots and find a good default value -- or then there could be a switch like \typographicalStaccatoOn/Off. With Neil's suggestion (which is implemented in the last patch) it's no problem at all to apply it only to staccato notes by default - just add the line (shifted-towards-stem . 0.5) in scm/script.scm anywhere in the block belonging to staccato. This places dots in the middle between note head and stem (for different positions, replace the value 0.5 with whatever you like best). Only so far I don't know how to change this value interactively in the .ly file, but I'm sure someone can tell us. Please also write some bit for the documentation so the simple user will be able to use it. :-) Yes, I'll do so when the way to solve this bug/problem is settled (perhaps there are some other hidden pitfalls in the last patch). Thanks for your efforts! The same to you! From what I gather you're among the most active ones on this list and the German community owes you a lot for all your translation (and other) efforts! Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix for bug #218 (center staccato over stem instead of notehead)
Hi Joe, Neil, thanks a lot for your quick and helpful responses! The right place to look, therefore, is at the X-offset property of the Script grob, which is set in scm/define-grobs.scm to script-interface::calc-x-offset (which lives in scm/output-lib.scm). OK, so I only need to adapt script-interface::calc-x-offset so that if the stem and articulation have the same direction it calculates a different horizontal shift, correct? Attached is a patch which implements this (it took me a bit to figure out which scheme functions yield the needed properties, but I hope I got it right - comments are again welcome). One Remark: I use (ly:grob-relative-coordinate stem-grob common-refp X) to compute the relative offset of the articulation grob w.r.t. the stem grob. I suppose that in principle this should read (- (ly:grob-relative-coordinate stem-grob common-refp X) (ly:grob-relative-coordinate grob common-refp X)) but the second number always seems to be 0 so I omitted it. Is this a safe assumption? I'm fine with it applying to all articulations. Just today I saw an example where a marcato over an up-stem half note was _not_ shifted and I liked it better. So I'm wondering if for now we should only implement the shifting for staccato marks until we have better rules for other articulation types (e.g., should the shifting depend on whether the notes are beamed or not, should it only apply to certain note values?). I haven't included this in the patch because I couldn't find a scheme equivalent for testing the 'articulation-type property which Neil mentioned. Any hints? Thanks again, Max From 8124af5050ceccc31c867af739d03ccc73fec4af Mon Sep 17 00:00:00 2001 From: Maximilian Albert [EMAIL PROTECTED](none) Date: Tue, 2 Dec 2008 01:36:51 +0100 Subject: [PATCH] Fix for bug #218 (if articulation is over the stem, it should be centered on it) --- scm/output-lib.scm | 12 +++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/scm/output-lib.scm b/scm/output-lib.scm index dcb1129..5593e84 100644 --- a/scm/output-lib.scm +++ b/scm/output-lib.scm @@ -669,4 +669,14 @@ centered, X==1 is at the right, X == -1 is at the left. (define-public (script-interface::calc-x-offset grob) (ly:grob-property grob 'positioning-done) - (ly:self-alignment-interface::centered-on-x-parent grob)) + (let* + ((note-head-grob (ly:grob-parent grob X)) + (stem-grob (ly:grob-object note-head-grob 'stem)) + (common-refp (ly:grob-common-refpoint grob stem-grob X)) + (dir1 (ly:grob-property grob 'direction)) + (dir2 (ly:grob-property stem-grob 'direction))) +;; If articulation is over the stem, it should be +;; centered on the latter instead of the note head +(if (equal? dir1 dir2) + (ly:grob-relative-coordinate stem-grob common-refp X) + (ly:self-alignment-interface::centered-on-x-parent grob -- 1.5.4.3 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Arrowed accidentals for microtone notation
2008/12/2 Werner LEMBERG [EMAIL PROTECTED]: Sorry for the late reply. No worries. Thanks for taking a look! Is there any reason that inner part of flat.arrowup and friends has a different shape compared to a normal flat? See attached images -- this looks like a buglet in your code. Besides that, everything looks nice. You are right. It's caused by side effects of my changes in parts of the code which I didn't touch. Namely, upon taking a closer look I noticed that the reference points z3l, z3r, z10 depend on the position of z1r, which controls the thickness of the top end of the stem. For the arrowed accidentals I had to reduce this thickness a little to make them look nicer, but that had the unintended side effect of changing the inner part, too. It should be easy to fix but I'd like to investigate the effects of the fix somewhat more thoroughly and fiddle a bit more with the parameter to find an optimal value before resending the patch. However, I'm unable to compare the new accidentals side by side as in your images because I can only investigate them in the dvi file which is output by metafont. How do you produce these images? Are they just screenshots from fontforge or is it possible to export these kinds of pictures somehow? Also, how can I avoid recompiling all fonts after making changes (which takes ages)? Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Fix for bug #218 (center staccato over stem instead of notehead)
Hi,
attached is a patch for bug #218 (see
http://code.google.com/p/lilypond/issues/detail?id=218). It simply
tests whether the directions of stem and articulation coincide, and if
so it shifts the latter sideways. Please note that the patch is just a
casual attempt to get more familiar with Lilypond's internals and that
the way it is implemented was derived mostly by trial-and-error and
sophisticated guessing. So any suggestions for improvement are most
welcome.
BTW, in the bug's description it says that only staccato marks should
be centered on the stem, but I personally find it more appealing if
this applies to any kind of articulation. If you think otherwise, I'd
be happy to adapt the patch but I don't know how to test whether the
grob actually is a staccato mark or something else.
Cheers,
Max
From 1922d0676cafafe07e9b613a9788ebc3032837f1 Mon Sep 17 00:00:00 2001
From: Maximilian Albert [EMAIL PROTECTED](none)
Date: Fri, 28 Nov 2008 00:46:16 +0100
Subject: [PATCH] If articulation is over the stem, it should be centered on it (fixes bug #218)
---
lily/script-engraver.cc |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/lily/script-engraver.cc b/lily/script-engraver.cc
index d0d713b..6ba1072 100644
--- a/lily/script-engraver.cc
+++ b/lily/script-engraver.cc
@@ -167,11 +167,18 @@ Script_engraver::process_music ()
void
Script_engraver::acknowledge_stem (Grob_info info)
{
+ Grob *stem = info.grob();
+ int stem_dir = robust_scm2int(stem-get_property(direction), 0);
int script_count = scripts_.size ();
for (int i = 0; i script_count; i++)
{
Grob *e = scripts_[i].script_;
+ /* If articulation is above the stem, it should be centered on it */
+ int script_dir = robust_scm2int(e-get_property(direction), 0);
+ if (stem_dir == script_dir)
+ e-translate_axis(stem-relative_coordinate(e, X_AXIS), X_AXIS);
+
if (to_dir (e-get_property (side-relative-direction)))
e-set_object (direction-source, info.grob ()-self_scm ());
--
1.5.4.3
attachment: before.pngattachment: after.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix for broken examples in section about explicit vertical positioning
2008/11/21 Neil Puttock [EMAIL PROTECTED]: Thanks for the patch; it's a definite improvement. :) Unfortunately, that's just the start of what's wrong with these examples; [...] Therefore, I've applied your patch together with the following changes: [...] Awesome, thanks a lot for improving the examples! Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Fix for broken examples in section about explicit vertical positioning
Hi,
in the Documentation section about explicit vertical positioning, the
four examples have too many measures per line. This makes the lines
break in a funny way and garbles the examples quite a lot (see
http://tinyurl.com/expl-vert-spacing). Although I thought I knew a bit
about vertical spacing, it took me quite a while to connect the
pictures to the text while reading this section (actually, I had to
look at the code before it made sense). I suggest reducing the number
of measures from 6 to 5 per line so that there are no unintended line
breaks. Corresponding patches against master are attached (for the
English and Spanish version separately, in case the latter is somehow
automatically generated from the former).
Cheers,
Max
From 9cc0cbef69c4227127371f6d8e65946ed6a8889f Mon Sep 17 00:00:00 2001
From: Maximilian Albert [EMAIL PROTECTED]
Date: Fri, 21 Nov 2008 10:43:05 +0100
Subject: [PATCH] Examples for vertical spacing: Reduce number of measures per line so that they don't break due to the short line length
---
Documentation/user/spacing.itely | 42 +++---
1 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/Documentation/user/spacing.itely b/Documentation/user/spacing.itely
index baabf80..349eabd 100644
--- a/Documentation/user/spacing.itely
+++ b/Documentation/user/spacing.itely
@@ -1507,14 +1507,14 @@ by looking at an example that includes no overrides at all.
\new Score
\new Staff
\new Voice {
- s1 * 6 \break
- s1 * 6 \break
- s1 * 6 \break
+ s1 * 5 \break
+ s1 * 5 \break
+ s1 * 5 \break
}
-\new Voice { \repeat unfold 18 { c'4 c'4 c'4 c'4 } }
+\new Voice { \repeat unfold 15 { c'4 c'4 c'4 c'4 } }
\new Staff {
-\repeat unfold 18 { d'4 d'4 d'4 d'4 }
+\repeat unfold 15 { d'4 d'4 d'4 d'4 }
}
@end lilypond
@@ -1536,18 +1536,18 @@ attribute of the @code{NonMusicalPaperColumn} grob:
\new Voice {
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details #'((Y-offset . 0))
- s1 * 6 \break
+ s1 * 5 \break
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details #'((Y-offset . 40))
- s1 * 6 \break
+ s1 * 5 \break
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details #'((Y-offset . 80))
- s1 * 6 \break
+ s1 * 5 \break
}
-\new Voice { \repeat unfold 18 { c'4 c'4 c'4 c'4 } }
+\new Voice { \repeat unfold 15 { c'4 c'4 c'4 c'4 } }
\new Staff {
-\repeat unfold 18 { d'4 d'4 d'4 d'4 }
+\repeat unfold 15 { d'4 d'4 d'4 d'4 }
}
@end lilypond
@@ -1569,20 +1569,20 @@ subproperty of @code{line-break-system-details}.
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details #'((Y-offset . 20)
(alignment-offsets . (0 -15)))
- s1 * 6 \break
+ s1 * 5 \break
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details #'((Y-offset . 60)
(alignment-offsets . (0 -15)))
- s1 * 6 \break
+ s1 * 5 \break
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details #'((Y-offset . 100)
(alignment-offsets . (0 -15)))
- s1 * 6 \break
+ s1 * 5 \break
}
-\new Voice { \repeat unfold 18 { c'4 c'4 c'4 c'4 } }
+\new Voice { \repeat unfold 15 { c'4 c'4 c'4 c'4 } }
\new Staff {
-\repeat unfold 18 { d'4 d'4 d'4 d'4 }
+\repeat unfold 15 { d'4 d'4 d'4 d'4 }
}
@end lilypond
@@ -1604,24 +1604,24 @@ specifies the vertical positioning of staves but not of staff groups.
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details #'((Y-offset . 0)
(alignment-offsets . (0 -30 -40)))
- s1 * 6 \break
+ s1 * 5 \break
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details #'((Y-offset . 60)
(alignment-offsets . (0 -10 -20)))
- s1 * 6 \break
+ s1 * 5 \break
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details #'((Y-offset . 100)
(alignment-offsets . (0 -10, -40)))
- s1 * 6 \break
+ s1 * 5 \break
}
-\new Voice { \repeat unfold 18 { c'4 c'4 c'4 c'4 } }
+\new Voice { \repeat unfold 15 { c'4 c'4 c'4 c'4 } }
\new StaffGroup
\new Staff {
- \repeat unfold 18 { d'4 d'4 d'4 d'4 }
+ \repeat unfold 15 { d'4 d'4 d'4 d'4 }
}
\new Staff {
- \repeat unfold 18 { e'4 e'4 e'4 e'4 }
+ \repeat unfold 15 { e'4 e'4 e'4 e'4 }
}
--
1.5.4.3
From e4cc73ed87b31b0039540e1887acb41fe3bb353b Mon Sep 17 00:00:00 2001
From: Maximilian Albert [EMAIL PROTECTED]
Date: Fri, 21 Nov 2008 10:49:47 +0100
Subject: [PATCH] Also reduce number of measures in spacing examples in Spanish version
---
Documentation/es/user/spacing.itely | 42 +-
1 files changed, 21
Re: PATCH: Arrowed accidentals for microtone notation
Hi, this is my third attempt to send this email. It seems to have been rejected twice due to size and sending it from the wrong account (things get complicated when you can't use the computer/setup you're used to). I hope it finally gets through this time; sorry if you received it multiple times anyway. The original message follows below. Cheers, Max === 2008/11/9 Maximilian Albert [EMAIL PROTECTED]: Hi all, after my laptop crash and endless attempts ( though unsuccessful ones, unfortunately) to set up a development environment on one of the university computers, I was finally able to borrow a friend's laptop, copy over the files from my old hard drive and set up a git repository to work on the changes Werner suggested. I am truly sorry that it took me again so long to make this work (but even accessing to the old files wasn't as easy as I had hoped). The reworked patches for the new arrowed accidentals are attached (I'm also attaching metafont's dvi output for inspection). Does this fix all the issues? Any further comments? Thanks again for your help and suggestions, Max arrowed_accidentals_patch_corr.tgz Description: GNU Zip compressed data arrowed_accidentals.dvi.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Arrowed accidentals for microtone notation
Hi Werner, first of all my apologies for having let you wait another week. I was on a maths conference first, then in the Netherland for a choir competition, and unexpectedly I didn't have internet access during any of both events. What's worse, my laptop just decided to stop working (don't know how severe a problem it is and how long it will take to fix) so I currently can't access my local repositories to test any further changes to my patches. :-( This looks very nice! Thanks! . With patch #6, you are widening the shape of a sharp if you either attach an up arrow or two arrows, but you don't do that for a down arrow only. This is a bad idea IMHO. You should widen the charbox alone but not the shape. Hmm, you are right. For whatever reason I visually inspected the wrong glyphs after applying the changes so I didn't notice the wider shapes. I thought that set_char_box only widened the charbox, not the shape, but apparently this is not so. How can I widen only the charbox without affecting the shape's width? Sorry if this is a dumb question but my last intensive metafont experience was a year ago. BTW, this problem may also be present in the other patches (e.g., from last time when my laptop worked I seem to remember that the sharp sign with up arrow looked wider than it should). . For the natural with an arrow up, you also make the opposite, non-arrowed end smaller. This is a bug, I think, since you don't do that for the natural with an arrow down. This should be fixed in the attached corrected patch #4. Note again that due to the problems with my computer the patch is hand-edited and untested. . The height and depth of all arrowed characters is a bit too large. Why? What do you mean by too large? (I.e., with respect to what?) Are the heights of arrowed acidentals different from the regular ones? After adding your (corrected) patches #1 to #5, maybe Joe or Neil can play with it, finding out why there are collisions. Note that the current skyline algorithm always handles glyphs as rectangles. We don't have a finer resolution (yet). It would be good if you can provide ugly test cases. OK, I will see to providing some when the work on the patches is done (and I have my laptop or at least another system up and running again). Thanks very much for your review and comments, Max P.S.: Initially, I had hoped that the patches would still be in time for 2.12. But now, with my laptop not working, I don't know if I'll be able to do the necessary corrections before feature freeze (even though for once I'd have enough time during the next few weeks). What is the envisaged time scale for 2.12? And more importantly, would these accidentals have a chance of being approved for the new version? -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 0004-Add-arrowed-natural-signs.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Arrowed accidentals for microtone notation
Hi all, for various reasons I've been inactive on this list for quite a long time. My last post was concerning a possible contribution, namely arrowed microtonal accidentals, which have been requested on this list quite a few times. IIRC, I had already sent a pdf file showing off the new accidentals but haven't provided a patch yet. The reason for this is that 1) out of some amazing stupidness I hadn't properly put my attempts under version control and thus needed to re-write a couple of things and 2) the original design was very generic (to allow for easy tweaking), but once the design was settled I needed to eliminate a lot of variables, which turned out much more time-consuming than expected. So alas I didn't get to do it before now. My sincere apologies to everyone who has been waiting for me to follow up. Anyway, here finally is a series of patches implementing these accidentals. The first one adds a function to draw the arrow, while the other ones add sharp/flat/natural signs with up- and downward pointing arrows attached. I made it so that the plain accidentals (i.e., without arrows) are created using the exact same operations as before, so that their shape isn't changed. Nnote that for natural and flat signs *with* arrows attached the brushing of the stems needed to be slightly reduced, or else they would look very awkward; but this only applies to the new accidentals. Patch No. #5 is optional because it adds accidentals with arrows in *both* directions (which is probably not needed, but you never know what people want to use in their scores :-). As for No. #6, see below. A sample .pdf showing the accidentals in various positions is attached, together with its .ly file (the latter is basically a slight variation of the maqam example). I guess that the file could be stripped down but I was too lazy for that. :-) In any case, it should be easy to adapt it so that you can inspect the accidentals in all positions and combinations. Anyone up for a review? Cheers, Max P.S.: I took care to make the charboxes precisely enclose the glyphs (which metafont confirms). However, the result looks rather clamped, and there are even occasional collisions with the arrowheads. Is this a bug in lilypond's spacing algorithm? I seem to remember that there have been problems with accidentals being placed too close to other symbols. Could this be the same issue? If for some reason there really needs to be more space around the glyphs, you can also apply patch #6 (and tweak the numbers if you wish). micro_accs_patches.tgz Description: GNU Unix tar archive microtone_accs.pdf Description: Adobe PDF document \include deutsch.ly #(define-public KOMA 1/9) #(define-public BAKIYE 4/9) #(define-public KUCUK 5/9) #(define-public BUYUKMUCENNEB 8/9) makamPitchNames = #`( (c . ,(ly:make-pitch -1 0 NATURAL)) (d . ,(ly:make-pitch -1 1 NATURAL)) (e . ,(ly:make-pitch -1 2 NATURAL)) (f . ,(ly:make-pitch -1 3 NATURAL)) (g . ,(ly:make-pitch -1 4 NATURAL)) (a . ,(ly:make-pitch -1 5 NATURAL)) (b . ,(ly:make-pitch -1 6 NATURAL)) (cc . ,(ly:make-pitch -1 0 KOMA)) (dc . ,(ly:make-pitch -1 1 KOMA)) (ec . ,(ly:make-pitch -1 2 KOMA)) (fc . ,(ly:make-pitch -1 3 KOMA)) (gc . ,(ly:make-pitch -1 4 KOMA)) (ac . ,(ly:make-pitch -1 5 KOMA)) (bc . ,(ly:make-pitch -1 6 KOMA)) (cb . ,(ly:make-pitch -1 0 BAKIYE)) (db . ,(ly:make-pitch -1 1 BAKIYE)) (eb . ,(ly:make-pitch -1 2 BAKIYE)) (fb . ,(ly:make-pitch -1 3 BAKIYE)) (gb . ,(ly:make-pitch -1 4 BAKIYE)) (ab . ,(ly:make-pitch -1 5 BAKIYE)) (bb . ,(ly:make-pitch -1 6 BAKIYE)) (ck . ,(ly:make-pitch -1 0 KUCUK)) (dk . ,(ly:make-pitch -1 1 KUCUK)) (ek . ,(ly:make-pitch -1 2 KUCUK)) (fk . ,(ly:make-pitch -1 3 KUCUK)) (gk . ,(ly:make-pitch -1 4 KUCUK)) (ak . ,(ly:make-pitch -1 5 KUCUK)) (bk . ,(ly:make-pitch -1 6 KUCUK)) (cbm . ,(ly:make-pitch -1 0 BUYUKMUCENNEB)) (dbm . ,(ly:make-pitch -1 1 BUYUKMUCENNEB)) (ebm . ,(ly:make-pitch -1 2 BUYUKMUCENNEB)) (fbm . ,(ly:make-pitch -1 3 BUYUKMUCENNEB)) (gbm . ,(ly:make-pitch -1 4 BUYUKMUCENNEB)) (abm . ,(ly:make-pitch -1 5 BUYUKMUCENNEB)) (bbm . ,(ly:make-pitch -1 6 BUYUKMUCENNEB)) ;; f for flat. (cfc . ,(ly:make-pitch -1 0 (- KOMA))) (dfc . ,(ly:make-pitch -1 1 (- KOMA))) (efc . ,(ly:make-pitch -1 2 (- KOMA))) (ffc . ,(ly:make-pitch -1 3 (- KOMA))) (gfc . ,(ly:make-pitch -1 4 (- KOMA))) (afc . ,(ly:make-pitch -1 5 (- KOMA))) (bfc . ,(ly:make-pitch -1 6 (- KOMA))) (cfb . ,(ly:make-pitch -1 0 (- BAKIYE))) (dfb . ,(ly:make-pitch -1 1 (- BAKIYE))) (efb . ,(ly:make-pitch -1 2 (- BAKIYE))) (ffb . ,(ly:make-pitch -1 3 (- BAKIYE))) (gfb . ,(ly:make-pitch -1 4 (- BAKIYE))) (afb . ,(ly:make-pitch -1 5 (- BAKIYE))) (bfb . ,(ly:make-pitch -1 6 (- BAKIYE))) (cfk . ,(ly:make-pitch -1 0 (- KUCUK))) (dfk . ,(ly:make-pitch -1 1 (- KUCUK))) (efk . ,(ly:make-pitch -1 2 (- KUCUK))) (ffk . ,(ly:make-pitch -1 3 (- KUCUK)))
Re: Acciaccaturas with beams have no slash
Trevor Daniels wrote: In either case, is there an accepted 'best' method of adding a slash now, should the user wish to have one? Mats Bengtsson wrote: Since the general intention of LilyPond is to support many different notation conventions (at least by tweaking some properties), I would classify this as a missing feature. As far as I can recall, the workarounds that have been posted on the mailing list require some trial and error to get the correct layout, so they don't seem appropriate for inclusion in the manual. An example in LSR, on the other hand, wouldn't hurt. Since I'm not familiar with appoggiaturas/acciacaturas in any way, I'm not sure if this is is relevant for the topic. But a while ago I posted a scheme function which allows adding slashes to note stems, see here: http://lists.gnu.org/archive/html/lilypond-user/2007-04/msg00422.html It's a rather generic function with a number of parameters that can be tweaked so as to achieve precisely the kind of slash the user desires. Maybe this can be useful for what you want (or maybe I completely misunderstood the topic). It may require cleanup or adaption before it is added to LSR, though, so you are welcome to improve it. But perhaps it's a start. Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Microtone accidentals
Hi Victor, sorry for this late reply - I was away over the weekend and got stuck in work once more. I printed out your 20pt example sheet in a standard laser printer at 1200dpi. Thanks for your feedback and your help in trying to assess these glyphs! However, if you allow me to be ultra picky, [...] Sure. :) I might suggest stretching the arrows slightly (maybe an extra 50%), keeping the width as it is. The same thought had crossed my mind, and I did indeed play with taller (and sometimes wider) versions. It turned out that making them taller (while keeping the width) makes them look rather awkward. On the other hand, increasing both width and height makes them look unproportionally big compared to the accidentals themselves, which gives a really ugly impression. Also, in playing with these parameters I found it difficult to decide whether the arrowtip should be covered by the staffline or if it should protrude through it (and in this case how far). For I got the impression that if the arrowtips of arrows that fall into spaces are not clearly discernible (because they are covered by the staffline or protrude too little), the corresponding arrowheads appear a bit larger than the other ones (probably caused by the additional blackness of the staffline), which gives an uneven overall impression. But this may be remediable by a careful design. If you or anyone else has any suggestions in this direction, I could try again to produce something reasonably-looking (although honestly I doubt that I would succeed, and I almost certainly won't get around to it during the next two weeks, I'm afraid :( ). Best, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Microtone accidentals
Werner LEMBERG schrieb: Thanks for your feedback and your help in trying to assess these glyphs! Where can I find the patch? I haven't yet sent it over because it still needs a bit of cleanup (hmm, quite a bit, actually). Thus I thought I'd ask first if there are any major objections before I invest too much time polishing something that runs the risk of ending up being fundamentally reworked. But if you'd like a patch then I will try to provide it as soon as possible (can't promise if it will be before the weekend, though, sorry). Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Caesura, n-th time :)
Werner LEMBERG schrieb: Applied. I've modified the shape of the straight caesura to be more in sync with other feta glyphs; I've simplified and `metafontisized' the code additionally. Thanks! I was aware that the code I sent over was slightly complicated (as Han-Wen correctly pointed out). But my first attempt back in March or April had the problem that adjacent curved corners *looked* as if one was larger than the other although mathematically they had the same size (i.e., radius). This was due to a different amount of blackness caused by the slant. Therefore I manually tweaked the code this time so as to achieve more balanced glyphs by having roughly the same area filled by each rounded corner. I'm surprised that you managed to do it with this much simpler approach because I'm sure I tried this myself. The blackness is not 100% the same for all corners, but it's hardly noticeably at all and I guess it doesn't have to be anyway. Thanks again for reworking and incorporating this. BTW, regarding your comment in an earlier email about asymmetrical corners: Regarding `noteheads.s[012]slash', this is not true. If you use mf2pt1 to generate the feta fonts you can see that. I rather suspect an artifact of the current glyph generation with mftrace. After seizing your suggestion and playing a bit with FontForge (not much, though), I still believe that the mentioned glyphs have rather unbalanced corners - unless I'm missing something obvious. I don't mind in any way, just thought I'd mention it because Han-Wen complained about the same aspect of the first caesura draft from spring (where he was absolutely right). Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Microtone accidentals
Trevor Bača wrote: These are outstanding! I don't have access to a true high-resolution printer, but the output on my end is perfectly legible and I'd very much like to have access to these new glyphs for use in my own scores. Thanks for your kind feedback. Much appreciated. :) Also, I have a question: have you given any thought to adding these same arrows to the quartertone accidentals as well? Indeed I have. But I figured it might be good to ask for some feedback first. :) It shouldn't be a big problem to get these working once the design is settled and approved, since they all have similar shapes and the arrow design is largely parametrized. Only the mirroredflat.flat symbol might cause a bit more work since the bottom is wider than that of the other symbols so that some curves may need to be adapted in order to integrate smoothly with the arrowshaft. But that can be tackled when the time comes. First, it would be nice to know if there is any interest in having these included and if anything needs to be improved. Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc addition to 8.1.2 Text and line spanners ... concerning \endSpanners
Trevor Bača wrote:
So that's a brief explanation of the function. Could you please insert
the following at the very bottom of 8.1.2 Text and line spanners,
immediately before the see also?
%%% BEGIN DOC ADDITION %%%
The music function \endSpanners terminates spanners and hairpins after
exactly one note.
\new Staff {
\endSpanners
c'2 \startTextSpan c'2
c'2 \ c'2
}
When using \endSpanners it is not necessary to close \startTextSpan
with \stopTextSpan, nor is it necessary to close hairpins with \!.
%%% END DOC ADDITION %%%
One thing I realize now writing this update is that I don't know if
there is a way to turn \endSpanners *off* at some point in input and
return to specifying spanner (and hairpin) endpoints manually.
Compiling your example (with version 2.11.34) results in the warning
unterminated (de)crescendo, and the hairpin is not present in the pdf
output. After inserting \endSpanners *twice*, however, like so:
%%% BEGIN CODE %%%
\new Staff {
\endSpanners
c'2 \startTextSpan c'2
\endSpanners
c'2 \ c'2
}
%%% END CODE %%%
... the warning disappears and the hairpin is visible in the way you
described. Which leads me to think that \endSpanners only applies to the
spanner immediately following the command (similar to a \once). It's
just a guess, though, without having looked at the code.
Best,
Max (who should finally learn not to read emails while trying to get his
work done :))
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Microtone accidentals
Hi everyone, here is the last and biggest unfinished project that has been resting on my hard drive for a while: Arrowed accidentals for microtone notation. At present Lilypond already has good support for quarter- and other microtones (see, e.g., section 6.1.4 of the manual or the NEWS file of v2.11 where Turkish makam music is mentioned). But from earlier requests on this list it seems that at least some composers frequently use accidentals with up- and down-arrows to indicate microtones, which is not yet natively supported by Lilypond (although I seem to remember another thread proposing a postcript-based workaround). Inspired by a request a while ago I started to implement these arrowed accidentals as new glyphs in their own right. At that time I encountered problems with the design of the arrowhead because it either turned out too small or was poorly separated from the surrounding stafflines. Attached is a sample [1] of redesigned glyphs where this problem is hopefully solved. IMHO the size, blackness, and overall style of the arrowheads goes together well the accidentals, but I have the slight fear that the arrowheads might be a bit too small to be legible when printed. Unfortunately I don't own a high resolution printer myself, so I can only judge the design based on the visual appearance on the screen (which seems to be fine). Thus I would be extremely grateful if someone with a good printer could comment on the design (of course, other comments from the experts and interested users are very welcome, too). If there are no problems related to legibility and the design is approved of by the main developers, I'd be glad to send over a patch (I presume that there is interest to include them in Lilypond?). Otherwise please let me know how the glyphs can be improved (or at least what is wrong with them). I don't know the exact timeline for v2.12, and I will be able to invest only little time in the near future, I'm afraid, but if there is interest to include them and it turns out that not too many adaptions need to be made, it would be terrific if they made it into the new stable release. Cheers, Max [1] In two versions: Both as a kind of proof sheet for on-screen inspection (which features a really huge staffsize) and also with normal-sized (= 20pt) staves for printing. arrowed_accidentals_big.pdf Description: Adobe PDF document arrowed_accidentals.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Caesura, n-th time :)
Werner LEMBERG schrieb: ... Basically, you are right, however, we have already to think about backwards compatibility... Good point. This made me think that in case my recent patch is applied, maybe convert-ly (or rather convertrules.py) should be updated, too!? Just in case I'm sending a patch for that as well. Hopefully, I correctly guessed the way it works. I inserted the rule scripts.caesura -- scripts.caesura.curved because this doesn't change the appearance of the output. However, given that many users seem to prefer the straight caesura, would it make sense to use scripts.caesura.straight as the replacement? Another option would be to keep the above rule but use accidentals.caesura rather than accidentals.caesura.straight as name for the new glyph in mf/feta-toevallig.mf. If someone then uses convert-ly to update old files, the output will be the same as before because it contains the old glyph. But if old files are simply compiled with a newer version of lilypond, the new glyphs appears. Anyway, these are just a few random thoughts. I'll leave the decisions to you experts. Interesting. How can I make lily use mf2pt1 to generate the fonts? As documented in mf/README, for example: mf2pt1 --rounding=0.001 --ffscript=makelilypond.pe feta26 The script `makelilypond.pe' is attached (however, it isn't necessary for inspection). I'm sending you some output privately. Thanks a lot for these hints and the script. This will make font inspection and glyph design a lot easier, I suppose (once I get more used to working with FontForge). And sorry, I thought I knew what was in the README file, but I should have checked first anyway. I'll probably have one or two further questions/comments but will ask them in a separate email once they have crystallized out completely. Best regards, Max From bad04ca58e8bc25c9932b6a1c719155ec32df5a7 Mon Sep 17 00:00:00 2001 From: Maximilian Albert [EMAIL PROTECTED] Date: Tue, 2 Oct 2007 10:18:50 +0200 Subject: [PATCH] Update convert-ly (include change in caesura glyph name) --- python/convertrules.py |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/python/convertrules.py b/python/convertrules.py index 54db434..b56c673 100644 --- a/python/convertrules.py +++ b/python/convertrules.py @@ -3013,3 +3013,9 @@ def conv (str): conversions.append (((2, 11, 23), conv, #'break-align-symbol - #'break-align-symbols)) +def conv (str): +str = re.sub (rscripts\.caesura, + rscripts.caesura.curved, str) +return str + +conversions.append (((2, 11, 35), conv, scripts.caesura - scripts.caesura.curved)) -- 1.5.3.1 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Update to mf/README
Hi, long ago I promised to add some info to mf/README about how stem attachments work for lilypond glyphs. Here finally is a patch. Since the conclusions I drew were derived by trial and error, I may have misinterpreted or overlooked something. Thus I'd be grateful if one of the metafont experts could give it a quick review. Also, please feel free to modify the wording as you like - I keep realizing that in English I find it difficult to write clearly and concisely at the same. Thanks, Max From 2fb7170681ad404fc7d2749e413210df4801e24d Mon Sep 17 00:00:00 2001 From: Maximilian Albert [EMAIL PROTECTED] Date: Sun, 30 Sep 2007 17:57:58 +0200 Subject: [PATCH] Add info about stem attachments to mf/README --- mf/README | 30 ++ 1 files changed, 30 insertions(+), 0 deletions(-) diff --git a/mf/README b/mf/README index 89eef4e..6239581 100644 --- a/mf/README +++ b/mf/README @@ -77,6 +77,36 @@ Some design rules: . Use rounded corners. +Hints for stem attachment: + +. Stem attachment of glyphs is controlled by two special variables + called 'charwx' and 'charwy'. Stems can be regarded as (very oblonged) + rectangles with slightly rounded corners. For upward-pointing stems the + lower right corner of this rectangle is attached to the glyph at position + (charwx, charwy). For downward-pointing stems it works analogously but + with the upper left corner, where the position of the attachment point + is additionally reflected horizontally about the center of the glyph (this + ensures that in most cases charwx and charwy can be set to the same values + for up- and down-stems even though these are attached at the right/left end + of the note, respectively). To make this more precise, the upper left + corner of a down-stem is attached at position (charwd/2 - charwx, charwy), + where charwd is an internal metafont variable representing the glyph width + as specified by the set_char_box command. + +. In case different stem attachments for upward- and downward-pointing stems + are needed, two separate glyphs must be defined in the *.mf file (of course + this also applies if two entirely different shapes are needed). These have + the same name but are prefixed by u and d, respectively (for up and + down, obviously). In each of these glyphs the variables charwx and charwy + must be set accordingly. If, on the other hand, the attachment point is the + same for both directions (with the above-mentioned horizontal reflection + taken into account) then the prefix s (for symmetric) should be used. + See the existing files for examples. The numbers in the glyph names refer to + the duration of the note; e.g., s0cross in feta-bolletjes.mf defines the + notehead for a whole cross-shaped note (similarly, 's1cross' and 's2cross' + are for half and quarter notes, respectively). + + Finally, some rules to assure that rasterization at low resolutions gives good results. Today, this is a minor issue, but in some cases it might show design flaws. -- 1.5.3.1 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Caesura, n-th time :)
Werner LEMBERG schrieb: The first one is a stab at a new caesura glyph that has continuously been requested on this list, according to the archives. Is there any reason why you are replacing the old glyph shape instead of adding a new one? Well, the comment in mf/feta-schrift.mf: % I actually have no clue how they should look, so we use a slightly % curvy and tapered shape. seemed to imply that the shape was designed by guessing, not by using a hand-engraved example. Also, the corresponding threads in the mailing list archives gave the impression that all real-world examples encountered by users had the shape of straigth parallel slashes. That's why I suggested to replace the glyph. Sorry if I offended anyone - this was certainly not my intention. Also, I agree that adding it as an alternative - as suggested by Han-Wen in a separate email - is certainly better (just didn't occur to me, don't ask me why :)). A corresponding patch will follow. The only problem seemed to be that the corners didn't look very symmetrical (which by the way is also the case with the existing noteheads.s[012]slash glyphs). Regarding `noteheads.s[012]slash', this is not true. If you use mf2pt1 to generate the feta fonts you can see that. I rather suspect an artifact of the current glyph generation with mftrace. Interesting. How can I make lily use mf2pt1 to generate the fonts? Also, since I don't have a high-resolution printer, the only way to closely inspect the glyphs is (rather awkwardly) by using Acrobat Reader with the greates zoom level, which often also seems to show artefacts like edges that certainly shouldn't be there (or is this an mftrace-related problem, too?). Do you have any suggestions how to do this more conveniently and, more importantly, less error-prone? Thanks, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Caesura, n-th time :)
Han-Wen Nienhuys schrieb:
Hi,
can you send a patch which adds it as a new glyph (caesura.straight)
and leaves the old one as caesura.curved, and adjusts the .ly init
files appropriately? Also, if possible, a more verbose commit message
would be nice.
Sure! Corresponding patch is attached. Sorry for replacing the old glyph
in the first place (see my reply to Werner's email for an explanation).
However, I don't know what needs to be adjusted in the .ly init files.
The only reference to a caesura I could find was in gregorian-init.ly,
but the definition there uses the glyph 'scripts.rvarcomma', not
'scripts.caesura', so there's no need for adaption. Or am I missing
anything?
On the other hand, I believe at least one of the files
input/regression/breathing-sign.ly
input/lsr/expressive/breathing-sign.ly
should be updated. I'm not 100% sure, though, since the version number
at the top of input/regression/breathing-sign.ly reads 2.10.0, and the
second file has a remark saying that it should not be edited because it
is updated automatically from LSR.
In any case, I'm attaching a second patch to update the regression test
file if necessary. Please tell me if I should do anything else to update
the LSR one, too.
Thanks,
Max
From 2b7b439319336906ef83a74614ebbdb8720a2338 Mon Sep 17 00:00:00 2001
From: Maximilian Albert [EMAIL PROTECTED]
Date: Mon, 1 Oct 2007 18:39:32 +0200
Subject: [PATCH] Add a new caesura glyph (two straight parallel slashes) as caesura.straight; rename the existing one to caesura.curved
---
mf/feta-schrift.mf | 62 ---
1 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/mf/feta-schrift.mf b/mf/feta-schrift.mf
index 10eebb5..d801237 100644
--- a/mf/feta-schrift.mf
+++ b/mf/feta-schrift.mf
@@ -1445,13 +1445,12 @@ fet_endchar;
input feta-slag;
-% railroad tracks.
%
-% I actually have no clue how they should look, so we use a slightly curvy
-% and tapered shape.
+% Railroad tracks. We define two variants of these - both as slightly
+% tapered, comma-shaped curves and as two straight parallel slashes.
%
-fet_beginchar (Caesura, caesura);
+fet_beginchar (Curved caesura, caesura.curved);
save slant, space_between, clearance;
save alpha, pat;
save botthick, topthick;
@@ -1504,5 +1503,60 @@ fet_beginchar (Caesura, caesura);
fill pat shifted (space_between, 0);
fet_endchar;
+fet_beginchar (Straight caesura, caesura.straight);
+ save slant, space_between, clearance, height;
+ save thick, upslant, center, factor, pat;
+ path pat;
+ pair upslant, center;
+
+ slant = 2.0;
+ thick = 2.88 linethickness;
+
+ space_between# = 0.56 staff_space#;
+ clearance# = 0.2 staff_space#;
+
+ set_char_box (0, 2.0 staff_space#,
+ staff_space# - clearance#, 1.2 staff_space#);
+ define_whole_pixels (space_between);
+
+ height = h+d;
+
+ z1 = origin shifted (0,-d);
+ z2 = z1 shifted (thick,0);
+ z3 = z1 shifted (thick+height/slant,height);
+ z4 = z1 shifted (height/slant,height);
+
+ upslant = unitvector(z4-z1);
+ factor = 1.2 blot_diameter;
+ center = 0.5[z1,z3];
+
+ z1a = z1 shifted (upslant*factor);
+ z1b = z1 shifted (right*factor);
+ z2a = z2 shifted (upslant*factor);
+ z2b = z2 shifted (left*factor);
+
+ z3a = z1a rotatedabout (center,180);
+ z3b = z1b rotatedabout (center,180);
+ z4a = z2a rotatedabout (center,180);
+ z4b = z2b rotatedabout (center,180);
+
+ z1c = 0.4[z1,0.6[z1a,z1b]];
+ z3c = z1c rotatedabout (center, 180);
+
+ z2c = 0.4[z2,0.5[z2a,z2b]];
+ z4c = z2c rotatedabout (center, 180);
+
+ pat = z1a{-upslant}...z1c...{right}z1b--
+ z2b{right}...z2c...{upslant}z2a--
+ z3a{upslant}...z3c...{left}z3b--
+ z4b{left}...z4c...{-upslant}z4a--cycle;
+
+ fill pat;
+ fill pat shifted (space_between, 0);
+
+ labels(range 1 thru 4);
+ labels(1a,1b,2a,2b,3a,3b,4a,4b);
+ labels(1c,2c,3c,4c);
+fet_endchar;
fet_endgroup (scripts);
--
1.5.3.1
From 0639ae7f4ef4b03278ce2164f7dc59d56e1d6b12 Mon Sep 17 00:00:00 2001
From: Maximilian Albert [EMAIL PROTECTED]
Date: Mon, 1 Oct 2007 19:10:00 +0200
Subject: [PATCH] Update input/regression/breathing-sign.ly to account for the new caesura glyph
---
input/regression/breathing-sign.ly |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/input/regression/breathing-sign.ly b/input/regression/breathing-sign.ly
index 9a0fa00..4a04f42 100644
--- a/input/regression/breathing-sign.ly
+++ b/input/regression/breathing-sign.ly
@@ -42,10 +42,13 @@ ticks, vees and `railroad tracks' (caesura).
#(make-musicglyph-markup scripts.upbow)
es8 d es f g8 \breathe f |
- %% caesura
+ %% caesurae
\override BreathingSign #'text =
- #(make-musicglyph-markup scripts.caesura)
- es8[ d] \breathe es[ f g f] |
+ #(make-musicglyph-markup scripts.caesura.curved)
+ es8[ d] \breathe
+ \override BreathingSign #'text =
+ #(make-musicglyph-markup scripts.caesura.straight
Caesura, n-th time :)
Hi all,
I've been absent from direct involvement in the discussions on this list
for quite a while, and unfortunately this isn't going to change much in
the near future (due to my finals awaiting me). But it's really exciting
to follow the current development, especially related to GDP. Special
kudos to Graham for his excellent work and coordination as well as to
all those involved!
Given that 2.12 doesn't seem to be too far away, I thought I'd try to
take this as an opportunity to pick up some loose ends that I was
working on half a year (or so) ago. I can't guarantee that I will get
any further than this email, but anyway ...
The first one is a stab at a new caesura glyph that has continuously
been requested on this list, according to the archives. In March (I
believe) I sent a patch to change it from the current curved shape to
two straight parallel slashes. The only problem seemed to be that the
corners didn't look very symmetrical (which by the way is also the case
with the existing noteheads.s[012]slash glyphs). Here is another patch
which attempts to correct this problem, together with a pdf sample.
Would that be suitable for inclusion?
Thanks and best regards,
Max
From 9fcc47f9099bb10532386a4fe3a4b2ec764187af Mon Sep 17 00:00:00 2001
From: Maximilian Albert [EMAIL PROTECTED]
Date: Sun, 30 Sep 2007 14:50:17 +0200
Subject: [PATCH] New caesura glyph
---
mf/feta-schrift.mf | 74 ++-
1 files changed, 38 insertions(+), 36 deletions(-)
diff --git a/mf/feta-schrift.mf b/mf/feta-schrift.mf
index 10eebb5..0d5b5bf 100644
--- a/mf/feta-schrift.mf
+++ b/mf/feta-schrift.mf
@@ -1445,63 +1445,65 @@ fet_endchar;
input feta-slag;
-% railroad tracks.
%
-% I actually have no clue how they should look, so we use a slightly curvy
-% and tapered shape.
+% railroad tracks.
+% (We now use two parallel slashes instead of the former curved shape.)
%
fet_beginchar (Caesura, caesura);
- save slant, space_between, clearance;
- save alpha, pat;
- save botthick, topthick;
- save krom;
+ save slant, space_between, clearance, height;
+ save thick, upslant, center, factor, pat;
path pat;
+ pair upslant, center;
- botthick = 1.5 linethickness;
- topthick = 2.5 linethickness;
-
- pickup pencircle scaled botthick;
+ slant = 2.0;
+ thick = 2.88 linethickness;
- slant = 3.5;
- space_between# = 0.6 staff_space#;
+ space_between# = 0.56 staff_space#;
clearance# = 0.2 staff_space#;
- height# = 1.2 staff_space#;
set_char_box (0, 2.0 staff_space#,
- staff_space# - clearance#, height#);
- define_pixels (clearance, height);
+ staff_space# - clearance#, 1.2 staff_space#);
define_whole_pixels (space_between);
- bot y1 = -d;
- top y2 = h;
+ height = h+d;
- lft x1 = 0;
- x2 = (y2 - y1) / slant;
+ z1 = origin shifted (0,-d);
+ z2 = z1 shifted (thick,0);
+ z3 = z1 shifted (thick+height/slant,height);
+ z4 = z1 shifted (height/slant,height);
- krom = 10;
+ upslant = unitvector(z4-z1);
+ factor = 1.2 blot_diameter;
+ center = 0.5[z1,z3];
+
+ z1a = z1 shifted (upslant*factor);
+ z1b = z1 shifted (right*factor);
+ z2a = z2 shifted (upslant*factor);
+ z2b = z2 shifted (left*factor);
- alpha = angle (z2 - z1);
- penpos1 (botthick, alpha - krom);
- penpos3 (botthick, alpha - krom + 90);
+ z3a = z1a rotatedabout (center,180);
+ z3b = z1b rotatedabout (center,180);
+ z4a = z2a rotatedabout (center,180);
+ z4b = z2b rotatedabout (center,180);
- penpos2 (topthick, alpha + krom);
- penpos4 (topthick, alpha + krom + 90);
+ z1c = 0.4[z1,0.6[z1a,z1b]];
+ z3c = z1c rotatedabout (center, 180);
- z3 = z1;
- z4 = z2;
+ z2c = 0.4[z2,0.5[z2a,z2b]];
+ z4c = z2c rotatedabout (center, 180);
- penlabels (1, 2, 3, 4);
+ pat = z1a{-upslant}...z1c...{right}z1b--
+ z2b{right}...z2c...{upslant}z2a--
+ z3a{upslant}...z3c...{left}z3b--
+ z4b{left}...z4c...{-upslant}z4a--cycle;
- pat := z3r{(z1r - z1l)}
- .. z4r{z2r-z2l}
- .. z2r{z4l-z4r}
- .. z4l{z2l-z2r}
- .. z3l{z1l-z1r}
- .. z1l{z3r-z3l}
- .. cycle;
fill pat;
fill pat shifted (space_between, 0);
+
+ labels(range 1 thru 4);
+ labels(1a,1b,2a,2b,3a,3b,4a,4b);
+ labels(1c,2c,3c,4c);
fet_endchar;
--
1.5.3.1
caesura.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Users using unstable
Arvid Grøtting schrieb: Graham Percival gpermus at gmail.com writes: [...] I think we only have a dozen serious users who track unstable. Considering the high quality unstable gives, I'd guess the number is higher, but what do I know. Anyway. Users of unstable LilyPond please raise a hand: *raiseshandtoo* Although I don't do any 'professional' typesetting (only for my own fun or for my vocal groups), and my last piece was quite a while ago - so I don't know if I count as a 'serious' user in Graham's sense. :) But when I get around to it, I normally use unstable. Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New notehead (accent)
Werner LEMBERG schrieb:
If there are any objections or anyone would like further changes,
please tell me so.
Just two things regarding your coding style:
. Please use tabs consistently; it sees that some lines use 8
spaces, other lines a tab.
. Stay within the 80 character limit per line if possible.
Thanks for your opinion and your comments. You are of course right. I
don't know where the mixed spaces/tabs came from (maybe they are due to
some copying pasting, although I wonder why I didn't notice the
mixture), and exceeding the 80 character limit certainly was an
inattention of mine.
To avoid unnecessary hassle for the developers I have attached a
corrected version of the patch. Hope this helps.
Thanks again,
Max
From e7168eccc2bbadd8db6cd97b21a51c77c214b058 Mon Sep 17 00:00:00 2001
From: Maximilian Albert [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 12:22:23 +0200
Subject: [PATCH] New notehead (accent-shaped with centered stem) +
corresponding doc update
---
input/manual/note-head-style.ly |4 +
input/regression/note-head-style.ly |4 +
lily/include/note-head.hh |1 +
lily/note-head.cc | 29
mf/feta-bolletjes.mf| 126 +++
scm/define-grobs.scm|2 +-
scm/output-lib.scm |1 +
7 files changed, 166 insertions(+), 1 deletions(-)
diff --git a/input/manual/note-head-style.ly b/input/manual/note-head-style.ly
index c561eec..0759927 100644
--- a/input/manual/note-head-style.ly
+++ b/input/manual/note-head-style.ly
@@ -91,6 +91,10 @@ pattern =
\break
+ \override Staff.NoteHead #'style = #'accent
+ s1*0^\markup { accent }
+ \pattern
+
\override Staff.NoteHead #'style = #'slash
s1*0^\markup { slash }
\pattern
diff --git a/input/regression/note-head-style.ly
b/input/regression/note-head-style.ly
index c561eec..0759927 100644
--- a/input/regression/note-head-style.ly
+++ b/input/regression/note-head-style.ly
@@ -91,6 +91,10 @@ pattern =
\break
+ \override Staff.NoteHead #'style = #'accent
+ s1*0^\markup { accent }
+ \pattern
+
\override Staff.NoteHead #'style = #'slash
s1*0^\markup { slash }
\pattern
diff --git a/lily/include/note-head.hh b/lily/include/note-head.hh
index 2edeb1b..e15be8a 100644
--- a/lily/include/note-head.hh
+++ b/lily/include/note-head.hh
@@ -18,6 +18,7 @@ public:
DECLARE_SCHEME_CALLBACK (brew_ez_stencil, (SCM));
DECLARE_SCHEME_CALLBACK (stem_x_shift, (SCM));
DECLARE_SCHEME_CALLBACK (calc_stem_attachment, (SCM));
+ DECLARE_SCHEME_CALLBACK (y_offset_callback, (SCM));
DECLARE_GROB_INTERFACE();
static Real stem_attachment_coordinate (Grob *, Axis a);
diff --git a/lily/note-head.cc b/lily/note-head.cc
index c711f87..a8384b8 100644
--- a/lily/note-head.cc
+++ b/lily/note-head.cc
@@ -15,6 +15,7 @@
using namespace std;
#include directional-element-interface.hh
+#include staff-symbol-referencer.hh
#include font-interface.hh
#include international.hh
#include warn.hh
@@ -141,6 +142,34 @@ Note_head::calc_stem_attachment (SCM smob)
return ly_offset2scm (get_stem_attachment (fm, key));
}
+MAKE_SCHEME_CALLBACK (Note_head, y_offset_callback, 1);
+SCM
+Note_head::y_offset_callback (SCM smob)
+{
+ Grob *me = unsmob_grob (smob);
+ SCM style_scm = me-get_property (style);
+ double offset = scm_to_double (Staff_symbol_referencer::callback (smob));
+
+ if (!scm_is_symbol (style_scm))
+return scm_from_double (offset);
+
+ string style = string (ly_symbol2string (style_scm));
+ if (style != accent)
+return scm_from_double (offset);
+
+ double extra_offset;
+ if (scm_to_int (me-get_property (staff-position)) % 2 == 0) {
+Real linethickness = Staff_symbol_referencer::line_thickness (me);
+// The precise value of the following factor depends
+// on the parameters in mf/feta-bolletjes.mf
+extra_offset = - 127.0/60 * linethickness;
+
+ } else {
+extra_offset = 0.0;
+ }
+
+ return scm_from_double (offset + extra_offset);
+}
ADD_INTERFACE (Note_head,
Note head,
diff --git a/mf/feta-bolletjes.mf b/mf/feta-bolletjes.mf
index b45222e..c1a011f 100644
--- a/mf/feta-bolletjes.mf
+++ b/mf/feta-bolletjes.mf
@@ -967,6 +967,132 @@ fi;
%
+% Accent-shaped notehead
+%
+
+def draw_accent_notehead (expr width_factor, clearing_factor,
+ ratio, upper_th, thick_factor, upstem) =
+begingroup;
+save upper_thickness, lower_thickness, clearing;
+save ww, hh;
+save roundness, thinning_start, thinning_factor;
+save se, ne, up_dist, down_dist;
+pair se, ne, up_dist, down_dist;
+save se_new, up_dist_new;
+pair se_new, up_dist_new;
+
+hh# := staff_space# + stafflinethickness# * upper_th;
+ww# := hh# * width_factor;
+set_char_box (0, ww#, hh#, 0);
+define_pixels (ww, hh);
+
+upper_thickness = stafflinethickness * upper_th
Re: New notehead (accent)
Maximilian Albert schrieb:
Attached are two further examples I have prepared to attenuate the
effect of 'smearing' Werner mentioned. In the first file the inner part
of the accent is drawn slimmer, as suggested. But this makes the right
part of the upper leg quite narrow. Whence the second file, where that
part is a bit wider. Opinions?
Well, I haven't heard any further comments, so I thought I'd just
provide a patch for the second option (including doc update). If there
are any objections or anyone would like further changes, please tell me so.
Cheers,
Max
From 3240a4a287324e11808d7c01b52a183181c2bd1e Mon Sep 17 00:00:00 2001
From: Maximilian Albert [EMAIL PROTECTED]
Date: Tue, 10 Apr 2007 18:15:26 +0200
Subject: [PATCH] New notehead (accent-shaped with centered stem) +
corresponding doc update
---
input/manual/note-head-style.ly |4 +
input/regression/note-head-style.ly |4 +
lily/include/note-head.hh |1 +
lily/note-head.cc | 28
mf/feta-bolletjes.mf| 119 +++
scm/define-grobs.scm|2 +-
scm/output-lib.scm |1 +
7 files changed, 158 insertions(+), 1 deletions(-)
diff --git a/input/manual/note-head-style.ly b/input/manual/note-head-style.ly
index c561eec..0759927 100644
--- a/input/manual/note-head-style.ly
+++ b/input/manual/note-head-style.ly
@@ -91,6 +91,10 @@ pattern =
\break
+ \override Staff.NoteHead #'style = #'accent
+ s1*0^\markup { accent }
+ \pattern
+
\override Staff.NoteHead #'style = #'slash
s1*0^\markup { slash }
\pattern
diff --git a/input/regression/note-head-style.ly
b/input/regression/note-head-style.ly
index c561eec..0759927 100644
--- a/input/regression/note-head-style.ly
+++ b/input/regression/note-head-style.ly
@@ -91,6 +91,10 @@ pattern =
\break
+ \override Staff.NoteHead #'style = #'accent
+ s1*0^\markup { accent }
+ \pattern
+
\override Staff.NoteHead #'style = #'slash
s1*0^\markup { slash }
\pattern
diff --git a/lily/include/note-head.hh b/lily/include/note-head.hh
index 2edeb1b..e15be8a 100644
--- a/lily/include/note-head.hh
+++ b/lily/include/note-head.hh
@@ -18,6 +18,7 @@ public:
DECLARE_SCHEME_CALLBACK (brew_ez_stencil, (SCM));
DECLARE_SCHEME_CALLBACK (stem_x_shift, (SCM));
DECLARE_SCHEME_CALLBACK (calc_stem_attachment, (SCM));
+ DECLARE_SCHEME_CALLBACK (y_offset_callback, (SCM));
DECLARE_GROB_INTERFACE();
static Real stem_attachment_coordinate (Grob *, Axis a);
diff --git a/lily/note-head.cc b/lily/note-head.cc
index c711f87..18d051e 100644
--- a/lily/note-head.cc
+++ b/lily/note-head.cc
@@ -15,6 +15,7 @@
using namespace std;
#include directional-element-interface.hh
+#include staff-symbol-referencer.hh
#include font-interface.hh
#include international.hh
#include warn.hh
@@ -141,6 +142,33 @@ Note_head::calc_stem_attachment (SCM smob)
return ly_offset2scm (get_stem_attachment (fm, key));
}
+MAKE_SCHEME_CALLBACK (Note_head, y_offset_callback, 1);
+SCM
+Note_head::y_offset_callback (SCM smob)
+{
+ Grob *me = unsmob_grob (smob);
+ SCM style_scm = me-get_property (style);
+ double offset = scm_to_double (Staff_symbol_referencer::callback (smob));
+
+ if (!scm_is_symbol (style_scm))
+return scm_from_double (offset);
+
+ string style = string (ly_symbol2string (style_scm));
+ if (style != accent)
+return scm_from_double (offset);
+
+ double extra_offset;
+ if (scm_to_int (me-get_property (staff-position)) % 2 == 0) {
+Real linethickness = Staff_symbol_referencer::line_thickness (me);
+// The precise value of the following factor depends on the parameters in
mf/feta-bolletjes.mf
+extra_offset = - 127.0/60 * linethickness;
+
+ } else {
+extra_offset = 0.0;
+ }
+
+ return scm_from_double (offset + extra_offset);
+}
ADD_INTERFACE (Note_head,
Note head,
diff --git a/mf/feta-bolletjes.mf b/mf/feta-bolletjes.mf
index b45222e..3fe725f 100644
--- a/mf/feta-bolletjes.mf
+++ b/mf/feta-bolletjes.mf
@@ -967,6 +967,125 @@ fi;
%
+% Accent-shaped notehead
+%
+
+def draw_accent_notehead (expr width_factor, clearing_factor, ratio, upper_th,
thick_factor, upstem) =
+begingroup;
+save upper_thickness, lower_thickness, clearing;
+save ww, hh;
+save roundness, thinning_start, thinning_factor;
+save se, ne, up_dist, down_dist;
+pair se, ne, up_dist, down_dist;
+ save see, up_distt;
+ pair see, up_distt;
+
+hh# := staff_space# + stafflinethickness# * upper_th;
+ww# := hh# * width_factor;
+set_char_box (0, ww#, hh#, 0);
+define_pixels (ww, hh);
+
+upper_thickness = stafflinethickness * upper_th;
+lower_thickness = stafflinethickness * upper_th * thick_factor;
+clearing = stafflinethickness * clearing_factor;
+roundness = stafflinethickness * 0.5;
+ thinning_start = 0.6
Re: Patch for yet again new noteheads (triangle-shaped)
The gap was an attempt to neutralize that optical effect, but perhaps it doesn't quite work. The gap will simply be blackened by lower resolutions... True. And you are probably right, it doesn't really look that good. What other strategies are there? Well, as Han-Wen said: Make the triangle shape slightly bigger vertically: In case the triangle sits on a note line, this isn't visible. In the other case, the broadened base should correct the optical size. Attached is an attempt to implement this suggestion. It is essentially what I had tried before introducing the gap, except for the slightly larger vertical extent. I'm not sure if Han-Wen meant to make the tip simply enter the staffline (so that it is still covered) or protrude through it, so I tried it both. (Sorry for cluttering the mailing list with the *.pdf files; I hope the sizes aren't too big). I'm not entirely convinced, though (but my opinion is not really relevant in this matter, since there are much more experienced people on this list). The overshooting in the second file is IMHO already fairly large when seen from close-by, but barely visible from further apart, probably also at low resolutions. Should it be even larger? Also, at first I thought that the increased size gives the glyph a slightly awkward look, but that feeling disappeared when I got used to it. ;) And still, I can't help it: At least to me it seems that when the triangle base touches a staffline, the line looks as if it covered part of the triangle's shape. In both files, this makes the corresponding triangle appear larger - as if its height were extended by precisely one stafflinethickness. Or am I wrong? Can this problem be overcome at all? BTW, the shape of the glyph is taken from the 'do' notehead of the solfa style - only with centered stem and flipped vertically if required. So the same comment applies if someone uses the 'do' notehead between stafflines. But if you say that you are satisfied with the shape and positioning as it is, then I certainly won't object (especially since I don't see a way to make the 'problem' disappear - if it is one at all). Further comments are welcome. Thanks for your time and your opinions, Max triangle_inshooting.pdf Description: Adobe PDF document triangle_overshooting.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New notehead (accent)
Han-Wen Nienhuys schrieb: Regarding the accents, I'm a bit confused still. Why don't you simply plug in the existing accent symbol by setting a couple of callbacks ? Well, we were aiming for a kind of 'calligraphic' look. That is, if possible the lower 'leg' of the accent should be somewhat thicker than the upper one. So the existing function draw_accent would have to be adapted anyway. Also, it draws circular 'caps' for the vertices, which IMHO looks ugly when the lines of the accent are much thicker than in the glyphs for which the function is currently used (such as 'sforzato', 'espressivo', 'upbow', etc.) - example on request. I personally liked the approach taken in the 'marcato' glyph much better, where the ends of the legs are essentially flat, with slightly rounded corners. That's why I used that one as a template. Is this a problem? Should I have done it differently? Attached are two further examples I have prepared to attenuate the effect of 'smearing' Werner mentioned. In the first file the inner part of the accent is drawn slimmer, as suggested. But this makes the right part of the upper leg quite narrow. Whence the second file, where that part is a bit wider. Opinions? As far as I can tell this takes away much of the ugliness at the inner angle for the accents that sit *on* stafflines. But I'm not sure if the slight bending of the edge is too visible (especially on the lower leg) for the accents *between* stafflines. What do you think? Cheers, Max accent1.pdf Description: Adobe PDF document accent2.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New notehead (accent)
Werner LEMBERG schrieb: Everything looks very nice! However, I suggest that the inner side of the right part of the glyph is drawn a bit slimmer, similar to the `' `sforzato' glyph, which has an optical correction to avoid excessive `smearing'. Thanks for the hint, I hadn't noticed this correction in the sforzato glyph, and most of the time I was looking at magnified versions of the glyphs where the effect of smearing is much less obvious, if at all visible. I attached two corrected pdf versions. In the first one the correction is rather small. I like it a bit better, but I'm again judging from the magnified view. In print the second version may prove more appealing. I would appreciate your input if this is what you had in mind or if you have any further suggestions for enhancement. I will then provide the corresponding patch. Thanks, Max accent_corrected1.pdf Description: Adobe PDF document accent_corrected2.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New notehead (accent)
Werner LEMBERG wrote: Everything looks very nice! However, I suggest that the inner side of the right part of the glyph is drawn a bit slimmer, similar to the `' `sforzato' glyph, which has an optical correction to avoid excessive `smearing'. BTW, the 'marcato' glyph (which I used as guideline for the design) doesn't have this correction. Is this intended? Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Patch for yet again new noteheads (triangle-shaped)
Hi everyone,
here are patches (contain metafont source and doc additions) for the
other kind of notehead requested by Trevor and Jamie some time ago. They
implement two slightly differing styles, namely 'outward-pointing' and
'inward-pointing' triangles. This means that the tips of the triangles
either point away from the stem or towards the stem. See the attached
*.pdf file for illustration.
Comments are welcome. If there is no objection it would be great if they
could be included in the next development release.
Thanks a lot,
Max
From a173abd5a73de8b97f8aea6fc8342857dda993ac Mon Sep 17 00:00:00 2001
From: Maximilian Albert [EMAIL PROTECTED]
Date: Tue, 3 Apr 2007 21:27:55 +0200
Subject: [PATCH] New noteheads: Two styles of triangles ('outward'-pointing and
'inward'-pointing) with centered stem
---
mf/feta-bolletjes.mf | 107 ++
scm/output-lib.scm |2 +
2 files changed, 109 insertions(+), 0 deletions(-)
diff --git a/mf/feta-bolletjes.mf b/mf/feta-bolletjes.mf
index 36abfcf..7bee94a 100644
--- a/mf/feta-bolletjes.mf
+++ b/mf/feta-bolletjes.mf
@@ -1484,6 +1484,113 @@ fet_beginchar (Quart down tihead, d2ti);
fet_endchar;
+
+%
+% Downward pointing triangle with centered stem (the shape is
+% the same as for the 'do' notehead in the solfa section, albeit
+% a bit smaller; for drawing we use an adapted version of the
+% function draw_do_head).
+%
+
+def draw_dreieck (expr width_factor, dir, outward_inward) =
+ save p_down, p_up;
+ save left_dist_up, right_dist_up;
+ save left_dist_down, right_dist_down;
+ save clearing_factor;
+ path p_down, p_up;
+ pair left_dist_up, right_dist_up;
+ pair left_dist_down, right_dist_down;
+
+ clearing_factor := 0.5 stafflinethickness# / solfa_noteheight#;
+
+ set_char_box (0, width_factor * solfa_base_notewidth#,
+ 0.5 solfa_noteheight#, 0.5 solfa_noteheight#);
+
+ pickup pencircle scaled solfa_pen_thick;
+
+ bot y1 = -d + 1.5 clearing_factor * (h + d);
+ y1 = y2;
+ lft x1 = 0 + clearing_factor * w;
+ rt x2 = w - clearing_factor * w;
+ top y3 = h - 0.5 clearing_factor * (h + d);
+ x3 =.5 [x1, x2];
+
+ left_dist_up = (unitvector (z3 - z1) rotated 90) * 0.5 solfa_pen_thick;
+ right_dist_up = (unitvector (z2 - z3) rotated 90) * 0.5 solfa_pen_thick;
+
+ p_up := bot z1
+ -- bot z2{right}
+ .. rt z2{up}
+ .. (z2 + right_dist_up){z3 - z2}
+ -- (z3 + right_dist_up){z3 - z2}
+ .. top z3{left}
+ .. (z3 + left_dist_up){z1 - z3}
+ -- (z1 + left_dist_up){z1 - z3}
+ .. lft z1{down}
+ .. {right}cycle;
+
+ z4 = (0, (h - d)/2);
+ z5 = (w, (h - d)/2);
+
+ z6 = z1 reflectedabout (z4, z5);
+ z7 = z2 reflectedabout (z4, z5);
+ z8 = z3 reflectedabout (z4, z5);
+
+ right_dist_down = (unitvector (z8 - z7) rotated 90) * 0.5
solfa_pen_thick;
+ left_dist_down = (unitvector (z6 - z8) rotated 90) * 0.5
solfa_pen_thick;
+
+ p_down := top z6
+ -- top z7{right}
+ .. rt z7{down}
+ .. (z7 + right_dist_down){z8 - z7}
+ -- (z8 + right_dist_down){z8 - z7}
+ .. bot z8{left}
+ .. (z8 + left_dist_down){z6 - z8}
+ -- (z6 + left_dist_down){z6 - z8}
+ .. lft z6{up}
+ .. {right}cycle;
+
+ if dir = outward_inward:
+ fill p_down;
+ labels (6, 7, 8);
+ else:
+ fill p_up;
+ labels (1, 2, 3);
+ fi;
+ labels (4, 5);
+
+ if (dir = +1) and (outward_inward = +1):
+ z9 = top 0.5[z6, z7] shifted (stemthickness/2 ,
-stemthickness/2);
+ elseif (dir = +1) and (outward_inward = -1):
+ z9 = z3 shifted (stemthickness/2, 0 - stemthickness/2);
+ elseif (dir = -1) and (outward_inward = +1):
+ z9 = z3 shifted (stemthickness/2, 0 - stemthickness/2);
+ elseif (dir = -1) and (outward_inward = -1):
+ z9 = bot 0.5[z6, z7] shifted (stemthickness/2 ,
+stemthickness/2);
+ fi;
+ charwx := x9/hppp;
+ charwy := y9/hppp;
+
+ labels (9);
+enddef;
+
+fet_beginchar (Outward pointing triangle (upstem), u2dreieckout);
+ draw_dreieck (solfa_quarter_width, +1, +1);
+fet_endchar;
+
+fet_beginchar (Outward pointing triangle (downstem), d2dreieckout);
+ draw_dreieck (solfa_quarter_width, -1, +1);
+fet_endchar;
+
+fet_beginchar (Inward pointing triangle (upstem), u2dreieckin);
+ draw_dreieck (solfa_quarter_width, +1, -1);
+fet_endchar;
+
+fet_beginchar (Inward pointing triangle (downstem), d2dreieckin);
+ draw_dreieck (solfa_quarter_width, -1, -1);
+fet_endchar;
+
+
fet_endgroup (noteheads);
diff --git a/scm/output
New notehead (accent)
Hi everybody,
here is a patch for a new accent-shaped notehead, as requested by Jamie
and Trevor on this list a while ago. An example of what it looks like is
attached. Would it be possibe to include this in the next development
release? The second patch is to update the docs.
Thanks,
Max
From b2f1b6e0afb63329555a6632f413f05cfe6c08e6 Mon Sep 17 00:00:00 2001
From: Maximilian Albert [EMAIL PROTECTED]
Date: Sun, 1 Apr 2007 00:21:20 +0200
Subject: [PATCH] New accent-shaped notehead
---
lily/include/note-head.hh |1 +
lily/note-head.cc | 28 +
mf/feta-bolletjes.mf | 97 +
scm/define-grobs.scm |2 +-
scm/output-lib.scm|1 +
5 files changed, 128 insertions(+), 1 deletions(-)
diff --git a/lily/include/note-head.hh b/lily/include/note-head.hh
index 0891b7d..8d39a2d 100644
--- a/lily/include/note-head.hh
+++ b/lily/include/note-head.hh
@@ -24,6 +24,7 @@ public:
DECLARE_SCHEME_CALLBACK (brew_ez_stencil, (SCM));
DECLARE_SCHEME_CALLBACK (stem_x_shift, (SCM));
DECLARE_SCHEME_CALLBACK (calc_stem_attachment, (SCM));
+ DECLARE_SCHEME_CALLBACK (y_offset_callback, (SCM));
DECLARE_GROB_INTERFACE();
static Real stem_attachment_coordinate (Grob *, Axis a);
static int get_balltype (Grob *);
diff --git a/lily/note-head.cc b/lily/note-head.cc
index c711f87..18d051e 100644
--- a/lily/note-head.cc
+++ b/lily/note-head.cc
@@ -15,6 +15,7 @@
using namespace std;
#include directional-element-interface.hh
+#include staff-symbol-referencer.hh
#include font-interface.hh
#include international.hh
#include warn.hh
@@ -141,6 +142,33 @@ Note_head::calc_stem_attachment (SCM smob)
return ly_offset2scm (get_stem_attachment (fm, key));
}
+MAKE_SCHEME_CALLBACK (Note_head, y_offset_callback, 1);
+SCM
+Note_head::y_offset_callback (SCM smob)
+{
+ Grob *me = unsmob_grob (smob);
+ SCM style_scm = me-get_property (style);
+ double offset = scm_to_double (Staff_symbol_referencer::callback (smob));
+
+ if (!scm_is_symbol (style_scm))
+return scm_from_double (offset);
+
+ string style = string (ly_symbol2string (style_scm));
+ if (style != accent)
+return scm_from_double (offset);
+
+ double extra_offset;
+ if (scm_to_int (me-get_property (staff-position)) % 2 == 0) {
+Real linethickness = Staff_symbol_referencer::line_thickness (me);
+// The precise value of the following factor depends on the parameters in
mf/feta-bolletjes.mf
+extra_offset = - 127.0/60 * linethickness;
+
+ } else {
+extra_offset = 0.0;
+ }
+
+ return scm_from_double (offset + extra_offset);
+}
ADD_INTERFACE (Note_head,
Note head,
diff --git a/mf/feta-bolletjes.mf b/mf/feta-bolletjes.mf
index 36abfcf..9652d3b 100644
--- a/mf/feta-bolletjes.mf
+++ b/mf/feta-bolletjes.mf
@@ -970,6 +970,103 @@ fi;
%
+% Accent-shaped notehead
+%
+
+def draw_accent_notehead (expr width_factor, clearing_factor, ratio, upper_th,
thick_factor, upstem) =
+begingroup;
+save upper_thickness, lower_thickness, clearing;
+save ww, hh;
+save roundness;
+save se, ne, up_dist, down_dist;
+pair se, ne, up_dist, down_dist;
+
+hh# := staff_space# + stafflinethickness# * upper_th;
+ww# := hh# * width_factor;
+set_char_box (0, ww#, hh#, 0);
+define_pixels (ww, hh);
+
+upper_thickness = stafflinethickness * upper_th;
+lower_thickness = stafflinethickness * upper_th * thick_factor;
+clearing = stafflinethickness * clearing_factor;
+roundness = stafflinethickness * 0.5;
+
+
+pickup pencircle scaled roundness;
+
+lft x1 = lft x3 = lft x4 = lft x6 = 0;
+rt x2 = ww;
+bot y1 = 0;
+top y6 - bot y1 = lower_thickness;
+top y3 - bot y4 = upper_thickness;
+y2 - bot y1 = ratio * (top y3 - bot y1);
+
+bot y4 - clearing = staff_space;
+
+z5 - z4 = whatever * (z2 - z3);
+z5 - z6 = whatever * (z2 - z1);
+
+se = unitvector (z2 - z3);
+ne = unitvector (z2 - z1);
+
+up_dist = (se rotated 90) * 0.5 roundness;
+down_dist = (ne rotated (-90)) * 0.5 roundness;
+
+z5a = whatever[z4 - up_dist, z5 - up_dist] = whatever[z6 - down_dist,
z5 - down_dist];
+
+fill lft z1{down}
+ .. (z1 + down_dist){ne}
+ -- (z2 + down_dist){ne}
+ .. (z2 + up_dist){-se}
+ -- (z3 + up_dist){-se}
+ .. lft z3{down}
+ -- lft z4{down}
+ .. (z4 - up_dist){se}
+ -- z5a
+ -- (z6 - down_dist){-ne}
+ .. lft z6{down}
+ --cycle;
+
+
+% stem attachment adjustments
+if upstem:
+ z7 = 0.5[z2,z3];
+z7a = whatever[z4,z5];
+z7a = (x7 - stemthickness/2, whatever);
+z7b = z7a shifted (stemthickness,0);
+% the shift
New noteheads and other contributions (was Re: Downward pointing triangle (was Re: Sponsorhip of new note heads))
Kevin Dalley schrieb: Jamie, I have a downward-pointing triangle now, which is the reverse of the do. However, it isn't exactly what you want. It is isosceles, though I don't think that it is equilateral. I think Trevor mentioned a while ago that (one of) the existing triangle(s) would perfectly suit his needs if it was flipped and the stem centered. Some time ago I contacted Jamie and Trevor to work on the accent-shaped notehead they had requested, which is also supposed to have a centered stem. I think that we have come up with a good solution. There only remained a tiny problem with the attachment of downward-pointing stems, which I was not able to address in the meantime due to extremely heavy workload. But I hope to sort it all out _very_ soon. Then it should be only a matter of another day or so to provide a triangle with centered stem, too. FYI (a bit off-topic): I also managed to come up with a nice version (IMHO at least :)) of arrowed quartertone accidentals, which I will also submit as soon as I have the time to clean up the files and to resolve a slight problem with spacing. Finally, I believe, some people are still waiting for the new caesura glyph. Sorry for the delay, I will also submit it soon (but to some extent I screwed up my metafont file in an attempt to implement a suggestion of Han-Wen's; I will have to deal with that first). Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
New caesura
Hi all, a couple of days ago Paul Scott asked about the implementation of a new caesura (railroad tracks) glyph. After a few tries and corrections we ended up with the attached example. I guess that this might be of interest to quite a few other users, too. If this is true I can easily send a patch. However, I seem to infer from a whole bunch of earlier discussions on the same subject that Han-Wen and Jan would rather prefer to stick to the current version of the glyph until someone manages to find hand-engraved examples of it in older German music editions on which the design can be based. So I thought I'd just ask if they are interested in trying out this first approximation to an improved version. I would like to have a look in our local musicological library to see if I can find one or two samples which meet their quality standards so that we don't have to rely entirely on our own sense of aesthetics. But it may take at least a week or two before I will find the time. Can anyone who frequently uses this glyph give a hint in which type of music it occurs most often? Thanks and cheers, Max caesura.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
