|
|
Created:
12 years, 11 months ago by pkx166h Modified:
12 years, 7 months ago CC:
lilypond-devel_gnu.org Visibility:
Public. |
DescriptionDoc: NR clarified \footnote command as a TextScript
While chorded notes *require* the \footnote command attached
as a TextScript, normal notes can _also_ be attached like that.
The original description stated the command *must* come before
single notes.
Patch Set 1 #
Total comments: 4
Patch Set 2 : Second patch with Trevor's suggestions #Patch Set 3 : changes to examples and text for '<>\footnote' #
Total comments: 17
Patch Set 4 : Corrections spotted by David. Will require one more patch - see comments #
Total comments: 18
Patch Set 5 : Corrections for \breathe. More text corrs. Thanks Keith. Added @cindexes too. #
Total comments: 15
Patch Set 6 : More corrections to syntax and grammar. Thanks Keith and JCM #
Total comments: 4
Patch Set 7 : More minor corrections (thanks Graham). #MessagesTotal messages: 23
http://codereview.appspot.com/6137050/diff/1/Documentation/notation/input.itely File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/1/Documentation/notation/input.ite... Documentation/notation/input.itely:1050: footnote is being attached but can also be attached as a isn't a textscript also a grob? if so, you don't need to add that in the text. The example carries that story.
Sign in to reply to this message.
http://codereview.appspot.com/6137050/diff/1/Documentation/notation/input.itely File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/1/Documentation/notation/input.ite... Documentation/notation/input.itely:1050: footnote is being attached but can also be attached as a On 2012/04/30 07:39:21, Graham Percival wrote: > isn't a textscript also a grob? if so, you don't need to add that in the text. > The example carries that story. Possibly, I don't actually know the technical difference, I was following the examples I did previously (if you scan down to the start of the 'manual' footnotes and the 'chorded' notes I've just tried tied to be consistent and that is what I used there. That was based on comments by Mike (and possibly David when he made his changes), so if TextScript and Grob are interchangeable I should make the changes throughout the @nodes than just here. If someone can let me know?
Sign in to reply to this message.
Hi James Alternative text suggested. Trevor http://codereview.appspot.com/6137050/diff/1/Documentation/notation/input.itely File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/1/Documentation/notation/input.ite... Documentation/notation/input.itely:1050: footnote is being attached but can also be attached as a On 2012/05/02 06:01:47, J_lowe wrote: > if TextScript and Grob are interchangeable They're not. A TextScript is one particular type of Layout Object. It's not really a Graphical Object (grob), although the distinction between Layout and Graphical Objects has been lost now. And these terms should only be used to reference items in the output document. Regarding the change itself, you don't need to add anything here - the second form is already documented a few lines lower. But, ideally, these two examples should be combined using something like: "The command @code{\footnote} can be placed before the item to which the footnote is to be attached or immediately after it as an annotation. The latter form is the only way to annotate items within a chord."
Sign in to reply to this message.
http://codereview.appspot.com/6137050/diff/1/Documentation/notation/input.itely File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/1/Documentation/notation/input.ite... Documentation/notation/input.itely:1050: footnote is being attached but can also be attached as a On 2012/05/04 08:57:14, Trevor Daniels wrote: > On 2012/05/02 06:01:47, J_lowe wrote: > > > if TextScript and Grob are interchangeable > They're not. A TextScript is one particular type of Layout Object. It's not > really a Graphical Object (grob), although the distinction between Layout and > Graphical Objects has been lost now. And these terms should only be used to > reference items in the output document. > > Regarding the change itself, you don't need to add anything here - the second > form is already documented a few lines lower. But, ideally, these two examples > should be combined using something like: "The command @code{\footnote} can be > placed before the item to which the footnote is to be attached or immediately > after it as an annotation. The latter form is the only way to annotate items > within a chord." Done. Also combined the 2 x 2 @lilypond into 2 x 1 @lilypond. Edited the xy co-ords. on the chorded notes as it was starting to run into the staff above.
Sign in to reply to this message.
Ok, everybody will love me for my late thinking again. But here we go: we have two cases of footnotes: one that will attach itself to whatever happens at a given point of time, being an independent event. Those footnotes, having a natural duration of 0, come (unless they are in simultaneous music) _before_ the things they attach themselves to, possibly restricted by Grob type so that they don't grab too much. Then you can use footnotes as _articulations_. Then they come behind what they refer to, separated by - ^ _. I think that's less intuitive than necessary. I propose we _always_ let them try to attach themselves as postevents/articulations, by defining the footnote command with define-event-function. Then the - before the footnote call is optional, like it is with things like \p. I think that makes more sense to explain. Yes, it is a nuisance to rewrite the documentation _again_, but everything else is really not all that helpful. Strictly speaking, this would also require a convert-ly rule, but I can't think of a good one.
Sign in to reply to this message.
<dak@gnu.org> wrote Friday, May 04, 2012 8:43 PM > Ok, everybody will love me for my late thinking again. But here we go: :) > we have two cases of footnotes: one that will attach itself to whatever > happens at a given point of time, being an independent event. > I propose we _always_ let > them try to attach themselves as postevents/articulations, by defining > the footnote command with define-event-function. Then the - before the > footnote call is optional, like it is with things like \p. > > I think that makes more sense to explain. Definitely! > Yes, it is a nuisance to > rewrite the documentation _again_, Sorry James, but I agree with David - any simplification is well worth it. @David: will you action the change? > http://codereview.appspot.com/6137050/
Sign in to reply to this message.
On 2012/05/04 20:21:14, t.daniels_treda.co.uk wrote: > <mailto:dak@gnu.org> wrote Friday, May 04, 2012 8:43 PM > > > > I think that makes more sense to explain. > > Definitely! I totally agree. Only allow articulation footnotes. Much clearer. Make a convert-ly rule that gives a warning if you have the footnote event, but leave it there. Thanks, Carl
Sign in to reply to this message.
New patch set uploaded for the <> change.
Sign in to reply to this message.
http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1050: is to be attached but in that case, it must be preceded by a @code{<>}; Seems like I caused you unnecessary work by being unclear. I am sorry for that. <> is a stopgap measure created by convert-ly since automatic change to postevent position of the real event is not feasible. \footnote should be documented as purely being a postevent, and the examples should be changed accordingly from the state after automatic conversion. Any explanation of <> or s1*0 belongs in a different part of the manual generally talking about how to deal with postevents you have no anchor for. The state after the automatic conversion is not really acceptible in documentation: it only has the advantage of maintaining functionality. http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1059: <>\footnote #'(0.5 . -2) #'NoteHead So this, for example, should be changed to a'4\footnote #'(0.5 . -2) #'NoteHead \markup { The first note } b8 e\footnote #'(0.5 , 1) #'NoteHead \markup { The third note } c4 and so on. http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1068: % Chorded Notes "Notes inside of a chord can be given individual footnotes." or something like this should be mentioned. http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1072: g\footnote #'(2 . 2) \markup { \bold "This is a G" } Visual correction here? http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1089: \footnote #'(-3 . 0) #'DynamicText Doesn't this give an error? The footnotes are not in postevent position. I think they would need to move after a'4. Similar for the following notes. http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1138: Like automatic footnotes, the @code{\footnote} command can be placed See above: I'd not mention <> at all. http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1148: <>\footnote Now I am baffled. Reintroducing <> manually? Or was this copy&paste for some reason? http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1177: \footnote See above. I should be surprised if this works unless you move the \footnote after a'4.
Sign in to reply to this message.
See inline. One more patch will be needed. http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1050: is to be attached but in that case, it must be preceded by a @code{<>}; On 2012/05/12 14:25:08, dak wrote: > Seems like I caused you unnecessary work by being unclear. I am sorry for that. > <> is a stopgap measure created by convert-ly since automatic change to > postevent position of the real event is not feasible. Ah ok. I see. I.e. you cannot make convert-ly change where the '\footnote' command 'string' is in the .ly file so in this pre-event(?) you just stick <> in place so it works. > \footnote should be documented as purely being a postevent, and the examples > should be changed accordingly from the state after automatic conversion. Any > explanation of <> or s1*0 belongs in a different part of the manual generally > talking about how to deal with postevents you have no anchor for. OK. > > The state after the automatic conversion is not really acceptible in > documentation: it only has the advantage of maintaining functionality. Yes I see now. http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1059: <>\footnote #'(0.5 . -2) #'NoteHead On 2012/05/12 14:25:08, dak wrote: > So this, for example, should be changed to > a'4\footnote #'(0.5 . -2) #'NoteHead > \markup { The first note } > b8 e\footnote #'(0.5 , 1) #'NoteHead > \markup { The third note } > c4 > and so on. Done. http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1068: % Chorded Notes On 2012/05/12 14:25:08, dak wrote: > "Notes inside of a chord can be given individual footnotes." or something like > this should be mentioned. I've reworded it to be less specific than that. But the examples and the new text should now indicate this fact more clearly than before. http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1072: g\footnote #'(2 . 2) \markup { \bold "This is a G" } On 2012/05/12 14:25:08, dak wrote: > Visual correction here? Yes. I thought the indicator was too close to the measure 'above' - its an a8 page size remember? This show the footnotes at the 'bottom' of the page without needing huge space (for bigger page size), so you only get one measure per line. Unless you compile this example I can see how this correction might not make sense. http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1089: \footnote #'(-3 . 0) #'DynamicText On 2012/05/12 14:25:08, dak wrote: > Doesn't this give an error? The footnotes are not in postevent position. I > think they would need to move after a'4. Similar for the following notes. Yes you are correct. Thanks for spotting. I ran all (or thought 'all') the example through a lilypond-book template that I have, one at a time, so I could tweak-and-fiddle examples quickly - without having to build the whole doc. I obviously missed this one! http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1138: Like automatic footnotes, the @code{\footnote} command can be placed On 2012/05/12 14:25:08, dak wrote: > See above: I'd not mention <> at all. Done. http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1148: <>\footnote On 2012/05/12 14:25:08, dak wrote: > Now I am baffled. Reintroducing <> manually? Or was this copy&paste for some > reason? Sigh - sorry. The <> was left in (because I didn't understand the post event thing you discussed above. The rest of the example was when I noticed that some lines caused the ugly black bars to appear in the PDF output (when your line length exceeds certain length) so again I had to fiddle-and-tweak the example to remove those. Hopefully it is ok now. http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1177: \footnote On 2012/05/12 14:25:08, dak wrote: > See above. I should be surprised if this works unless you move the \footnote > after a'4. Yes again, it was simply going up and down in the texi file that I missed this. However I now cannot work out how to footnote the '\breathe' mark as wherever I put the \breathe command I get an error. I have left it in for now commented out in case this is simply not understanding where it goes, or if this is a change in the footnote behaviour since this code change. This is different from the above example because I think that manual footnotes were the only way at the time to footnote things like this (that weren't attached to 'normal notes' so to speak), but it's all a bit hazy.
Sign in to reply to this message.
Looks good to me. I honestly tried to use a footnote a couple months ago, but gave up trying to figure it out. Now I think the docs are pretty clear. http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1044: Automatic footnotes take three arguments; the @var{Layout Object} to be maybe "Automatically-numbered footnotes" http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1076: higher up in the list.} Do you mean that footnotes on the same chord are numbered and listed in order the vertical positions of their indicators, G Eb C ? If that is it, you might want it in normal text rather than a warning. (I had to look up 'descendancy', so my problem might have just been my English comprehension.) http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1128: Manual footnotes takes four arguments; the @var{Layout Object} to be maybe "Footnotes with manually-chosen indicators take" and in any case, "take" http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1159: higher up in the list.} From experiment, it seems that, a set of footnotes on one chord are listed at the bottom of the page according to the vertical order of their indicators. -- which is quite nice. http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1181: Works for me to put here, \breathe http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1185: \markup { \bold 4. { This is a stem } } and then here \footnote \markup { \teeny \musicglyph #"rests.4" } #'(-0.5 . 0.5) #'BreathingSign \markup { \null } In rhythms were you usually see a breath mark, it is printed just before the next note. Breathing just after two eight notes is a little odd, but it would take some re-arranging of the example to make it realistic, and maybe not worth it.
Sign in to reply to this message.
http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... Documentation/notation/input.itely:1073: >1 >2 \breathe c2 \footnote #'(0.5 . 0.5) #'BreathingSign \markup { Breathe } The \breathe example is more normal-looking here.
Sign in to reply to this message.
On 2012/05/12 18:36:56, Keith wrote: > http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... > File Documentation/notation/input.itely (right): > > http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... > Documentation/notation/input.itely:1073: >1 > >2 > > \breathe > c2 > \footnote #'(0.5 . 0.5) #'BreathingSign \markup { Breathe } > > The \breathe example is more normal-looking here. Not exactly the most intuitive order I have to say. \breathe does not take a postevent, though, so the alternative would be the use of <>\footnote or equivalent, either before or after \breathe itself: \breathe creates an event without duration. This is one case where the postevent order is not helpful, because the thing you want to modify itself does not take a postevent. Putting the postevent on c2 instead delivers it at the right point of time, but this is plainly counterintuitive.
Sign in to reply to this message.
On 2012/05/12 19:11:44, dak wrote: > On 2012/05/12 18:36:56, Keith wrote: > > > http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... > > File Documentation/notation/input.itely (right): > > > > > http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... > > Documentation/notation/input.itely:1073: >1 > > >2 > > > > \breathe > > c2 > > \footnote #'(0.5 . 0.5) #'BreathingSign \markup { Breathe } > > > > The \breathe example is more normal-looking here. > > Not exactly the most intuitive order I have to say. \breathe does not take a > postevent, though, so the alternative would be the use of > <>\footnote or equivalent, either before or after \breathe itself: > \breathe creates an event without duration. > > This is one case where the postevent order is not helpful, because the thing you > want to modify itself does not take a postevent. Putting the postevent on c2 > instead delivers it at the right point of time, but this is plainly > counterintuitive. c2 \footnote #'(0.5 . 0.5) #'BreathingSign \markup { Breathe } -\breathe does work: turning \breathe explicitly into a postevent makes the arrangement in toto somewhat more natural, even though having the \breathe after the note is a bit surprising. But a bit less jarring than the alternative.
Sign in to reply to this message.
On 2012/05/12 19:25:34, dak wrote: > On 2012/05/12 19:11:44, dak wrote: > > On 2012/05/12 18:36:56, Keith wrote: > > > > > > http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... > > > File Documentation/notation/input.itely (right): > > > > > > > > > http://codereview.appspot.com/6137050/diff/11001/Documentation/notation/input... > > > Documentation/notation/input.itely:1073: >1 > > > >2 > > > > > > \breathe > > > c2 > > > \footnote #'(0.5 . 0.5) #'BreathingSign \markup { Breathe } > > > > > > The \breathe example is more normal-looking here. > > > > Not exactly the most intuitive order I have to say. \breathe does not take a > > postevent, though, so the alternative would be the use of > > <>\footnote or equivalent, either before or after \breathe itself: > > \breathe creates an event without duration. > > > > This is one case where the postevent order is not helpful, because the thing > you > > want to modify itself does not take a postevent. Putting the postevent on c2 > > instead delivers it at the right point of time, but this is plainly > > counterintuitive. > > c2 > \footnote #'(0.5 . 0.5) #'BreathingSign \markup { Breathe } > -\breathe > > does work: turning \breathe explicitly into a postevent makes the arrangement in > toto somewhat more natural, even though having the \breathe after the note is a > bit surprising. > > But a bit less jarring than the alternative. Sigh. I take that back. It is more or less a historical accident that \breathe is defined as a music function (and thus can be used in the place of an explicit postevent). The purported reason told in comments in music-function-init.ly for that redefinition does not exist anymore, and the plainer replacement breathe = #(make-music 'BreathingEvent) does not work as postevent, so comparable expressions would also not work. That's really starting to look like a case for <>\footnote or equivalent. Or leave it like Keith proposed.
Sign in to reply to this message.
On Sat, 12 May 2012 12:11:45 -0700, <dak@gnu.org> wrote: > >> \breathe >> c2 >> \footnote #'(0.5 . 0.5) #'BreathingSign \markup { Breathe } > > Not exactly the most intuitive order I have to say. True. Good to document it, I guess. http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1049: The @code{\footnote} command comes immediately after the item being "... comes after the note or rest associated with the item being annotated" to be more accurate for the odd things like the breath mark. And as you show later, if you have dynamics and a slur on a sharped note, you can type the \footnote for the sharp after \f( -- which might be convenient. http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1069: >1 maybe bring the example for #'Accidental up here, too, where there is more space in the typeset output ? >1 \breathe cis2 \footnote #'(0.5 . 0.5) #'BreathingSign \markup { Gasp} \footnote #'(0.5 , 0.5) #'Accidental \markup { Chromatic }
Sign in to reply to this message.
New patch set uploaded http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1044: Automatic footnotes take three arguments; the @var{Layout Object} to be On 2012/05/12 18:23:23, Keith wrote: > maybe "Automatically-numbered footnotes" This made me re-think the titling of both these sections, so I have re-titled them to something more descriptive and adjusted the body text accordingly. http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1049: The @code{\footnote} command comes immediately after the item being On 2012/05/12 21:01:35, Keith wrote: > "... comes after the note or rest associated with the item being annotated" > to be more accurate for the odd things like the breath mark. And as you show > later, if you have dynamics and a slur on a sharped note, you can type the > \footnote for the sharp after \f( -- which might be convenient. Done. http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1069: >1 On 2012/05/12 21:01:35, Keith wrote: > maybe bring the example for #'Accidental up here, too, where there is more space > in the typeset output ? > > >1 > \breathe > cis2 > \footnote #'(0.5 . 0.5) #'BreathingSign \markup { Gasp} > \footnote #'(0.5 , 0.5) #'Accidental \markup { Chromatic } > Done. Thanks. http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1076: higher up in the list.} On 2012/05/12 18:23:23, Keith wrote: > Do you mean that footnotes on the same chord are numbered and listed in order > the vertical positions of their indicators, G Eb C ? If that is it, you might > want it in normal text rather than a warning. > (I had to look up 'descendancy', so my problem might have just been my English > comprehension.) Done. http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1076: higher up in the list.} On 2012/05/12 18:23:23, Keith wrote: > Do you mean that footnotes on the same chord are numbered and listed in order > the vertical positions of their indicators, G Eb C ? If it is a chord yes, but you can have multiple 'grobs' that are not in chords but come at the same vertical position too. I am not sure now. Mike's turn of phrase might have been ambiguous when giving me answers to questions on footnotes when I was writing this up but he might have meant the same 'moment' in this case, but I am not sure if this is 1. Correct technically 2. Same vertical position is, in this context, synonymous with same 'moment' on the staff or not. 3. If it is do we want to get into explaining 'moments' in this case? > If that is it, you might > want it in normal text rather than a warning. > (I had to look up 'descendancy', so my problem might have just been my English > comprehension.) I removed the @warning, and used a simpler phrase, that will also make for easier translation in the other languages. http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1128: Manual footnotes takes four arguments; the @var{Layout Object} to be On 2012/05/12 18:23:23, Keith wrote: > maybe "Footnotes with manually-chosen indicators take" I've changed this based on the new section heading. > and in any case, "take" Done. (and also in the automatically numbered section too) http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1159: higher up in the list.} On 2012/05/12 18:23:23, Keith wrote: > From experiment, it seems that, a set of footnotes on one chord are listed at > the bottom of the page according to the vertical order of their indicators. -- > which is quite nice. I've changed this wording as per the automatically numbered section too. http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1181: On 2012/05/12 18:23:23, Keith wrote: > Works for me to put here, \breathe Done. http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1185: \markup { \bold 4. { This is a stem } } On 2012/05/12 18:23:23, Keith wrote: > and then here > \footnote > \markup { \teeny \musicglyph #"rests.4" } > #'(-0.5 . 0.5) #'BreathingSign > \markup { \null } > > In rhythms were you usually see a breath mark, it is printed just before the > next note. I guess I don't see that in my own music, I picked up a few random scores and they all came at or on the bar line. >Breathing just after two eight notes is a little odd Hmm... you obviously don't play marching brass music ;) > but it would > take some re-arranging of the example to make it realistic, and maybe not worth > it. Probably not. I could use another grob if people really objected. http://codereview.appspot.com/6137050/diff/8003/Documentation/notation/input.... Documentation/notation/input.itely:1185: \markup { \bold 4. { This is a stem } } On 2012/05/12 18:23:23, Keith wrote: > and then here > \footnote > \markup { \teeny \musicglyph #"rests.4" } > #'(-0.5 . 0.5) #'BreathingSign > \markup { \null } > > In rhythms were you usually see a breath mark, it is printed just before the > next note. Breathing just after two eight notes is a little odd, but it would > take some re-arranging of the example to make it realistic, and maybe not worth > it. Done.
Sign in to reply to this message.
Big change, still very clear. http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1048: the order in which each indicator, and so footnotes, are created during "each... footnote is" http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1075: \footnote #'(0.5 , 0.5) #'Accidental \markup { Chromatic } r2 to square up the bar http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1080: When footnotes have the same vertical position they are printed in In this case, maybe the word "moment" is best : "When several footnotes mark items at the same moment in the music, they are printed..." http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1144: are created during compilation. "each.. is"
Sign in to reply to this message.
http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1075: \footnote #'(0.5 , 0.5) #'Accidental \markup { Chromatic } Eek! Comma in place of a dot! My typo, but never trust me with Scheme. Silly programming language with all its picky distinctions between tiny bits of punctuation.
Sign in to reply to this message.
Nitpicks, but I had to read twice and carefully the first paragraph and I'm not sure to understand. http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1037: customize footnote indicators to suit. More digestible (?): Footnotes can be crated for all grobs, TL markup or chord, either with automatically incrementing numbers or customized footnote indicators. http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1140: command comes after the note or rest associated with the item being one "command" is enough!
Sign in to reply to this message.
New Patch. Thanks Keith and Jean-Charles http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1037: customize footnote indicators to suit. On 2012/05/13 09:46:59, Jean-Charles wrote: > More digestible (?): > Footnotes can be crated for all grobs, TL markup or chord, either with > automatically incrementing numbers or customized footnote indicators. Done. http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1048: the order in which each indicator, and so footnotes, are created during On 2012/05/13 02:23:09, Keith wrote: > "each... footnote is" Done. http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1075: \footnote #'(0.5 , 0.5) #'Accidental \markup { Chromatic } On 2012/05/13 02:23:09, Keith wrote: > r2 > to square up the bar Done. http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1075: \footnote #'(0.5 , 0.5) #'Accidental \markup { Chromatic } On 2012/05/13 02:23:09, Keith wrote: > r2 > to square up the bar Done. http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1075: \footnote #'(0.5 , 0.5) #'Accidental \markup { Chromatic } On 2012/05/13 02:32:36, Keith wrote: > Eek! Comma in place of a dot! > My typo, but never trust me with Scheme. Silly programming language with all > its picky distinctions between tiny bits of punctuation. Don't worry, I always do my own make doc just before pushing just to make doubly sure (I have no excuse!). Done. http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1080: When footnotes have the same vertical position they are printed in On 2012/05/13 02:23:09, Keith wrote: > In this case, maybe the word "moment" is best : > "When several footnotes mark items at the same moment in the music, they are > printed..." Done. http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1140: command comes after the note or rest associated with the item being On 2012/05/13 09:46:59, Jean-Charles wrote: > one "command" is enough! Done. http://codereview.appspot.com/6137050/diff/14003/Documentation/notation/input... Documentation/notation/input.itely:1144: are created during compilation. On 2012/05/13 02:23:09, Keith wrote: > "each.. is" Done.
Sign in to reply to this message.
LGTM http://codereview.appspot.com/6137050/diff/22001/Documentation/notation/input... File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/22001/Documentation/notation/input... Documentation/notation/input.itely:1044: Automatically numbered footnotes take three arguments; the I think this should be a full colon: http://codereview.appspot.com/6137050/diff/22001/Documentation/notation/input... Documentation/notation/input.itely:1136: Customized footnotes take four arguments; the @var{Layout Object} to be another :
Sign in to reply to this message.
New patch http://codereview.appspot.com/6137050/diff/22001/Documentation/notation/input... File Documentation/notation/input.itely (right): http://codereview.appspot.com/6137050/diff/22001/Documentation/notation/input... Documentation/notation/input.itely:1044: Automatically numbered footnotes take three arguments; the On 2012/05/14 18:52:01, Graham Percival wrote: > I think this should be a full colon: Done. http://codereview.appspot.com/6137050/diff/22001/Documentation/notation/input... Documentation/notation/input.itely:1136: Customized footnotes take four arguments; the @var{Layout Object} to be On 2012/05/14 18:52:01, Graham Percival wrote: > another : Done.
Sign in to reply to this message.
|