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
