Re: exact inversion (issue4173065)
NR edits LGTM - can't comment on the other .ly files. Sorry. http://codereview.appspot.com/4173065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Question about @lilypond options for creating smaller page examples within our Doc
Hello, While editing the NR 3.2 section on Titles and Headers it seems it would be nice to be able to create 'smaller' (or rather, shorter) ' whole page output' when processing @lilypond examples, so as to show simple things like page breaks, tag lines and headers and footers without having to display a whole Letter/A4 page of blank space. I've takne a look in the usage documents for lilypond-book and Texinfo but I need some advice. It seems to me that I cannot create an explicit output size by specifying height and width dimensions, like I can specify a line length within a @lilypond [xxx] variable. So I thought that if we had a 'custom' entry in the scm/paper.scm file - I experimented with some sizes and it seems that having a height of 35mm is enough to get a line of music, a header/title and a footer - that we could simply refer to that within the @lilypond [xxx] variables. But I cannot see what option to use or if it is possible. I could just explicitly put a \paper {} variable within the @lilypond construct but this isn't as neat and I can't see which option to use in the @lilypond [xxx] variable to force it to use the \paper {} either. Thanks for your help. James attachment: winmail.dat___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fret diagram fixes (issue4176056)
I have added new tracker issue for this patch: http://code.google.com/p/lilypond/issues/detail?id=1530 http://codereview.appspot.com/4176056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Draws a line above footnotes (issue4167063)
Wow, nice job Mike ! I am also currently trying to solve this issue. With Scheme only I managed to do a good solution for endnotes. I have some suggestions for your work : * There should be more space between separator line and footnotes. * Maybe a smaller separator, like LaTeX does. line-width / 3 for example. * Maybe spread the footnotes on several columns, like this : 1 4 7 2 5 8 3 6 * A more user-friendly set of commands ? * This doesn't support text footnotes... But this is a great work, indeed ! http://codereview.appspot.com/4167063/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: transition between full-length and shortened stems - please discuss
On Sun, Feb 20, 2011 at 11:08:05PM -0300, Han-Wen Nienhuys wrote: 2011/2/20 Han-Wen Nienhuys hanw...@gmail.com: This change is default over current lily, so let's put it in. I can't this change is an improvement over current lily It took me a lng time see any difference between the two alternatives. Having done so, I think I prefer alternative 1. Either would be in improvement over current behaviour. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: transition between full-length and shortened stems - please discuss
2011/2/21 Han-Wen Nienhuys hanw...@gmail.com: Can you make your code be less hardcoded? I propose something like: factor = (1+abs(hp[dir])) / (2*staff_radius + 1) shorten *= min(factor, 1.0) What staff_radius is? I tried to find an explanation, but to no avail... this way, it will work with other types of staves too. If you want to be extra fancy, you could do factor = pow(factor, shorten_concavity) for some number != 1 to tune shape of the transition. I think it's not necassary. Btw, i think that using a power here wouldn't give good results. If we really wanted to control the shape of the transition, we would need some other function (perhaps a little sophisticated one). 2011/2/21 Bernard Hurley bern...@marcade.biz: It took me a lng time see any difference between the two alternatives. Having done so, I think I prefer alternative 1. Either would be in improvement over current behaviour. :) I also prefer 1. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOC: NR 1.5.2 Multiple voices - part combining (issue4188056)
http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely File Documentation/notation/simultaneous.itely (right): http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode846 Documentation/notation/simultaneous.itely:846: change the state permanently. If I may make a suggestion for this whole paragraph? --snip-- In professional scores, voices are often kept apart for long periods - even if one or two notes actually coincide and could easily be printed as @emph{unisono}. Combining notes into a chord, or to print one voice as solo is therefore not ideal as the @code{\partcombine} function considers each note separately. For this reason, the @code{\partcombine} function can be overriden with the following commands: --snip-- I have moved that final sentence below the list http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode852 Documentation/notation/simultaneous.itely:852: chord or unisono. Again do we @emph{} unisono? I assume this is a musical term and not just a mis-translation of foreign usage? http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode856 Documentation/notation/simultaneous.itely:856: Combine the notes to a chord. There was much discussion on 'chord' vs 'not chord' unrelated to this, but still enough to worry some. So is 'chord' the correct term here? I have no preference but am just pre-empting discussion. http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode860 Documentation/notation/simultaneous.itely:860: The two voices are unisono. @emph{unisono} http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode872 Documentation/notation/simultaneous.itely:872: Use the combination strategy automatically determined. Can we be more descriptive on what the 'automatic' strategy is? Or we could simply say Let the software decide which is the best option. I want to not use the word 'strategy'. http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode874 Documentation/notation/simultaneous.itely:874: @end itemize Now add the final sentence from above: All commands ending in @code{...Once} apply only to the following note. --- It is therefore implicit and unnecessary to state what the code that doesn't end in 'once' does. So I have removed that sentence. http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode880 Documentation/notation/simultaneous.itely:880: \partcombineChords e'^chord e | If we do change the word 'chord' above then we need to change it here too. http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode891 Documentation/notation/simultaneous.itely:891: c2 c If we're going to have bar checks then we need one on the last bar http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode897 Documentation/notation/simultaneous.itely:897: \new Staff \partcombine \instrumentOne \instrumentTwo If we do keep this @lilypond (see comment below) I'd like to see {} after the new Staff for clarity. \new Staff { \instrumentOne } \new Staff { \instrumentTwo } \new Staff { \partcombine \instrumentOne \instrumentTwo } http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode899 Documentation/notation/simultaneous.itely:899: @end lilypond Maybe I have missed something but this looks a tad complicated for an @lilypond and would be better served as a snippet instead. We don't often use variables like this in @lilypond except when explicitly discussing variables. http://codereview.appspot.com/4188056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: transition between full-length and shortened stems - please discuss
2011/2/21 Janek Warchoł lemniskata.bernoull...@gmail.com: 2011/2/21 Han-Wen Nienhuys hanw...@gmail.com: Can you make your code be less hardcoded? I propose something like: factor = (1+abs(hp[dir])) / (2*staff_radius + 1) shorten *= min(factor, 1.0) What staff_radius is? I tried to find an explanation, but to no avail... Look for Staff_symbol_reference::staff_radius. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOC: NR 1.5.2 Multiple voices - part combining (issue4188056)
revised patch uploaded. http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely File Documentation/notation/simultaneous.itely (right): http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode846 Documentation/notation/simultaneous.itely:846: change the state permanently. On 2011/02/21 17:56:05, pkx166h wrote: If I may make a suggestion for this whole paragraph? --snip-- In professional scores, voices are often kept apart for long periods - even if one or two notes actually coincide and could easily be printed as @emph{unisono}. Combining notes into a chord, or to print one voice as solo is therefore not ideal as the @code{\partcombine} function considers each note separately. For this reason, the @code{\partcombine} function can be overriden with the following commands: --snip-- I have moved that final sentence below the list Done. http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode852 Documentation/notation/simultaneous.itely:852: chord or unisono. On 2011/02/21 17:56:05, pkx166h wrote: Again do we @emph{} unisono? I assume this is a musical term and not just a mis-translation of foreign usage? I believe unisono is a Dutch usage, so I've changed it to unison, although it is hardwired into the names of functions like \partCombineUnisono. http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode856 Documentation/notation/simultaneous.itely:856: Combine the notes to a chord. On 2011/02/21 17:56:05, pkx166h wrote: There was much discussion on 'chord' vs 'not chord' unrelated to this, but still enough to worry some. So is 'chord' the correct term here? I have no preference but am just pre-empting discussion. I think it's safe, given the names of the commands. Whether the commands are correctly named may be another discussion! http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode860 Documentation/notation/simultaneous.itely:860: The two voices are unisono. On 2011/02/21 17:56:05, pkx166h wrote: @emph{unisono} As above. http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode872 Documentation/notation/simultaneous.itely:872: Use the combination strategy automatically determined. On 2011/02/21 17:56:05, pkx166h wrote: Can we be more descriptive on what the 'automatic' strategy is? Or we could simply say Let the software decide which is the best option. I want to not use the word 'strategy'. Done. http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode874 Documentation/notation/simultaneous.itely:874: @end itemize On 2011/02/21 17:56:05, pkx166h wrote: Now add the final sentence from above: All commands ending in @code{...Once} apply only to the following note. --- It is therefore implicit and unnecessary to state what the code that doesn't end in 'once' does. So I have removed that sentence. Done. http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode880 Documentation/notation/simultaneous.itely:880: \partcombineChords e'^chord e | On 2011/02/21 17:56:05, pkx166h wrote: If we do change the word 'chord' above then we need to change it here too. Done. http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode891 Documentation/notation/simultaneous.itely:891: c2 c On 2011/02/21 17:56:05, pkx166h wrote: If we're going to have bar checks then we need one on the last bar Done. http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode897 Documentation/notation/simultaneous.itely:897: \new Staff \partcombine \instrumentOne \instrumentTwo On 2011/02/21 17:56:05, pkx166h wrote: If we do keep this @lilypond (see comment below) I'd like to see {} after the new Staff for clarity. \new Staff { \instrumentOne } \new Staff { \instrumentTwo } \new Staff { \partcombine \instrumentOne \instrumentTwo } Done. http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode899 Documentation/notation/simultaneous.itely:899: @end lilypond On 2011/02/21 17:56:05, pkx166h wrote: Maybe I have missed something but this looks a tad complicated for an @lilypond and would be better served as a snippet instead. We don't often use variables like this in @lilypond except when explicitly discussing variables. It may be more confusing to write it without variables; \partcombine is certainly easier to do *with* than without, and I believe the example is nearly unreadable without variables. Other tastes are of course different! http://codereview.appspot.com/4188056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org
Re: transition between full-length and shortened stems - please discuss
2011/2/21 Han-Wen Nienhuys hanw...@gmail.com: 2011/2/21 Janek Warchoł lemniskata.bernoull...@gmail.com: 2011/2/21 Han-Wen Nienhuys hanw...@gmail.com: Can you make your code be less hardcoded? I propose something like: factor = (1+abs(hp[dir])) / (2*staff_radius + 1) shorten *= min(factor, 1.0) What staff_radius is? I tried to find an explanation, but to no avail... Look for Staff_symbol_reference::staff_radius. Ah. i looked in staff-symbol-referencer.hh, while the answer was in staff-symbol-referencer.cc : return (line_count (me) - 1) / 2.0; silly me. I'll cook appropriate function tomorrow. Thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
On Fri, Feb 18, 2011 at 7:46 PM, k-ohara5...@oco.net wrote: Why not use a sequence of Rationals [..] to represent the alteration? A single Rational can hold the series as a sum, and preserve the separability of the terms, if we use mutually prime denominators. In scales where cih is identical to ciseh, ciseh can be +1/2 - 1/4 = 1/4. In scales where cih is logically distinct from ciseh, ciseh can be +1/2 - 1/5. I know that, but 1. The separability will go out the window if people start transposing by these amounts. +1/1 - 1/5 = 3/10. Transpose by that 5 times, and you have 15/10 = 3; the quarter tones have gone. I realize this concern is mostly academic. 2. If what we really want to represent is a sequence of numbers (and I gather it is), we should make the internal representation a sequence too. If we use rational numbers, we can maintain backward compatibility. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Draws a line above footnotes (issue4167063)
http://codereview.appspot.com/4167063/diff/3018/lily/note-head.cc File lily/note-head.cc (right): http://codereview.appspot.com/4167063/diff/3018/lily/note-head.cc#newcode189 lily/note-head.cc:189: footnote Any particular reason this belongs to note-head-interface (rather than, say, item-interface)? http://codereview.appspot.com/4167063/diff/3018/lily/page-breaking.cc File lily/page-breaking.cc (right): http://codereview.appspot.com/4167063/diff/3018/lily/page-breaking.cc#newcode516 lily/page-breaking.cc:516: Page_breaking::draw_page (SCM systems, SCM footnotes, SCM configuration, int page_num, bool last) Surely draw_page can extract the footnotes from the systems rather than taking them as an argument? Then you don't have to keep passing them around, and you get support for the other page breaking algorithms for free. http://codereview.appspot.com/4167063/diff/3018/lily/page-layout-problem.cc File lily/page-layout-problem.cc (right): http://codereview.appspot.com/4167063/diff/3018/lily/page-layout-problem.cc#newcode65 lily/page-layout-problem.cc:65: Stencil mol; Why not make the separator a (stencil-valued) property of the paper-book? http://codereview.appspot.com/4167063/diff/3018/lily/page-spacing.cc File lily/page-spacing.cc (right): http://codereview.appspot.com/4167063/diff/3018/lily/page-spacing.cc#newcode81 lily/page-spacing.cc:81: for (vsize i = 0; i line.footnotes_.size (); i++) You'll need to do this in append_system also. http://codereview.appspot.com/4167063/diff/3018/lily/system.cc File lily/system.cc (right): http://codereview.appspot.com/4167063/diff/3018/lily/system.cc#newcode623 lily/system.cc:623: footnote_search (Grob *g, vsize start, vsize end, vectorStencil** s) Have you checked the performance of this? This part is linear and so it makes break_into_pieces quadratic. Also, you can make it simpler by iterating through all-elements instead of recursing through elements. http://codereview.appspot.com/4167063/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Hey, lilypond-devel complained about the recipient list of this message, so I am resending it. Sorry for those who are receiving it for the second time. -- Forwarded message -- Hello everyone, First of all, thanks for the extensive comments made on this. I will try to address the major topics in this mail. Sorry if I miss anything. === 1. Issue header Nitpick: if this were called something like change internal pitch representation in the first line of the patch, I would have looked earlier. From a casual glance at my mailbox, it looked like it would be a simple bugfix patch for issue 1278. I should remind you that this patch was at first only casually posted as a background for a discussion I started by the end of the last year, see http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00726.html I am taking this review as a continuation of that discussion. So, for those of you who did not follow that, I will give relevant pointers below. For now, I think you really should check the attachments in http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00730.html I will occasionally make references to towards123, which is attached in http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00729.html - 2. int vs Rational Why not use a sequence of Rationals (rather than ints) to represent the alteration? If we use rational numbers, we can maintain backward compatibility. The re-scaling of the alterations is interesting but unnecessary. They could still be rationals. That is a very reasonable idea. Its main advantage would be, as pointed, in more robust backwards compatibility, as well as ease of implementation. If you decide for that, I can work on a new patch. Further considerations of mine might be found below question 1.1 in http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00729.html and after the last quote in http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00737.html - 3. Transposition you have to set a rule that (0 . 1) + (0 . 1) = (1 . 0). No, we don't. Transposing c to cis takes cis to cisis, not to d. If you are not using arrow notation, you can define a quarter tone to be (1 . 0). Also, see the next topic, for further discussion. - 4. Normalisation Many objections regarding transposition in my current patch, or in LilyPond's current behaviour, are related to what I am calling normalisation. This is what may cause musical transposition to look complicated, it really is not. My considerations on the subject can be found in Section 3 of towards123. - 5. Scale 1 I think that the arguments to make-scale should not have implicit steps (which they currently do) Steps _mean_ position on Scale, which in its turn means position in the staff. I assume this to uniquely determine one of the coefficients in the group representation of the pitch. The vector argument to make-scale then just specifies what alteration is attached to each position when no accidental is added to it. This well models every notation system I have come across. Besides, a notation system in which this did not work would either need some specific algorithm to determine the staff position of a pitched note, or not work with transpositions well. - 6. Scale 2 The alteration sizes aren't part of the default scale. It's counter intuitive to set them in that function. Firstly, the default scale effectively is just the static part of the C++ Pitch class, except when you instantiate a Pitch, then reset the default scale, and then use that Pitch (which will refer to the old scale). Secondly, see my considerations on Section 1 of towards123. - 7. Default arguments in ly:make-pitch I don't see why ly:make-pitch can't take a single rational as the alteration, and assign it as the first alteration in the majority of cases where that's what you want. Whether we to decide for ints or for Rationals, I completely agree that make-pitch should have optional arguments. Even the alteration itself should be optional. The single reason why I chose not to enable that in this patch was to track parts of the code that would need rewriting, by making the code break until I edited them. I was particularly concerned with the commits made after my patch, that could silently invalidate it. Of course, none of this would have to be undertaken with a Rational pair/list representation. === If you have any further questions, or if you think that I forgot something, please write. Also: Should I write a new version of this patch using Rational instead of int? I look forward to hearing from you. Regards, Felipe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Question about @lilypond options for creating smaller page examples within our Doc
On Mon, Feb 21, 2011 at 11:47:18AM +, James Lowe wrote: It seems to me that I cannot create an explicit output size by specifying height and width dimensions, like I can specify a line length within a @lilypond [xxx] variable. Hmm. Is there a difference between width dimension and line length ? (non-rhetorical question; I honestly don't know) So I thought that if we had a 'custom' entry in the scm/paper.scm file - I experimented with some sizes and it seems that having a height of 35mm is enough to get a line of music, a header/title and a footer - that we could simply refer to that within the @lilypond [xxx] variables. But I cannot see what option to use or if it is possible. Oh, that would be a nice idea. Like a tinypage paper size. I do not believe that we can use a [pagesize=xyz] option in lilypond-book yet, but adding this could be a nice Frog task. (not for James, but for somebody else) If nobody points out a better way of doing this, let's add a feature request to the tracker. I could just explicitly put a \paper {} variable within the @lilypond construct but this isn't as neat and I can't see which option to use in the @lilypond [xxx] variable to force it to use the \paper {} either. Definitely agreed there! Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: 48-hour notice for markuplines crash and toc lines
Thurs 9am. Assuming we want \markuplines { } to behave like \markup { } (i.e., produce a \null toplevel markup), then this patch works, since it ensures a valid Paper_score in paper-book.cc: http://codereview.appspot.com/4160059/ Add dots to tocItemMarkup http://codereview.appspot.com/4182056/ Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel