Re: cropping problem
Graham Percival escreveu: > > How picky do you want to be about this? Examples with very little below > the staff will cut off the treble clef. See > > http://lilypond.org/doc/v2.11/Documentation/user/lilypond/Falls-and-doits > > for example. (missing 2 or 3 pixels at the bottom of the clef) > Probably 1 pixel, due to rounding. We used to have some padding , but maybe it got broken somewhere. -- 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: cropping problem
Han-Wen Nienhuys wrote: Werner LEMBERG escreveu: In section 5.1, `Moving objects', there are two examples using `extra-offset'. The second one has the `ritenuto' cropped partially. I wonder whether it is a generic problem (this is, lilypond can't compute the bounding box correctly if extra-offset is used) or whether it is a bug. In the former case, it should be documented. The EPS cropping code uses the same code for determining extents as the rest of lilypond does, so it doesn't notice extra-offset. How picky do you want to be about this? Examples with very little below the staff will cut off the treble clef. See http://lilypond.org/doc/v2.11/Documentation/user/lilypond/Falls-and-doits for example. (missing 2 or 3 pixels at the bottom of the clef) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: beams in tuplets
Werner LEMBERG escreveu: > > In case nobody objects, I'll file a bug report. > See #11. -- 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: cropping problem
Werner LEMBERG escreveu: > In section 5.1, `Moving objects', there are two examples using > `extra-offset'. The second one has the `ritenuto' cropped partially. > > I wonder whether it is a generic problem (this is, lilypond can't > compute the bounding box correctly if extra-offset is used) or whether > it is a bug. In the former case, it should be documented. The EPS cropping code uses the same code for determining extents as the rest of lilypond does, so it doesn't notice extra-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: section 5.1 `Moving objects' is out of date
Werner LEMBERG wrote: Due to the new collision avoidance algorithm, section 5.1, `Moving objects', is out of date. Similarly, in section 4.2, `Saving typing with identifiers and functions', the music function `padText' should be replaced with something more meaningful. Yes and no -- some collisions do still occur (see the bug tracker). I agree that it isn't as big a concern as it used to be, and that those sections could display more relevant tweaks. Oh wait; the "bad example" in 5.1 probably isn't a bad example at all now. Any suggestions for a quick fix? I can't do any major work for the next week. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Double hyphens in lyrics
Hi everyone!
In the following fragment of music, Lilypond prints a double hyphen on the last
note of the slur.
\version "2.10.0"
MusicaUno = \relative c'' {
e8. e16 e4 d8. d16 d8 d
d4( c) b b
}
Parole = \lyricmode {
Ky -- ri -- e, Ky -- ri -- e e --
lei -- son, e
}
\score {
<<
\new Voice = musicone { \MusicaUno }
\new Lyrics \lyricsto musicone \Parole
>>
\layout { }
}
It's a strange behaviour, in fact it happens with last note of slur being "c"
"f" or "g" but not with "e" "a" or "b".
Thank you for your reply.
Alberto
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal: second style for quartertone accidentals
Han-Wen Nienhuys wrote: Maximilian Albert escreveu: . So it seems that the use of "Accidental #'style" is deprecated and one should set the alteration-alist directly. (But changing the style property still works in v2.11.13, even if I don't know why, given that I couldn't find the code handling it). What is the reason for this? To me the former notation seems much more intuitive and easy to use. The recent microtone improvements needed a much more flexible way to map pitches onto symbols, and it seems superfluous to have two mechanisms for setting glyphname at the same time. It would be possible to have a mechanism to set the alist based on the style property, but I thought it would be overkill. Among other things I use Lilypond for, I transcribe Byzantine chant, which, rather than being based on quarter-tones, is based on sixth-tones. (Actually it's based on twelfth-tones, but it's rare to encounter an odd number of twelfths.) The arrow accidentals are perfect for this since a natural with a down-arrow can indicate a lowering by a sixth-tone, while a flat with an up-arrow can indicate a lowering by two sixth-tones, etc. I'd like to be able to translate this accurately into midi output. Is there already a mechanism in place for associating a microtonal relationship with the elements in an alteration-alist, or is this just a pipe dream? --Daniel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Questions regarding creation of a new glyph
Han-Wen,
thank you for your very fast and helpful answers!
A few more comments/questions/suggestions.
>> \once \override NoteHead #'style = #'harmonic
>> \once \override NoteHead #'glyph-name = #'"2harmonic"
>
> if you set glyph-name, style is no longer necessary.
That's what I thought beforehand, too. But leaving out 'style' results
in ordinary noteheads instead. See for yourself (picture of output
attached):
-- begin code --
%\version "2.11.12" %% same with v2.10.10
\layout { ragged-right = ##t }
{
% %This produces the harmonic notehead
\once \override NoteHead #'style = #'harmonic
\once \override NoteHead #'glyph-name = #'"0harmonic"
f'1
%% This yields an ordinary notehead
\once \override NoteHead #'glyph-name = #'"0harmonic"
f'1
}
-- end code --
Is this a bug?
>> [... how to control the choice of noteheads with note durations ...]
>>
> see scm/output-lib.scm, function note-head::calc-glyph-name.
Thanks, that's precisely what I was looking for.
>> [... Why do black diamonds of harmonic style not exist yet? ...]
>>
> AFAIK, they only exist in the open form, and Trevor's use of the black
> form is not canonical.
Taking this into account, I considered it best not to mess with the
existing harmonic style because it could cause confusion in users
familiar with them. Moreover, existing *.ly files would suddenly spit
out "wrong" or unexpected output. I therefore inserted two further style
definitions in scm/output-lib.scm which can serve as a replacement. To wit,
1) "harmonic-black", which prints noteheads with the same diamond
as the ordinary "harmonic" style, but all noteheads are filled
black.
2) "harmonic-mixed", which prints quarter and shorter notes in black,
whereas longer ones get the "regular" diamond.
One of them is probably redundant. But I thought that for people like
Trevor it might be nice to have a harmonic style which behaves in a way
analogous to, say, neomensural. On the other hand, if you need black
notes throughout, it might be awkward to continuously override the
settings. Any objections against both styles or other suggestions? Or is
it completely inappropriate to add any additional "artificial" styles?
Concerning the naming of the new black diamond glyph I decided to stick
with "s2harmonic" for the time being because it underlines the
parallelism to neomensural and the other styles where the black notehead
is called "s2neomensural", etc. To further keep up this similarity I
also added a glyph called "s1harmonic" which is entirely identical to
the open diamond but in a way "closes the gap" between "s0" and "s2"
(although it is used nowhere at all). IMHO this provides some sort of
consistency in the naming. Agree?
Since Trevor urged me to do so and in case there is interest to include
the changes in a future version, I attached patches for the two modified
files mf/parmesa-heads.mf and scm/output-lib.scm, incorporating the
changes as described. Is there a more canonical place to submit them?
Also, if there are suggestions for a different solution, just tell me,
so that I can adapt the files and resend the patches if desired. (BTW,
are there any naming conventions for patches?)
>> [...] is the *.mf file the right place at all to make changes?
>
> yes, but do take the hints in mf/README at heart.
Thanks for the hint. I had read them before, but since I only reused
existing functions and did not add my own metafont code, I am confident
that everything is fine.
>> [... about ragged outlines when viewing the pdf output in xpdf ...]
> It might be related to the version of fontforge that you use.
It's the newest Debian package available. However, I did not use
FontForge to modify the glyph and was not aware that it plays a role in
the compilation process of lilypond (thus indirectly influencing the
viewing of pdf files). How does it do this?
Thanks again and best regards
Max
--- scm/output-lib.scm.old 2007-01-25 00:21:49.0 +0100
+++ scm/output-lib.scm 2007-01-25 00:20:55.0 +0100
@@ -168,6 +168,9 @@
;; statement. -- jr
((xcircle) "2xcircle")
((harmonic) "0harmonic")
+ ((harmonic-black) "2harmonic")
+ ((harmonic-mixed) (if (<= log 1) "0harmonic"
+ "2harmonic"))
((baroque)
;; Oops, I actually would not call this "baroque", but, for
;; backwards compatibility to 1.4, this is supposed to take
--- mf/parmesan-heads.mf.old2007-01-25 00:30:11.0 +0100
+++ mf/parmesan-heads.mf2007-01-25 00:29:41.0 +0100
@@ -192,6 +192,20 @@
charwy := 0;
fet_endchar;
+fet_beginchar("Harmonic notehead (Neo-mensural open)",
+ "s1harmonic")
+ draw_neomensural_open_head (1.3 staff_space#, 1.3 noteheight#);
+ charwx := head_width#;
+ charwy := 0;
+fet_endchar;
+
+fet_beginchar("Harmonic notehead (Neo-mensural black)",
+ "s2harmonic")
+ draw_neomensural_black_head (
section 5.1 `Moving objects' is out of date
Due to the new collision avoidance algorithm, section 5.1, `Moving objects', is out of date. Similarly, in section 4.2, `Saving typing with identifiers and functions', the music function `padText' should be replaced with something more meaningful. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
cropping problem
In section 5.1, `Moving objects', there are two examples using `extra-offset'. The second one has the `ritenuto' cropped partially. I wonder whether it is a generic problem (this is, lilypond can't compute the bounding box correctly if extra-offset is used) or whether it is a bug. In the former case, it should be documented. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
beams in tuplets
Have a look at section 2.2.6 in the tutorial, subsection `Tuplets'.
The third beat in the displayed bar is entered as
\times 2/3 { f,8 g16 a g a }
and displayed as
x x x x x
| | | | |
|-- -
---
3
I strongly disagree with this default devision! It should be
x x x x x
| | | | |
| - -
---
3
instead -- a triplet should by default be subdivided into three units,
not two.
In case nobody objects, I'll file a bug report.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal: second style for quartertone accidentals
Maximilian Albert escreveu: > Orm Finnendahl schrieb: > >> thanks for pointing that out. That's exactly along the lines I was >> thinking. Is anybody capable of doing the scheme/lilypond code? I >> don't know Metafont yet but I think I could handle that part and throw >> in the glyphs (they are currently PS Type1). > > Well, I'd be delighted to give it a try because this sounds exactly like > the kind of rather easy task which merely distracts the core team from > doing more difficult and really important stuff but gives newcomers like > me a chance to play around a little with the code and possibly even make > a useful contribution. Exactly. > . So it seems that the use of "Accidental #'style" is deprecated and one > should set the alteration-alist directly. (But changing the style > property still works in v2.11.13, even if I don't know why, given that I > couldn't find the code handling it). What is the reason for this? To me > the former notation seems much more intuitive and easy to use. The recent microtone improvements needed a much more flexible way to map pitches onto symbols, and it seems superfluous to have two mechanisms for setting glyphname at the same time. It would be possible to have a mechanism to set the alist based on the style property, but I thought it would be overkill. -- 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
