Re: Issue 1686 in lilypond: Compile scheme files to scm/out when using Guile V2.n. Also load and run .go files if available
Updates: Status: Started Cc: pnorcks hanw...@gmail.com jan.nieuwenhuizen percival.music.ca Comment #1 on issue 1686 by ianhuli...@gmail.com: Compile scheme files to scm/out when using Guile V2.n. Also load and run .go files if available http://code.google.com/p/lilypond/issues/detail?id=1686 This will need changes in lily.scm - add new compile routines for scheme and modify ly:load to pick up the .go file in preference to .scm; also implement -d compile-scheme which will compile files when running with Guile V2. Also changes in main.cc - When running Guile V2, alter guile list %load-compiled-path as well as %load-path during start-up to find Lilypond files also possibly %compile-fallback-path so Lily knows where Guile autocompile is putting its files. Cheers Ian ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1691 in lilypond: Ugly bars in PDF documents
Status: Accepted Owner: Labels: Type-Documentation Priority-Medium New issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 In the documentation build it's common to see an error message beginning Overfull \hbox. Looking on the web for what this means, I found http://docs.freebsd.org/info/texinfo/texinfo.info.Overfull_hboxes.html which says: TeX is sometimes unable to typeset a line without extending it into the right margin unless told otherwise, TeX will print a large, ugly, black rectangle beside the line that contains the overfull hbox. There are quite a few of these in, say, the 2.14.0 NR - see the PDF page 33 and 37 for example. It would seem there are 2 options: either fix the text/diagram sizes, or compile as suggested in the page above: To prevent such a monstrosity from marring your final printout, write the following in the beginning of the Texinfo file on a line of its own, before the `@titlepage' command: @finalout The current consensus is that it would be better to start by looking at correcting the documentation to get the text correctly sized. Issue 1015 is related to this. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Extracting parts: why does Devnull take as much space as a normal staff ?
Hi all,
In the book I'm engraving, it happens that some instruments get tacet
for certain pieces. In order to generate a full table of contents for
the parts, I treat them through Devnull. The problem is that this
Devnull context takes as much vertical space as a normal staff of
whatever kind I use (by the qay, a rhythmic staff is spread over the
same extent as a 5 lines staff - min-dist = 8.00).
Using annotate-spacing = ##t, Lily spits a
space: NaN/inf
min-dist: NaN/inf
padding: NaN/inf
bottom-of-extent: NaN/inf
extent-estimate: NaN/inf
---8---
\version 2.14.0
#(set-global-staff-size 20)
\paper { annotate-spacing = ##t
ragged-bottom = ##t
ragged-last-bottom = ##t }
\score { b'1}
\score {
%{ \new RhythmicStaff \with {
% \override StaffSymbol #'stencil = ##f
fontSize = #-3
\override StaffSymbol #'staff-space = #(magstep -3)
\override StaffSymbol #'thickness = #(magstep -3) %}
\new Devnull { s1 }
\header { piece = Piece two opus = TACET. }
\layout { %#(layout-set-staff-size 1)
%{\context {
\RhythmicStaff
\remove Time_signature_engraver
\remove Stem_engraver
\remove Beam_engraver
\remove Bar_engraver
\override VerticalAxisGroup
#'default-staff-staff-spacing = #'((basic-distance . 0.01)
(minimum-distance . 0.01)
(padding . -24)
(stretchability . 0))
}
\context {
\Score
\remove Bar_number_engraver
\override VerticalAxisGroup
#'default-staff-staff-spacing = #'((basic-distance . 0.01)
(minimum-distance . 0.01)
(padding . -24)
(stretchability . 0))
\override VerticalAxisGroup #'Y-extent = #'(-0.1 . 0)
%}
}
}
\score { b'1}
---8---
After three full days digging in that; I'm really fed up and upset, and
rely upon you.
The tracks I was following:
- have a piece and opus headers and a Devnull which normally should take
no vertical space - wrong guess;
- have a piece and opus headers and a transparent staff I would
translate up : impossible to change markup-score-spacing neither
score-markup-spacing within a book(part);
- generate a transparent staff of ONE POINT HEIGHT: no way, it still
takes the same vertical space as a regular one.
- create TACETpiece and TACETopus that would mimic the piece and opus
headers whatever the customized layout I use for them: the only point of
entry I git grep are in Documentation/*
Thanks and sorry if for the disturbance,
Jean-Charles
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Extracting parts: why does Devnull take as much space as a normal staff ?
2011/6/13 Jean-Charles Malahieude lily...@orange.fr: - generate a transparent staff of ONE POINT HEIGHT: no way, it still takes the same vertical space as a regular one. On a quick sight, this could be caused by staff-staff spacing which is still standard, non-null despite of the null extent of your staff. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: fretted-string-harmonics-in-tablature snippet
Hi, wish i had not missed this thread and found it earlier... I found a diff in one of your previous e-mails, but it's kind of weird, so i'll simply write how things should look. 2011/5/24 Federico Bruni fedel...@gmail.com: In the second bar of the snippet [http://lilypond.org/doc/v2.13/Documentation/snippets/fretted-strings#fretted_002dstring-harmonics-in-tablature] there is an harmonic played on 5th fret of 4th string (a d in standard tuning), so the note must be a d two octave higher than the d of open string. Currently it's a g. Yes, it should be d''. Look at line 2 of the table: harmonics produced on the middle of the vibrational length are one octave higher. When you play an artificial harmonic, you shorten the string so that the middle of the vibrational length will shift up on the right. In bar 1 of the snippet: left hand is positioned on 4th fret of 3rd string (b note); right hand pluck the 16th fret, which is the new middle position. The rule above applies: one octave higher, because we are in the middle of the main node. In the snippet all artificial harmonics of this kind are raised up by two octaves. They are wrong. They should be raised one octave. I've just realized that the second tapped harmonic may be wrong: shouldn't it be played on 7th fret? Yes, it should. Also the third tapped harmonic should be played on 5th fret. The difference between artificial harmonics and tapped harmonics is just a matter of gesture? Pluck in AH, percussive in TH? Yes. I put lilypond-user in CC, I hope someone will confirm. I do. Concerning the last harmonic: it should be e'' (i.e. note on third ledger line - remember that guitar is written in \clef G_8) Thanks for catching this issue! Janek ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1691 in lilypond: Ugly bars in PDF documents
Comment #2 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Technically I suppose that somebody could just manually tweak the line widths of all examples which are too wide, thereby fixing this issue without fixing issue 1015 (which asks for a general solution to line-width). So no, I wouldn't say that it was blocked on 1015 / 766. It would certainly be nice if those issues could be resolved, though. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: fretted-string-harmonics-in-tablature snippet
Il giorno lun, 13/06/2011 alle 20.10 +0200, Janek Warchoł ha scritto:
Hi,
wish i had not missed this thread and found it earlier...
I found a diff in one of your previous e-mails, but it's kind of
weird, so i'll simply write how things should look.
Hi Janek,
thanks for taking care of it!
Here's the open issue in the tracker:
http://code.google.com/p/lilypond/issues/detail?id=1666
I've just realized that the second tapped harmonic may be wrong:
shouldn't it be played on 7th fret?
Yes, it should. Also the third tapped harmonic should be played on 5th fret.
Yes, you are right.
I put lilypond-user in CC, I hope someone will confirm.
I do.
Concerning the last harmonic: it should be e'' (i.e. note on third
ledger line - remember that guitar is written in \clef G_8)
I still think that it should be e'
The pitch I hear is the same as the 1st open string (standard tuning),
so it's 4th space of the staff.
I attach the patched file.
Sorry, I can't produce a .diff file, even though the two files I'm using
are different. It's a mystery to me...
Waiting for your comments.
Thanks,
Federico
\version 2.14.0
\header {
lsrtags = fretted-strings
texidoc =
Fretted-string harmonics:
doctitle = Fretted-string harmonics in tablature
}
pinchedHarmonics = {
\textSpannerDown
\override TextSpanner #'bound-details #'left #'text =
\markup {\halign #-0.5 \teeny PH }
\override TextSpanner #'style =
#'dashed-line
\override TextSpanner #'dash-period = #0.6
\override TextSpanner #'bound-details #'right #'attach-dir = #1
\override TextSpanner #'bound-details #'right #'text =
\markup { \draw-line #'(0 . 1) }
\override TextSpanner #'bound-details #'right #'padding = #-0.5
}
harmonics = {
%artificial harmonics (AH)
\textLengthOn
\parenthesize b b''\harmonic4_\markup{ \teeny AH 16 }
\parenthesize g g''\harmonic4_\markup{ \teeny AH 17 }
\parenthesize d' d'''\harmonic2_\markup{ \teeny AH 19 }
%pinched harmonics (PH)
\pinchedHarmonics
a'\harmonic2\startTextSpan
g'\harmonic4
e'\harmonic4\stopTextSpan
%tapped harmonics (TH)
\parenthesize g\4 g'\harmonic4_\markup{ \teeny TH 17 }
\parenthesize a\4 a'\harmonic4_\markup{ \teeny TH 19 }
\parenthesize c'\3 c''\harmonic2_\markup{ \teeny TH 17 }
%touch harmonics (TCH)
a4( e''\harmonic2. )_\markup{ \teeny TCH }
}
frettedStrings = {
%artificial harmonics (AH)
\harmonicByFret #4 g4\3
\harmonicByFret #5 d4\4
\harmonicByFret #7 g2\3
%pinched harmonics (PH)
\harmonicByFret #7 d2\4
\harmonicByFret #5 d4\4
\harmonicByFret #7 a4\5
%tapped harmonics (TH)
\harmonicByFret #5 d4\4
\harmonicByFret #5 d4\4
\harmonicByFret #4 g2\3
%touch harmonics (TCH)
a4 \harmonicByFret #9 g2.\3
}
\score {
\new Staff {
\new Voice {
\clef treble_8
\harmonics
}
}
\new TabStaff {
\new TabVoice {
\frettedStrings
}
}
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1688 in lilypond: New half-closed hihat symbol for drum mode
Comment #6 on issue 1688 by carl.d.s...@gmail.com: New half-closed hihat symbol for drum mode http://code.google.com/p/lilypond/issues/detail?id=1688 After following up some more, it appears that fontforge 20110222 works properly, so no bug report is needed. However, this provides a good reason to require fontforge 20110222, so I guess we should get it into lilydev as soon as possible. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1688 in lilypond: New half-closed hihat symbol for drum mode
Comment #7 on issue 1688 by lemzw...@googlemail.com: New half-closed hihat symbol for drum mode http://code.google.com/p/lilypond/issues/detail?id=1688 How comes that it suddenly works? Did you do a mistake? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
