problems with octavation dashes
http://code.google.com/p/lilypond/issues/detail?id=170 Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: another skyline problem
> slurs and dynamic texts are involved in collision resolution; check > the avoid-slur properties on DynamicText and DynamicLineSpanner. Indeed, this did the trick: f1 \once \override DynamicText #'X-offset = #'-5.0 \once \override DynamicLineSpanner #'Y-offset = #'-5.0 \once \override DynamicLineSpanner #'outside-staff-priority = ##f \once \override DynamicLineSpanner #'avoid-slur = ##f c1\ff( | f1) | Thanks for the help. Quite complicated IMHO... However, I get a warning Ignoring grob for slur. avoid-slur not set? which isn't appropriate in this case since I explicitly override the property. Can you disable it (at least in such situations)? I wonder whether it makes sense to introduce a property, say, `offset', which is the same as `extra-offset' but which actually takes part in formatting. Due to the central role of X- and Y-offset it's probably a bad idea to directly manipulate them. We would have a workflow similar to this: . compute X-offset and Y-offset of the grob as usual . apply `offset' . finish formatting . apply `extra-offset' The `offset' property would be quite convenient (and predictable) for the end user. However, my point of view is quite naive since I lack knowledge of lilypond internals. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: dejavu kievan notation message
Hi. Just got a lilypond-devel email with first message about kievan notes in it again. I'm not sure how that happened, but I'm sorry for the repeat. Fr. P ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: another skyline problem
Werner LEMBERG escreveu: >>> Change #'Y-offset on the DynamicLineSpanner too. >> Yes, I got the same idea. However, I would prefer that Y-offset >> were relative to the original position instead of being relative to >> the vertical staff center. However, I can live with that. > > Hmm. The code below makes me believe that there is a bug somewhere... slursand dynamic texts are involved in collision resolution ; check the avoid-slur properties on DynamicText and DynamicLineSpanner. Slur collision resolution overrides Y-offset. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: another skyline problem
Werner LEMBERG escreveu:
>>> Well, it still doesn't work: I want to change Y-offset!
>>>
>>> {
>>> \override DynamicText #'Y-offset = #5.0
>>> \once \override DynamicLineSpanner #'outside-staff-priority = ##f
>>> c2\ff
>>> }
>> Change #'Y-offset on the DynamicLineSpanner too.
>
> Yes, I got the same idea. However, I would prefer that Y-offset were
> relative to the original position instead of being relative to the
> vertical staff center. However, I can live with that.
>
>> Did overriding DynamicText #'Y-offset work on earlier versions?
>
> I don't know. Just recently I've started to replace all
> `extra-offset's with X- and Y-offsets so that they work with
> skylining.
Y-offset always is relative to the Y parent of the grob. This has
always been the case, and won't change; [YX]-offset aren't just a
convenience properties for tweaking, but they're the heart of all
grob-placement routines.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation translation: first patch
John Mandereau escreveu:
> Since the translated documentation itself is ready to be released, merge
> and apply your trick as you like.
>
> So, I have a question about merging branches, since I may need to do it
> sooner or later. IIRC, Han-Wen has once told Joe Neeman on the list that
> it was better to merge with git-rebase. Let's take a concrete example:
> suppose you want to merge fr-doc (I mean, a local branch with exactly
> matches fr-doc on git.sv.gnu.org) onto stable/2.10, and suppose your
> current checked out branch is fr-doc. If I understand correctly, the
> command to issue would be
>
> git-rebase stable/2.10
>
> right? And then I guess the resulting branch may be pushed to
> stable/2.10, is it ok?
Yes, that looks right.
> Another example: once fr-doc has been merged, suppose you want to work
> on fr-doc again, based on the current stable/2.10 branch; is the same
> command above the best way to do it?
Not necessarily. You might want to use the stable/2.10 as a starting point,
and branch off fr-doc again, either by removing the old fr-doc again, or
by fast-forwarding fr-doc to the current stable/2.10.
> Even if I'm not ready to commit anything, I can tell you a bit about my
> plans. I'm working on hardlinking most files from out-www directories
> to /out-www/{offline,online}-root, because copying them twice (for the
yes, please do. Copies are only necessary if you intend to modify the files.
> Btw, you haven't answered my proposition for language selection in
> offline docs: is it OK to copy every foo.html file that is not
> translated in LANG to foo.LANG.html, and then replacing *.html hrefs
> with *.LANG.html in all (i.e. real translations and copies of the
> English docs) *.LANG.html files?
Yes, I think there is no other way.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
There no ligatures in Kievan notation (was Re: Kievan "hatchet" notes for lilypond?)
On Thursday 30 November 2006 06:01, you wrote: > Hello, Panteleimon! Hello, thank you for your response > I fear the task of fully implementing kievan chant notation is more than > just a question of adding thirteen glyphs. > recognize at least pes ligatures (those pairwise stacked rhombic glyphs) > and clivis ligatures (e.g. the third glyph in the last line of the long > example). Actually, those are not ligatures, and there are no ligatures at all in Kievan notation. The two stacked diamond-shapes you refer to are simply a half note. They refer to the space inbetween the two diamonds, in this case "mi" or b-natural. If the diamonds where in spaces, they would refer to the line in-between. The "squiggly-with-stem" and "double-diamond-with-stem" notes that also seem to take up several spaces are not ligatures either, just 16th notes. (By the way, the durations I cite are doubled by some transcribers in order to have a whole-note as the longest duration, but this gives an incorrect impression of the flow of the chant). > To me, the notation looks structurally quite similar to gothic > (also called "hufnagel") chant notation, though the glyphs are somewhat > different. I would be interested to know what notation looked like in Poland in the 1600's, to see if it has a parent for this style > Still, adding those glyphs that are not part of ligatures (sole note > heads, clefs, custos, accidentals, etc.) would be a good starting point > (any volunteers?). As I understand it, the only things necessary *besides* adding the glyphs would be: 1. Spacing according text syllable. This is the only way notes are spaced in this chant, as you can see. There is a small & even block of space between each textual syllable, all the notes whereof are equidistant and very close. %%%(This is part of what makes this notation better for Znamenny Chant, being closer in this regard to the neumatic origins and taking up less space for long, involved melismata. It looks ugly if you try to do it with round notes.)%%% My hope is that this can be accomplished simply making slurs invisible in the kievan-init.ly file | Slur #'transparent = ##t | and then convincing lilypond to put an appropriate block of space between syllables. At first I thought that this could be done with LyricSpace #'minimum-distance , but that would only work for short syllables. 2. Right now we can set shaped noteheads in LP like this: \set shapeNoteStyles = ##(fa # la fa # la mi) (or something like that). We'd have to do something similar but different in the init.ly for kievan, since several symbols (the quarter and the eight) have slightly different forms for lines and spaces. These differences are very important to the overall look of the music. Note that they differ not to according scale-position (like shapenotes) but according to whether they are on a line or space. That means that g,8 looks different from g8 Furthermore, the eigth note (block with long tail) has not two but *four* slightly different forms: two for stem-up and two for stem-down. I think that rest could be done just by thickening lines and such, except perhaps that the beams on the 16th notes (single beams) extend beyond the note-stems and half sort of blunt edges, but I'm sure that can be done without designing anything new, right? Thanks again for your response. I look forward to doing whatever I can to implement this feature. Sincerely, Monk Panteleimon Hermitage of the Holy Cross Wayne, WV USA [EMAIL PROTECTED] http://www.holycross-hermitage.com/ http://www.holycrosskliros.org/ PS. I have an adaption of a long chant like this example in which the sequence of notes is almost exactly as in the Slavonic original. I can post both if you like, so you how can see how simple it really is. > Greetings, > Juergen > > On Wed, 29 Nov 2006, Monk Panteleimon wrote: > > Hello, developers of Lilypond. > > > > I submitted to the lilypond-user list a queru regarding the possibilty of > > adding symbols for kievan chant notation to lilyponds "feta" font. > > I got no response, but thought I'd try the developers, specifically those > > involved with older notations. > > > > I have counted thirteen symbols that would need adding to lilypond's font > > (presumably as "noteheads," with their stems included, two "dots" and > > one "clef") in order to enable lilypond to imitate the Chant-books of the > > Russian Orthodox Church. I have no idea how to make such characters, or > > how to fit them into lilypond, so I'm asking this to be added as a > > sponsored feature. > > > > Being a monk I have no personal money, but if the lilypond-developers can > > give me an estimated cost of sponsorship for the addition of these > > symbols, then I believe that I may be able find several people interested > > enough to support the feature, even if they are not already > > lilypond-users. I am thinking of some Russian Chant enthusiasts and > > people already develop
Fwd: Kievan "hatchet" notes for lilypond?
Sorry for the repeat, but I didn't initially send this to the developer's list, just to certain developers. Since Juergen's reply went to the list I thought I'd better correct my omission. Second installment coming soon. Fr. P -- Forwarded Message -- Subject: Kievan "hatchet" notes for lilypond? Date: Wednesday 29 November 2006 21:58 From: Monk Panteleimon <[EMAIL PROTECTED]> To: "Han-Wen Nienhuys" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Hello, developers of Lilypond. I submitted to the lilypond-user list a queru regarding the possibilty of adding symbols for kievan chant notation to lilyponds "feta" font. I got no response, but thought I'd try the developers, specifically those involved with older notations. I have counted thirteen symbols that would need adding to lilypond's font (presumably as "noteheads," with their stems included, two "dots" and one "clef") in order to enable lilypond to imitate the Chant-books of the Russian Orthodox Church. I have no idea how to make such characters, or how to fit them into lilypond, so I'm asking this to be added as a sponsored feature. Being a monk I have no personal money, but if the lilypond-developers can give me an estimated cost of sponsorship for the addition of these symbols, then I believe that I may be able find several people interested enough to support the feature, even if they are not already lilypond-users. I am thinking of some Russian Chant enthusiasts and people already developing ways to digitally reproduce Russian Liturgical books. I have attached 2 images, one extracted from a pdf-scan of a Russian Chant book from 1909, another being someone's attempt to reproduce this using a ttf that is typed in to a word-processor. It should be obvious which is which. If you like I can point out the short-comings of the ttf version. I can also tell you what the symbols are and point you to some online explanations of this simple notation, although I would warn you that there are two practices of interpreting the durations of these notes, of which practices the less accurate is the more common. If for some reason you are adverse to adding these symbols to lilypond's vocabulary, please let me know. You can download complete books in kievan notation in .pdf from this page: http://www.seminaria.ru/raritet/quadsborn.htm Thank you for your time. Monk Panteleimon Hermitage of the Holy Cross Wayne, WV USA [EMAIL PROTECTED] http://www.holycross-hermitage.com/ http://www.holycrosskliros.org/ --- topo.png Description: PNG image toporki.png Description: PNG image ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
new vertical positioning question
Hello, I'm very excited about the new vertical collision avoiding code in Lily-2.11.0 - it's something I've been waiting from 2.2. version on (I had to always set vertical text-padding value manually) :). I have some question about its implementation and usage: 1) Does this patch removes text collisions with notes in the staff completely by itself? 2) Or should this be manually set in the source file (the outside-staff-priority line, what does it do?)? 3) Are there any major downsides or tradeoffs about this feature (takes much longer to compile the document?)? Thank you! - Matevž Canorus development team http://canorus.berlios.de signature.asc Description: OpenPGP digital signature ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: another skyline problem
> > Change #'Y-offset on the DynamicLineSpanner too.
>
> Yes, I got the same idea. However, I would prefer that Y-offset
> were relative to the original position instead of being relative to
> the vertical staff center. However, I can live with that.
Hmm. The code below makes me believe that there is a bug somewhere...
Werner
==
\version "2.11.0"
\header { texidoc = "
A slur disables the @code{Y-offset} property of a
@code{DynamicLineSpanner}.
" }
\new Staff \with {
\remove Time_signature_engraver
}
{
f1 |
\once \override DynamicText #'X-offset = #'-5.0
\once \override DynamicLineSpanner #'Y-offset = #'-5.0
\once \override DynamicLineSpanner #'outside-staff-priority = ##f
c1\ff( | f1) |
\break
f1
\once \override DynamicText #'X-offset = #'-5.0
\once \override DynamicLineSpanner #'Y-offset = #'-5.0
\once \override DynamicLineSpanner #'outside-staff-priority = ##f
c1\ff | f1 |
}
\paper {
ragged-right = ##t
indent = #0
}
% EOF
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: another skyline problem
> > Well, it still doesn't work: I want to change Y-offset!
> >
> > {
> > \override DynamicText #'Y-offset = #5.0
> > \once \override DynamicLineSpanner #'outside-staff-priority = ##f
> > c2\ff
> > }
>
> Change #'Y-offset on the DynamicLineSpanner too.
Yes, I got the same idea. However, I would prefer that Y-offset were
relative to the original position instead of being relative to the
vertical staff center. However, I can live with that.
> Did overriding DynamicText #'Y-offset work on earlier versions?
I don't know. Just recently I've started to replace all
`extra-offset's with X- and Y-offsets so that they work with
skylining.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation translation: first patch
Jan Nieuwenhuizen wrote:
> Ok, thanks. We may want to merge then and use my silly
> build-html-docs-twice solution. Or was that reverted now, Han-Wen?
Since the translated documentation itself is ready to be released, merge
and apply your trick as you like.
So, I have a question about merging branches, since I may need to do it
sooner or later. IIRC, Han-Wen has once told Joe Neeman on the list that
it was better to merge with git-rebase. Let's take a concrete example:
suppose you want to merge fr-doc (I mean, a local branch with exactly
matches fr-doc on git.sv.gnu.org) onto stable/2.10, and suppose your
current checked out branch is fr-doc. If I understand correctly, the
command to issue would be
git-rebase stable/2.10
right? And then I guess the resulting branch may be pushed to
stable/2.10, is it ok?
Another example: once fr-doc has been merged, suppose you want to work
on fr-doc again, based on the current stable/2.10 branch; is the same
command above the best way to do it?
Even if I'm not ready to commit anything, I can tell you a bit about my
plans. I'm working on hardlinking most files from out-www directories
to /out-www/{offline,online}-root, because copying them twice (for the
both offline and online docs) would really be too slow. The HTML files
will be hardlinked to only one of the targets (e.g. the offline docs);
then add-html-footer.py will read the original from this target, and for
each target it will will process and write the page. I suppose this
solution minimizes disk I/O.
Note that I won't submit/push any patch for GUB, because I don't use it.
Btw, you haven't answered my proposition for language selection in
offline docs: is it OK to copy every foo.html file that is not
translated in LANG to foo.LANG.html, and then replacing *.html hrefs
with *.LANG.html in all (i.e. real translations and copies of the
English docs) *.LANG.html files?
Cheers,
--
John Mandereau <[EMAIL PROTECTED]>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: another skyline problem
On 12/7/06, Werner LEMBERG <[EMAIL PROTECTED]> wrote:
> That's right -- you need to override DynamicLineSpanner instead of
> DynamicText (see the following example).
Well, it still doesn't work: I want to change Y-offset!
{
\override DynamicText #'Y-offset = #5.0
\once \override DynamicLineSpanner #'outside-staff-priority = ##f
c2\ff
}
Change #'Y-offset on the DynamicLineSpanner too. I'm not 100% sure why yours
doesn't work but I think it's something on the lines of:
changing Y-offset of DynamicText changes the Y-extent of DynamicLineSpanner
(it used to be centred around 0, now it is centred around 5)
changing Y-extent of DynamicLineSpanner changes its Y-offset because it is
attached to something (the NoteHead?) according to side-position-interface
the combined changes to the Y-offsets cause DynamicText to be placed in
exactly the same position as before! If you could see the position of a
DynamicLineSpanner, I think you would see that your overrides caused its
Y-offset to be -5 from what it would have been originally.
By this hypothesis, at least, this behaviour is completely unrelated to
skyline spacing. Did overriding DynamicText #'Y-offset work on earlier
versions?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: another skyline problem
> That's right -- you need to override DynamicLineSpanner instead of
> DynamicText (see the following example).
Well, it still doesn't work: I want to change Y-offset!
{
\override DynamicText #'Y-offset = #5.0
\once \override DynamicLineSpanner #'outside-staff-priority = ##f
c2\ff
}
\paper {
ragged-right = ##t
}
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning vertical skyline order
Joe Neeman wrote: Your assumption is correct. The grobs with low priority (maybe it should be the other way around?) are positioned first. Once they are in place, the skylines are recalculated to include them and the remaining grobs are positioned. Grobs where outside-staff-priority is not a number are positioned before any of the skyline stuff is done. Regarding the docs, I am happy to write a short section, but I also have no idea where to put it. Let's make a "11.7 Skyline spacing"; just put everything in there. At the end of Dec I'll make a quick round of overall editing, rearranging (if necessary), and adding to the newbie docs in chapter 4. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning vertical skyline order
On 12/7/06, Werner LEMBERG <[EMAIL PROTECTED]> wrote: > >> well, it is using a priority field, which can have multiple values > >> for a single grob type. > > > > Aah, if I understand you correctly, I can write > > > > > >\override foo #'outside-staff-priority = #1 > >\override bar #'outside-staff-priority = #2 > >\override foo #'outside-staff-priority = #3 > > > > right? This should be documented. > > Just to avoid any confusion, somebody else is going to document > this, right? I don't know where this info should go. Well, I haven't received an answer w.r.t. my assumption (I think that it's wrong -- I have no idea what a priority field is actually :-) Your assumption is correct. The grobs with low priority (maybe it should be the other way around?) are positioned first. Once they are in place, the skylines are recalculated to include them and the remaining grobs are positioned. Grobs where outside-staff-priority is not a number are positioned before any of the skyline stuff is done. Regarding the docs, I am happy to write a short section, but I also have no idea where to put it. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: another skyline problem
On 12/7/06, Werner LEMBERG <[EMAIL PROTECTED]> wrote:
> > > If a user wants the symbol to be positioned at an absolute
> > > offset from its Y-parent, they can just set
> > > outside-staff-position to () in addition to setting Y-offset.
>
> Sorry, outside-staff-priority, not outside-staff-position.
This doesn't work. I tried
\once \override DynamicText #'outside-staff-priority = ##f
and
\once \override DynamicText #'outside-staff-priority = #'()
in my example recently sent to the list. Both have no effect.
That's right -- you need to override DynamicLineSpanner instead of
DynamicText (see the following example). The reason is that every
DynamicText is wrapped in a DynamicLineSpanner and the Staff's
VerticalAxisGroup only sees the DynamicLineSpanner, not the DynamicText.
It's a little unnatural, but I don't see another way to implement it.
\version "2.11.1"
{
\override DynamicText #'X-offset = #'-5.0
c2
c''\ff
c2
\once \override DynamicText #'outside-staff-priority = ##f
c''\ff
c2
\once \override DynamicLineSpanner #'outside-staff-priority = ##f
c''\ff
}
\paper {
ragged-right = ##t
}
skyline.preview.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: exact command for git push
Han-Wen Nienhuys wrote: ssh+git://[EMAIL PROTECTED]/srv/git/lilypond.git/ Yay, it worked! Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: exact command for git push
Graham Percival escreveu: > Mats Bengtsson wrote: >> Try something like >> git push [EMAIL PROTECTED]/srv/git/lilypond.git > > Nope, sorry. > > tsubasa:~/usr/src/lilypond gperciva$ git push > [EMAIL PROTECTED]/srv/git/lilypond.git > fatal: '[EMAIL PROTECTED]/srv/git/lilypond.git': unable to chdir > or not a git archive > fatal: unexpected EOF try ssh+git://[EMAIL PROTECTED]/srv/git/lilypond.git/ -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: exact command for git push
Mats Bengtsson wrote: Try something like git push [EMAIL PROTECTED]/srv/git/lilypond.git Nope, sorry. tsubasa:~/usr/src/lilypond gperciva$ git push [EMAIL PROTECTED]/srv/git/lilypond.git fatal: '[EMAIL PROTECTED]/srv/git/lilypond.git': unable to chdir or not a git archive fatal: unexpected EOF I'm guessing that the address is wrong, rather than my having screwed up git already. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
