separate narrowed accidentals (issue 5527049)
Reviewers: , Message: ignore first 3 sentences, it was a mistake. http://code.google.com/p/lilypond/issues/detail?id=2203 Description: separate narrowed accidentals leaving arrows alone font: narrowed variants of accidentals As discussed in issue 2142, narrower versions of accidentals would be useful for typesetting very tight music. This patches adds such narrow accidentals to the font. Samples showing them are attached to tracker issue. Please review this at http://codereview.appspot.com/5527049/ Affected files: M mf/feta-accidentals.mf Index: mf/feta-accidentals.mf diff --git a/mf/feta-accidentals.mf b/mf/feta-accidentals.mf index feac34f9ed68e0b6288439e99548db04a3a40d07..f1b2980e9d03b3234ed2f12fa0ae5c913605e047 100644 --- a/mf/feta-accidentals.mf +++ b/mf/feta-accidentals.mf @@ -191,7 +191,7 @@ def draw_meta_sharp (expr width, offset) = enddef; -def draw_sharp(expr arrowup, arrowdown) = +def draw_sharp(expr arrowup, arrowdown, narrowed) = save stem, stemx, stemwidth; save outer_space, interbeam; save stemlength, extendleft, extendright, height, depth; @@ -217,9 +217,14 @@ def draw_sharp(expr arrowup, arrowdown) = extendleft# := extendleft# + 1.5 stafflinethickness#; fi; define_pixels (extendleft, extendright); - set_char_box (extendleft#, 1.1 staff_space#, depth#, height#); + if narrowed: + set_char_box (extendleft#, 0.88 staff_space#, depth#, height#); + stem := 8 / 16 * w; + else: + set_char_box (extendleft#, 1.1 staff_space#, depth#, height#); + stem := 7 / 16 * w; + fi; - stem := 7 / 16 * w; stemx := hround stem; outer_space := hround ((w - stemx - stemwidth) / 2); @@ -264,7 +269,15 @@ enddef; fet_beginchar (Sharp, sharp); - draw_sharp (false, false); + draw_sharp (false, false, false); +fet_endchar; + + +draw_shifted_too; + + +fet_beginchar (Narrowed Sharp, sharp.narrow); + draw_sharp (false, false, true); fet_endchar; @@ -272,7 +285,7 @@ draw_shifted_too; fet_beginchar (Arrowed Sharp (arrow up), sharp.arrowup); - draw_sharp (true, false); + draw_sharp (true, false, false); fet_endchar; @@ -280,7 +293,7 @@ draw_shifted_too; fet_beginchar (Arrowed Sharp (arrow down), sharp.arrowdown); - draw_sharp (false, true); + draw_sharp (false, true, false); fet_endchar; @@ -288,7 +301,7 @@ draw_shifted_too; fet_beginchar (Arrowed Sharp (arrows up and down), sharp.arrowboth); - draw_sharp (true, true); + draw_sharp (true, true, false); fet_endchar; @@ -482,7 +495,7 @@ draw_shifted_too; % The stems of the natural are brushed (at least, in Barenreiter SCS) % -def draw_natural (expr arrowup, arrowdown) = +def draw_natural (expr arrowup, arrowdown, narrowed) = save stemwidth, top_stem_thick; save ne, pat_top, pat_bottom; save depth, height, extendleft, extendright, stemlength; @@ -511,7 +524,11 @@ def draw_natural (expr arrowup, arrowdown) = fi; define_pixels (extendright); - set_char_box (extendleft#, 2/3 staff_space#, depth#, height#); + if narrowed: + set_char_box (extendleft#, 4/7 staff_space#, depth#, height#); + else: + set_char_box (extendleft#, 2/3 staff_space#, depth#, height#); + fi; d := d - feta_space_shift; @@ -612,7 +629,15 @@ enddef; fet_beginchar (Natural, natural); - draw_natural (false, false); + draw_natural (false, false, false); +fet_endchar; + + +draw_shifted_too; + + +fet_beginchar (Narrowed Natural, natural.narrow); + draw_natural (false, false, true); fet_endchar; @@ -620,7 +645,7 @@ draw_shifted_too; fet_beginchar (Arrowed Natural (arrow up), natural.arrowup); - draw_natural (true, false); + draw_natural (true, false, false); fet_endchar; @@ -628,7 +653,7 @@ draw_shifted_too; fet_beginchar (Arrowed Natural (arrow down), natural.arrowdown); - draw_natural (false, true); + draw_natural (false, true, false); fet_endchar; @@ -636,7 +661,7 @@ draw_shifted_too; fet_beginchar (Arrowed Natural (arrows up and down), natural.arrowboth); - draw_natural (true, true); + draw_natural (true, true, false); fet_endchar; @@ -839,6 +864,19 @@ fet_endchar; draw_shifted_too; +fet_beginchar (Narrowed Flat, flat.narrow); + draw_arrowed_meta_flat (0, 0.65 staff_space#, 0.27 staff_space, + false, false); + penlabels (range 0 thru 11); + + remember_pic := currentpicture; + + draw_staff (-2, 2, 0); +fet_endchar; + + +draw_shifted_too; + fet_beginchar (Arrowed Flat (arrow up), flat.arrowup); draw_arrowed_meta_flat (0, 0.8 staff_space#, 0.31 staff_space, @@ -1163,6 +1201,24 @@ fet_beginchar (Double Flat, flatflat); fet_endchar; +fet_beginchar (Narrowed Double Flat, flatflat.narrow); + save left_wid,
Re: build: adding forntforge 20110222 to requirements (issue 5530044)
On Sat, Jan 07, 2012 at 11:24:18PM +, janek.lilyp...@gmail.com wrote: I don't know how to check for --enable-double but this patch assures that fontforge 20110222 is a requirement, not an option. It's a start, but not enough. You need to check for --enable-double. It's given by the version string. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
On Sun, Jan 08, 2012 at 01:52:41AM +0100, Łukasz Czerwiński wrote: As for all the emails that were written it the last two days, I believe that a sort of coordination is needed in each project. We have the amount of coordination that we have chosen. * Let's assume that I would like to help in developing Lilypond, but I don't have my own idea, what part of it I could improve. What would you suggest me to do? There are tons of open issues on the tracker. Are there some guidelines how to write new code to work in the same manner as the already written code? We have a contributor's guide. It is not complete, but that's where to look. If no, is there a person (several people?) that could answer such questions? Janek used to be that person, but he gave up. So no, we do not have any dedicated people that work with new contributors. A few developers often give feedback for patches. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: position of dots
Moving from lilypond-user to lilypond-devel: Is the problem appearing when engravers are moved an instance of http://code.google.com/p/lilypond/issues/detail?id=1792 ? That or issue 44. For issue 1792 I had to expand the list of cases when DotColumns avoid colliding chords http://codereview.appspot.com/4293054/diff/15002/lily/note-collision.cc#newcode310 To support setting dot-columns in each voice, the obviously-missing case involves chords that 'touch' and where the head note of the chord with the down-pointing-stem is on a line. a'2.\\g'2. I encourage you to refine this code, Janek, with your eye for detail. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: Usage - added link for Windows users (issue 5521056)
this breaks make doc.
http://codereview.appspot.com/5521056/diff/1/Documentation/usage/lilypond-book.itely
File Documentation/usage/lilypond-book.itely (right):
http://codereview.appspot.com/5521056/diff/1/Documentation/usage/lilypond-book.itely#newcode38
Documentation/usage/lilypond-book.itely:38: @cindex @Latex{}
breaks doc compile.
http://codereview.appspot.com/5521056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: build: adding forntforge 20110222 to requirements (issue 5530044)
I don't know how to check for --enable-double There is `-D' appended somewhere after the date in fontforge's version string, e.g. Executable based on sources from 23:14 GMT 25-Feb-2011-ML-TtfDb-D. ^^ Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: include music-function
Hello Carl, Hello David, thanks for your replies! I will read through those threads next week. This might help me understand what is happening under the hood. The basic include is working as expected. But I think it would be a nice feature if one could search for files to include using scheme. Cheers, Jan-Peter Am 06.01.2012 um 21:40 schrieb Carl Sorensen c_soren...@byu.edu: On 1/6/12 7:28 AM, David Kastrup d...@gnu.org wrote: Now I don't want to repeat old mistakes, but I don't really have the time for an extended investigation. So if somebody gives me all the data in a manner that does not require all too much thinking on my side, I might try putting that kind of functionality back. Here is a thread that discusses this problem. You were not interested in eliminating parser-parse-file at this point, but it appears that it got eliminated anyway. http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/29392/focus=29404 These patches came in response to issue 1096, http://code.google.com/p/lilypond/issues/detail?id=1096 where a segfault happened with parser-parse-string due to infinite recursion, IIUC. Also see issue 1119: http://code.google.com/p/lilypond/issues/detail?id=1119 A related thread (indexed in issue 1096) is: http://lists.gnu.org/archive/html/lilypond-devel/2010-02/msg00106.html HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: include music-function
Jan-Peter Voigt jp.vo...@gmx.de writes: Am 06.01.2012 10:17, schrieb Jan-Peter Voigt: Am 06.01.2012 09:35, schrieb Jan-Peter Voigt: Hello David, the \sourcefilename hint is helpful! Thank you! If I use this in my function and do a ly:parser-clone, the location is up to date: ... Now I will look, if this is working also with ly:parser-include-string while resetting filename and fileline at the end, so that definitions in the included file get into the current parser. ... yes it does: --snip-- #(define-public includeLocal (define-music-function (parser location file)(string?) (let ((outname (format ~A.ly (ly:parser-output-name parser))) (locname (car (ly:input-file-line-char-column location))) (locpos (cadr (ly:input-file-line-char-column location (if (or (string=? outname locname)(string-suffix? outname locname)) (begin (ly:parser-include-string parser (format \\sourcefilename \~A\ \\sourcefileline 0\n (ly:find-file file))) (ly:parser-include-string parser (ly:gulp-file file)) (ly:parser-include-string parser (format \\sourcefilename \~A\ \\sourcefileline ~A\n locname locpos (make-music 'SequentialMusic 'void #t --snip-- ... but if I include a file in an included file, it will not parse. I will investigate that for more info. OK, now I had lunch and saw my own mistakes ... Here are the two functions I implemented ... still a bit clumsy, but it works for now ... if you are interested *how* and *why* to use them, don't hesitate to mail me! Actually, this is quite too complicated... (ly:parser-include-string parser (format #f \\include ~S file)) should likely be all that is needed here. Sorry for thinking too complicated. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Janek Warchoł janek.lilyp...@gmail.com writes:
2012/1/5 David Kastrup d...@gnu.org:
Janek Warchoł janek.lilyp...@gmail.com writes:
2012/1/4 David Kastrup d...@gnu.org:
\layout {
\layout-from { \compressFullBarRests
\override Score.SpacingSpanner #'common-shortest-duration =
#(ly:make-moment 6 10)
}
etc...
}
ok... However - i'm very sorry to say this :/ - it would be better if
i wouldn't have to type \layout-from at all.
\layout is not the place to accept arbitrary music.
i understand. I think my answer is maybe \layout could work
differently than now? [1]
Do not think that I came to abolish the documentation or the
programmers; I did not come to abolish but to fulfill.
As you so aptly remarked:
[1] I think that a more detailed discussion should be a part of GLISS.
Well, I am currently more or less working on a first coming -- first
serving base. My priority is on making work with the current principles
and design nicer. If you don't like layout specifications and context
definitions, you just write things like \compressFullBarRests into every
voice and things will work out fine. In fact, many examples I see start
with something like
global = { \time 4/4 \compressFullBars and whatever else }
...
\new Voice { \global ... }
It just tends to get mucky with implicit voices and grace notes, but the
ways in which it gets mucky are reasonably well-understood.
I really don't quite get the point of complaining that I provide
alternative ways of accessing functionality. Nobody forces you to make
use of them.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Janek Warchoł janek.lilyp...@gmail.com writes: What i want to say is, i'm afraid you might have forgotten how it feels to be a non-programmer. It's not a joke that for average person that wants to produce some notation, it's hard enough to use text input. In the light of the focus of the work I have been doing for several months, I have a hard time not finding your remarks offensive. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: include music-function
Ah, yes ... I will rewrite this, when I'm in my machine again Cheers, Jan-Peter Am 07.01.2012 um 09:42 schrieb David Kastrup d...@gnu.org: Jan-Peter Voigt jp.vo...@gmx.de writes: Am 06.01.2012 10:17, schrieb Jan-Peter Voigt: Am 06.01.2012 09:35, schrieb Jan-Peter Voigt: Hello David, the \sourcefilename hint is helpful! Thank you! If I use this in my function and do a ly:parser-clone, the location is up to date: ... Now I will look, if this is working also with ly:parser-include-string while resetting filename and fileline at the end, so that definitions in the included file get into the current parser. ... yes it does: --snip-- #(define-public includeLocal (define-music-function (parser location file)(string?) (let ((outname (format ~A.ly (ly:parser-output-name parser))) (locname (car (ly:input-file-line-char-column location))) (locpos (cadr (ly:input-file-line-char-column location (if (or (string=? outname locname)(string-suffix? outname locname)) (begin (ly:parser-include-string parser (format \\sourcefilename \~A\ \\sourcefileline 0\n (ly:find-file file))) (ly:parser-include-string parser (ly:gulp-file file)) (ly:parser-include-string parser (format \\sourcefilename \~A\ \\sourcefileline ~A\n locname locpos (make-music 'SequentialMusic 'void #t --snip-- ... but if I include a file in an included file, it will not parse. I will investigate that for more info. OK, now I had lunch and saw my own mistakes ... Here are the two functions I implemented ... still a bit clumsy, but it works for now ... if you are interested *how* and *why* to use them, don't hesitate to mail me! Actually, this is quite too complicated... (ly:parser-include-string parser (format #f \\include ~S file)) should likely be all that is needed here. Sorry for thinking too complicated. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to check clef type?
On Jan 7, 2012, at 1:49 AM, Janek Warchoł wrote: Hi, i'm inside Clef_engraver::create_clef () - line 130 of lily/clef-engraver.cc I'd like to do sth based on the clef type (G, F or C). What condition should i use? I thought this if (ly_scm2string (clef_-get_property (glyph-name)) == G) would work, but it doesn't. The glyph name would be clefs.G. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: suggestion - increase default beam thickness
On Jan 7, 2012, at 1:54 AM, Janek Warchoł wrote: W dniu 7 stycznia 2012 01:40 użytkownik Carl Sorensen c_soren...@byu.edu napisał: On 1/6/12 4:25 PM, Janek Warchoł janek.lilyp...@gmail.com wrote: Of course we shouldn't change thickness too much. I'd say that it should be 0.51 or 0.52 staffspace. My research is here: http://www.sendspace.com/file/juulc4 What do you think? Are you measuring staff space in pixels from the top of one staff line to the top of the next staff line? Yes, exactly like that. I was often measuring one sample in several places (and estimating an average) because the shapes are not perfect. Can you post regtest comparisons for us to look at? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Need real cross-staff chords
Sent from my iPhone On Jan 7, 2012, at 12:06 AM, Pavel Roskin pro...@gnu.orgmailto:pro...@gnu.org wrote: Quoting Carl Sorensen c_soren...@byu.edumailto:c_soren...@byu.edu: There is no forced-distance now. I can use minimal-distance, but there is no guarantee that Lilypond won't increase the distance between staves. And Lilypond may do it because of something in another measure. You can get a fixed distance by setting minimal-distance = basic-distance, and stretchability = 0. Thank you, Carl! It would be an acceptable solution, even though not the best one. However, it's not working for me. Even simple dynamics can break everything. This is the snippet approach for a change. The gap between staves is wider and the stems are broken in the second measure. Perhaps I misunderstood your suggestion? Oops, no. I forgot to mention that you should also set padding to be something like -minimum-distance, or in your example -9. The staves will now be fixed, but you will need to makesure to leave enough space for dynamics, etc. I'm sorry I forgot about the negative padding value that is also needed. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: staging is a safety net, not a trampoline
- Original Message - From: Keith OHara k-ohara5...@oco.net To: lilypond-devel@gnu.org Sent: Saturday, January 07, 2012 6:16 AM Subject: Re: staging is a safety net, not a trampoline Graham Percival graham at percival-music.ca writes: But please consider testing your patches a bit more before sending them in. Sorry that was probably me. I thought I was safe after testing with doc-section.sh, but these scripts do not report the warnings from lilypond snippets in the docs. I've started `touch Documentation/*te??; make doc` but will leave documentation to the experts from now on. FWIW make doc is now more useful for testing doc changes than it used to be. If you can run make doc successfully, edit your document and then repeat make doc, it will usually only remake the stuff that's been changed - with no need to touch any files. This is because of the work Julien did late last year. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: staging is a safety net, not a trampoline
hello, On 7 January 2012 11:42, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Keith OHara k-ohara5...@oco.net To: lilypond-devel@gnu.org Sent: Saturday, January 07, 2012 6:16 AM Subject: Re: staging is a safety net, not a trampoline Graham Percival graham at percival-music.ca writes: But please consider testing your patches a bit more before sending them in. Sorry that was probably me. I thought I was safe after testing with doc-section.sh, but these scripts do not report the warnings from lilypond snippets in the docs. I've started `touch Documentation/*te??; make doc` but will leave documentation to the experts from now on. FWIW make doc is now more useful for testing doc changes than it used to be. If you can run make doc successfully, edit your document and then repeat make doc, it will usually only remake the stuff that's been changed - with no need to touch any files. This is because of the work Julien did late last year. If that really is true (hooray) then we ought to update http://lilypond.org/doc/v2.15/Documentation/contributor-big-page.html#documentation-editor_0027s-edit_002fcompile-cycle -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: staging is a safety net, not a trampoline
- Original Message - From: James pkx1...@gmail.com To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org; Keith OHara k-ohara5...@oco.net Sent: Saturday, January 07, 2012 11:54 AM Subject: Re: staging is a safety net, not a trampoline hello, On 7 January 2012 11:42, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Keith OHara k-ohara5...@oco.net To: lilypond-devel@gnu.org Sent: Saturday, January 07, 2012 6:16 AM Subject: Re: staging is a safety net, not a trampoline Graham Percival graham at percival-music.ca writes: But please consider testing your patches a bit more before sending them in. Sorry that was probably me. I thought I was safe after testing with doc-section.sh, but these scripts do not report the warnings from lilypond snippets in the docs. I've started `touch Documentation/*te??; make doc` but will leave documentation to the experts from now on. FWIW make doc is now more useful for testing doc changes than it used to be. If you can run make doc successfully, edit your document and then repeat make doc, it will usually only remake the stuff that's been changed - with no need to touch any files. This is because of the work Julien did late last year. If that really is true (hooray) then we ought to update http://lilypond.org/doc/v2.15/Documentation/contributor-big-page.html#documentation-editor_0027s-edit_002fcompile-cycle -- -- James Agreed. Please test my assertion - make doc, edit the CG section shown and remake doc - that would make a fair test. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: staging-broken-jan7
On Jan 7, 2012, at 5:23 AM, Graham Percival wrote: I've branched current staging -- unfortunately *after* removing two patches which seemed to break stuff -- to staging-broken-jan7. I picked one patch, Mike's non-negativity check, to put into the new staging on the theory that it was the least likely to be breaking stuff. If somebody wants to look into this more, that would be great. - Graham I'm trying to look at my commits to see if they're the culprit, and I got a failed make doc on: bar-chords-notation-for-guitar--with-text-spanner.ly However, current master also struggles with this file (ghostscript barfs and there are lots of undead parsed objects). Does anyone else have this problem? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
wiki at lilynet?
Hello, I have found this when looking for the lilypond wiki: http://wiki.lilynet.net/ MediaWiki 1.16.5 To complete the installation, move config/LocalSettings.php to the parent directory. I don't really know whether to say congratulations or too bad. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Prevents Beam vs Flag collisions (issue 5527047)
LGTM. Will test soon. http://codereview.appspot.com/5527047/diff/1/lily/lily-guile.cc File lily/lily-guile.cc (left): http://codereview.appspot.com/5527047/diff/1/lily/lily-guile.cc#oldcode573 lily/lily-guile.cc:573: int i = scm_to_int (k); Please apply this cosmetic patch directly to the repository; I think it doesn't belong to the rest of the patch set. http://codereview.appspot.com/5527047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Prevents Beam vs Flag collisions (issue 5527047)
Reviewers: lemzwerg,
Message:
On 2012/01/07 15:18:07, lemzwerg wrote:
LGTM. Will test soon.
http://codereview.appspot.com/5527047/diff/1/lily/lily-guile.cc
File lily/lily-guile.cc (left):
http://codereview.appspot.com/5527047/diff/1/lily/lily-guile.cc#oldcode573
lily/lily-guile.cc:573: int i = scm_to_int (k);
Please apply this cosmetic patch directly to the repository; I think
it doesn't
belong to the rest of the patch set.
Sorry ... I have no clue why this is here.
Will get rid of it.
Description:
Prevents Beam vs Flag collisions
Please review this at http://codereview.appspot.com/5527047/
Affected files:
A input/regression/beam-collision-flag.ly
M lily/beam-collision-engraver.cc
M lily/lily-guile.cc
Index: input/regression/beam-collision-flag.ly
diff --git a/input/regression/beam-collision-flag.ly
b/input/regression/beam-collision-flag.ly
new file mode 100644
index
..beed7315ab283458b5e4184fd587724c4f78d352
--- /dev/null
+++ b/input/regression/beam-collision-flag.ly
@@ -0,0 +1,11 @@
+\version 2.15.24
+
+\header {
+ texidoc = Beams do not collide with flags.
+
+}
+
+\relative c'
+ { \voiceOne c'8 r } \\
+ { \voiceThree c,8.[ c'16] }
+
Index: lily/beam-collision-engraver.cc
diff --git a/lily/beam-collision-engraver.cc
b/lily/beam-collision-engraver.cc
index
8e397508b79df7aa092516598a6e5df8fcb653b0..aec586157bbb5104964b7c6a482b978d516ba93b
100644
--- a/lily/beam-collision-engraver.cc
+++ b/lily/beam-collision-engraver.cc
@@ -37,6 +37,7 @@ protected:
DECLARE_ACKNOWLEDGER (key_signature);
DECLARE_ACKNOWLEDGER (time_signature);
DECLARE_ACKNOWLEDGER (beam);
+ DECLARE_ACKNOWLEDGER (flag);
virtual void finalize ();
@@ -171,6 +172,12 @@ Beam_collision_engraver::acknowledge_time_signature
(Grob_info i)
}
void
+Beam_collision_engraver::acknowledge_flag (Grob_info i)
+{
+ covered_grobs_.push_back (i);
+}
+
+void
Beam_collision_engraver::acknowledge_beam (Grob_info i)
{
beams_.push_back (i);
@@ -185,6 +192,7 @@ ADD_ACKNOWLEDGER (Beam_collision_engraver, accidental);
ADD_ACKNOWLEDGER (Beam_collision_engraver, clef);
ADD_ACKNOWLEDGER (Beam_collision_engraver, key_signature);
ADD_ACKNOWLEDGER (Beam_collision_engraver, time_signature);
+ADD_ACKNOWLEDGER (Beam_collision_engraver, flag);
ADD_ACKNOWLEDGER (Beam_collision_engraver, beam);
ADD_TRANSLATOR (Beam_collision_engraver,
Index: lily/lily-guile.cc
diff --git a/lily/lily-guile.cc b/lily/lily-guile.cc
index
cc71dcba2ceff4ece9258e6f3da0208ad2aaf6d1..6035a91983303d6284e83d4660c4ada853ef7514
100644
--- a/lily/lily-guile.cc
+++ b/lily/lily-guile.cc
@@ -570,9 +570,9 @@ robust_scm2vsize (SCM k, vsize o)
{
if (scm_integer_p (k) == SCM_BOOL_T)
{
- int i = scm_to_int (k);
- if (i = 0)
-return (vsize) i;
+ o = scm_to_int (k);
+ if (o = 0)
+return (vsize) o;
}
return o;
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Documentation for the PDF produced by Lilypond
Is there any documentation about the pdf output format details? Cheers, Felix ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation for the PDF produced by Lilypond
Felix Kugel f.ku...@googlemail.com writes: Is there any documentation about the pdf output format details? LilyPond produces PostScript. PDFs are courtesy of Ghostscript, so the details are to be asked there. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation for the PDF produced by Lilypond
Felix, On 6 January 2012 14:51, Felix Kugel f.ku...@googlemail.com wrote: Is there any documentation about the pdf output format details? More specifically? We have http://lilypond.org/doc/v2.15/Documentation/internals/index.html which may be what you are looking for. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation for the PDF produced by Lilypond
Hi James, thanks for that link. http://lilypond.org/doc/v2.15/Documentation/internals/index.html I'm about to write an interactive application for prima vista reading (in Java). I want to color played (and wrongly played) note heads, but the roundtrip from lilypond source to PDF is too slow for real-time. BTW, does anyone know such an open source project? My idea is to render the score once with all noteheads in black, and then quickly alter colors directly in the PDF, without going through Lilypond. Using PDF manipulation libraries, i want to locate specific note head PDF objects and change their color. Therefore, i need to know the specific PDF structure produced by Lilypond, some kind of schema like a class diagram. Of course it would be more convenient to use Lilypond's programmatic interfaces in-memory from Java, maybe the roundtrip could be fast enough for small scores. But i didn't investigate so far. Felix ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation for the PDF produced by Lilypond
On Jan 7, 2012, at 10:14 AM, Felix Kugel f.ku...@googlemail.com wrote: Hi James, Using PDF manipulation libraries, i want to locate specific note head PDF objects and change their color. Therefore, i need to know the specific PDF structure produced by Lilypond, some kind of schema like a class diagram. You might want to use the svg output instead of the PDF. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Engravers cannot be added at the StaffGroup level
Dear Bug Squad,
This has been reported two times in lilypond-user:
http://lists.gnu.org/archive/html/lilypond-user/2011-12/msg00395.html
http://lists.gnu.org/archive/html/lilypond-user/2012-01/msg00111.html
Mark_engraver or Metronome_mark_engraver should be moveable to the
StaffGroup (and alike: GrandStaff, ChoirStaff, etc.) context (and work!!).
Snippet
\version 2.13.24
music = \repeat unfold 5 {
\repeat unfold 5 c'1
\mark \default
}
\score {
\new Staff {
s1*0^Marks should NOT be above this Staff (i.e. above the Score)!
\music
}
\new StaffGroup {
\new Staff {
s1*0^Marks should be above the StaffGroup
\music
}
\new Staff {
\music
}
}
\layout {
\context {
\Score
\remove Mark_engraver
% same for Metronome_mark_engraver
\remove Staff_collecting_engraver
}
\context {
\StaffGroup
\consists Mark_engraver
\consists Staff_collecting_engraver
% same for Metronome_mark_engraver
}
}
}
%% Note that it works if we move it to the Staff level (instead of the
%% StaffGroup). But engravers at the StaffGroup level is required for
%% example if the first staff of the StaffGroup is removed, using
%% \RemoveEmptyStaves (Frenched score).
\score {
\new Staff {
s1*0^Marks are not above the score
\music
}
\new StaffGroup {
\new Staff \with {
\consists Mark_engraver
} {
s1*0^Marks are above this Staff
\music
}
\new Staff {
\music
}
}
\layout {
\context {
\Score
\remove Mark_engraver
\remove Staff_collecting_engraver
}
\context {
\Staff
% \consists Mark_engraver % We add this engraver to the
second Staff only
\consists Staff_collecting_engraver
}
}
}
End of the snippet
Cheers,
Xavier
--
Xavier Scheuer x.sche...@gmail.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Engravers cannot be added at the StaffGroup level
Added as http://code.google.com/p/lilypond/issues/detail?id=2199
2012/1/7 Xavier Scheuer x.sche...@gmail.com:
Dear Bug Squad,
This has been reported two times in lilypond-user:
http://lists.gnu.org/archive/html/lilypond-user/2011-12/msg00395.html
http://lists.gnu.org/archive/html/lilypond-user/2012-01/msg00111.html
Mark_engraver or Metronome_mark_engraver should be moveable to the
StaffGroup (and alike: GrandStaff, ChoirStaff, etc.) context (and work!!).
Snippet
\version 2.13.24
music = \repeat unfold 5 {
\repeat unfold 5 c'1
\mark \default
}
\score {
\new Staff {
s1*0^Marks should NOT be above this Staff (i.e. above the Score)!
\music
}
\new StaffGroup {
\new Staff {
s1*0^Marks should be above the StaffGroup
\music
}
\new Staff {
\music
}
}
\layout {
\context {
\Score
\remove Mark_engraver
% same for Metronome_mark_engraver
\remove Staff_collecting_engraver
}
\context {
\StaffGroup
\consists Mark_engraver
\consists Staff_collecting_engraver
% same for Metronome_mark_engraver
}
}
}
%% Note that it works if we move it to the Staff level (instead of the
%% StaffGroup). But engravers at the StaffGroup level is required for
%% example if the first staff of the StaffGroup is removed, using
%% \RemoveEmptyStaves (Frenched score).
\score {
\new Staff {
s1*0^Marks are not above the score
\music
}
\new StaffGroup {
\new Staff \with {
\consists Mark_engraver
} {
s1*0^Marks are above this Staff
\music
}
\new Staff {
\music
}
}
\layout {
\context {
\Score
\remove Mark_engraver
\remove Staff_collecting_engraver
}
\context {
\Staff
% \consists Mark_engraver % We add this engraver to the
second Staff only
\consists Staff_collecting_engraver
}
}
}
End of the snippet
Cheers,
Xavier
--
Xavier Scheuer x.sche...@gmail.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Need real cross-staff chords
Hi Pavel, 2012/1/7 Pavel Roskin pro...@gnu.org: I believe it would be nice to have support for cross-staff chords. Perhaps it could be done as another snippet. I'm a beginner in Scheme and Lilypond, so it takes me quite a lot of effort. I'll appreciate some help. I envision having a Scheme function that would apply to some notes in the chord: g c g,\crossStaff I wish that i could help you doing this, but it's beyond my knowledge. I have a suggestion for the future syntax, though - i think it would be best to define cross-staff chords like cross-staff voices, i.e. use \change Staff = StaffName inside chord construct: g c \change Staff = LeftHand g, You may consider writing a brief feature request that would be added to our tracker (http://code.google.com/p/lilypond/issues/list), so that this issue doesn't get lost. (send the feature request to bug-lilypond) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
David, 2012/1/7 David Kastrup d...@gnu.org: I really don't quite get the point of complaining that I provide alternative ways of accessing functionality. Nobody forces you to make use of them. 2012/1/7 David Kastrup d...@gnu.org: In the light of the focus of the work I have been doing for several months, I have a hard time not finding your remarks offensive. I'm very sorry! I didn't mean that you're doing anything wrong - my comments were intended to be about lily infrastructure in general. I value your work and i think it's very good for LilyPond. If my words were offensive to you, i call them off! my apologies Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
custom signs....
Dear list,
inspired by a pretty old post by Bertala Fodor i designed some signs for
me. For example:
#(define-markup-command (mysign layout props)()
(interpret-markup layout props
(markup #:postscript 0 5 translate 0.16 -0.16 scale newpath 0 0.846390
moveto 0 0 lineto 13 0 lineto 13 13 lineto 11 13 lineto 11 2 lineto 0 2
lineto 0 0 lineto closepath fill 0 -14 moveto
)))
They print well by ^\markup{mysign} in the score, but a completely
ignored by lilypond's spacing/collision department.
What can i do that lilypond calculates the space for it?
Yours, Arno
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: custom signs....
On Jan 7, 2012, at 10:21 PM, Arno Waschk wrote:
Dear list,
inspired by a pretty old post by Bertala Fodor i designed some signs for me.
For example:
#(define-markup-command (mysign layout props)()
(interpret-markup layout props
(markup #:postscript 0 5 translate 0.16 -0.16 scale newpath 0 0.846390
moveto 0 0 lineto 13 0 lineto 13 13 lineto 11 13 lineto 11 2 lineto 0 2
lineto 0 0 lineto closepath fill 0 -14 moveto
)))
They print well by ^\markup{mysign} in the score, but a completely ignored by
lilypond's spacing/collision department.
What can i do that lilypond calculates the space for it?
You need to use LilyPond's native stencil functions.
Check out make-connected-path-stencil (which has scale arguments) and
ly:stencil-translate. You can basically copy and paste your work into that,
changing the syntax a bit to work for Scheme.
Then feed this stencil to the \stencil command in a markup.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: suggestion - increase default beam thickness
2012/1/7 m...@apollinemike.com m...@apollinemike.com:
On 1/6/12 4:25 PM, Janek Warchoł janek.lilyp...@gmail.com wrote:
Of course we shouldn't change thickness too much. I'd say that it
should be 0.51 or 0.52 staffspace.
Can you post regtest comparisons for us to look at?
Well, there are changes in many tests, but the actual difference in
thickness is too small to be seen in low-resolution regtest images.
Surprisingly, however, there are some changes in beam positions - some
beams are slightly better, some slightly worse. See here:
http://www.sendspace.com/file/fyx6pj
If you'd like to see how this new thickness looks like, add
\context { \Voice \override Beam #'beam-thickness = #0.51 }
to your \layout block.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
build: adding forntforge 20110222 to requirements (issue 5530044)
Reviewers: , Message: Graham said we cannot assume that we have fontforge 20110222 with --enable-double until ../configure checks for this. This requires a change to configure.in which will be 1-10 lines of code. I don't know how to check for --enable-double but this patch assures that fontforge 20110222 is a requirement, not an option. Description: build: adding forntforge 20110222 to requirements Please review this at http://codereview.appspot.com/5530044/ Affected files: M configure.in Index: configure.in diff --git a/configure.in b/configure.in index 7a020d6e097fdef22e04ad16af6cc935f2da19a4..c599c0ee70b53acb11b60d984ca7a0c14c53f26f 100644 --- a/configure.in +++ b/configure.in @@ -163,8 +163,7 @@ STEPMAKE_PYTHON_DEVEL(REQUIRED) STEPMAKE_PATH_PROG(GHOSTSCRIPT, gs, OPTIONAL, 8.60) -STEPMAKE_PATH_PROG(FONTFORGE, fontforge, REQUIRED, 20100501) -STEPMAKE_PATH_PROG(FONTFORGE, fontforge, OPTIONAL, 20110222) +STEPMAKE_PATH_PROG(FONTFORGE, fontforge, REQUIRED, 20110222) STEPMAKE_PATH_PROG(T1ASM, t1asm, REQUIRED) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Need real cross-staff chords
Quoting Janek Warchoł janek.lilyp...@gmail.com: Hi Pavel, 2012/1/7 Pavel Roskin pro...@gnu.org: I believe it would be nice to have support for cross-staff chords. Perhaps it could be done as another snippet. I'm a beginner in Scheme and Lilypond, so it takes me quite a lot of effort. I'll appreciate some help. I envision having a Scheme function that would apply to some notes in the chord: g c g,\crossStaff I wish that i could help you doing this, but it's beyond my knowledge. I have a suggestion for the future syntax, though - i think it would be best to define cross-staff chords like cross-staff voices, i.e. use \change Staff = StaffName inside chord construct: g c \change Staff = LeftHand g, I actually tried it and it didn't work. I think implementing this approach in Scheme may be harder, as I would need to redefine \change (or catch for staff change events or something as hairy as that) rather than write a new function. You may consider writing a brief feature request that would be added to our tracker (http://code.google.com/p/lilypond/issues/list), so that this issue doesn't get lost. (send the feature request to bug-lilypond) I will. We have a good reason to want cross-staff chords rather than a fragile imitation that can only be held together by hacks involving negative padding :) -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Need real cross-staff chords
Quoting Carl Sorensen c_soren...@byu.edu: Oops, no. I forgot to mention that you should also set padding to be something like -minimum-distance, or in your example -9. That works! The staves will now be fixed, but you will need to makesure to leave enough space for dynamics, etc. Absolutely. I just don't want to replace something that is glued together, albeit in an ugly way, with something that is not glued together at all. I'm sorry I forgot about the negative padding value that is also needed. No problem. I'll be able to finish my conversion now. I'm also going to file a bug report, as using negative padding is very counterintuitive. How ironic is that I participated yesterday in the naming context for non-negative integers :) -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
First of all I would like to apologize for misjudging Lilypond project. As for all the emails that were written it the last two days, I believe that a sort of coordination is needed in each project. Maybe for some of them there must be one boss with many programmers and designers, while for other projects a better solution is to create several small loosely connected groups, nevertheless each of them having a leader. As a person who knows only a bit of Lilypond, I would like to get a better view of Lilypond, so I'd like to ask some questions: - What's the aim of Lilypond? And why isn't it competing with Finale and Sibellius? Aren't all three programs making PDF files with music? Of course Finale and Sibellius have some other functionalities, but the common one is related to PDFs. - Every computer program and in fact every thing or machine have a most common user. How would you describe a most common user of Lilypond? How does he/she use Lilypond, what kind of music (and how complex) does they (re-)write? What annoys or disturbs them most in Lilypond? - Let's assume that I would like to help in developing Lilypond, but I don't have my own idea, what part of it I could improve. What would you suggest me to do? If everybody does it in his own local way, it is more a distraction than anything else. How does one do x in LilyPond? Depends on whether you are talking about functionality written by Mike, David, Han-Wen, Jan, Graham, Carl or Werner. That's not what a user wants to hear. Are there some guidelines how to write new code to work in the same manner as the already written code? If no, is there a person (several people?) that could answer such questions? Well, uniform code is nice, modular code is better. You don't need to worry about uniformity if everything actually calls the same code. And if you need to change how it works, being able to do it in one place is much less likely to cause problems. Of course, that needs to touch foreign code in a lot of places instead of just leading by example. And that's where actual leadership is helpful since it can _make_ people change their _own_ code, and they usually are much better qualified to see problems in connection with those changes than a self-appointed global janitor can hope to be. I totally agree. I think a good policy is that, when working on that which one wants to work on, one should always strive to do it in a way that leads to better maintainability and extensibility. If those efforts are not coordinated, there is no end user benefit. Coordinated does NOT mean slavery and being a bored, sad programmer ;) It just means that no one is a self-appointed janitor, because there is always someone, who keeps an eye on some guidelines of a quality of a Lilypond code. Hoping to read soon your answers to my questions, Łukasz Czerwiński ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
