Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
Am 31.10.2010 00:07, schrieb Neil Puttock: On 30 October 2010 22:40, Marc Hohlm...@hohlart.de wrote: File /home/marc/git/lilypond/python/out/book_snippets.py, line 561, in compose_ly if self.global_options.safe_mode: AttributeError: Values instance has no attribute 'safe_mode' I don't think this has anything to do with your patch. It looks like lilypond-book is out of date (the safe_mode option was only added a week or two ago). Oops, sorry. I do a git pull nearly every day, but probably I rebased the branch containing the tie stuff not very recently ... Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
Hello Carl, wow, you were fast ... LGTM ;-) As said before, I wouldn't be able to do this engraver myself, but I think I understand now a tiny bit better how c++ engraver work. Thank you, Marc http://codereview.appspot.com/2723043/diff/1/lily/tab-tie-follow-engraver.cc File lily/tab-tie-follow-engraver.cc (right): http://codereview.appspot.com/2723043/diff/1/lily/tab-tie-follow-engraver.cc#newcode34 lily/tab-tie-follow-engraver.cc:34: are present. IMHO, the description should be more detailed, e.g. Change the tab-note-head properties when a tie is followed by a slur or a glissando. http://codereview.appspot.com/2723043/diff/1/lily/tab-tie-follow-engraver.cc#newcode145 lily/tab-tie-follow-engraver.cc:145: Adjust tabNoteHead properties when accuring with ties, uppercase: TabNoteHead http://codereview.appspot.com/2723043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
I may be missing something, but doesn't this assume all line spanners are glissandi? Trevor http://codereview.appspot.com/2723043/diff/1/lily/tab-tie-follow-engraver.cc File lily/tab-tie-follow-engraver.cc (right): http://codereview.appspot.com/2723043/diff/1/lily/tab-tie-follow-engraver.cc#newcode69 lily/tab-tie-follow-engraver.cc:69: glissandi_.push_back (info.grob ()); Does this not catch line spanners other than glissandi?? http://codereview.appspot.com/2723043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
On 2010/10/31 09:29:29, Trevor Daniels wrote: I may be missing something, but doesn't this assume all line spanners are glissandi? I thought the same thing. I haven't investigated it carefully; I was just translating Marc's Scheme engraver to C++. Any comments, Mark? Thanks, Carl http://codereview.appspot.com/2723043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
I've updated the comments and the doc string, and added a check for Glissando. Thanks, Carl http://codereview.appspot.com/2723043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)
On Sun, Oct 31, 2010 at 4:33 AM, carl.d.soren...@gmail.com wrote: I've put a new patch up on Rietveld, with the Scheme engraver moved to a C++ engraver to avoid the challenges with documentation. Thanks Carl! In the meantime, I've opened http://code.google.com/p/lilypond/issues/detail?id=1375 as a brainstorming session for Scheme engravers. Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: Removed [fragment] from @lilypond examples NR (issue2810041)
Reviewers: ,
Message:
Docs look ok, but I'm not 100% certain about the changes to chords, or
whether Trevor wants us changing vocal.itely.
(this is a git-cl-merge of James Lowe's initial doc patch, and a few
fixes I applied to that one; I don't think it's worth separating this
into two separate patch-sets, but if you want, I could do that)
Description:
Doc: fixes for previous patch.
Doc: Removed [fragment] from @lilypond examples NR
Where appropriate replaced with [relative] or added { } construct within
@lilypond example
All except ancient.itely have been amended because some ancient music
examples gave unexpected results.
Please review this at http://codereview.appspot.com/2810041/
Affected files:
M Documentation/notation/changing-defaults.itely
M Documentation/notation/cheatsheet.itely
M Documentation/notation/chords.itely
M Documentation/notation/fretted-strings.itely
M Documentation/notation/input.itely
M Documentation/notation/percussion.itely
M Documentation/notation/pitches.itely
M Documentation/notation/spacing.itely
M Documentation/notation/vocal.itely
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rextend macro sometimes repeats a word
Le 31/10/2010 02:42, Francisco Vila disait : 2010/10/30 Graham Percivalgra...@percival-music.ca: On Sat, Oct 30, 2010 at 01:51:14AM +0200, Francisco Vila wrote: 2010/10/30 Francisco Vilapaconet@gmail.com: this is to ask if anyone, besides me, has noticed that rextend macro sometimes prints a repeated word before the link, and the word is the last of the phrase argument. Yes, back in 2008. Wait another half a moment! Can arguments to @footnote and/or @rextend be split across lines? if not, that could explain it. Yes, that's the cause. fr/tweaks.itely does split the @rextendnamed argument at the very end of the file, and the output at LM 4.6.6 is fine! That's not fair! http://lilypond.org/doc/v2.13/Documentation/learning/advanced-tweaks-with-scheme.fr.html After a quick check, it seems that this is the only instance of a split in a @rXXX macro argument. I do my best to avoid splitting any of them. The only particularity of this very case is that I use the /named/ version of the macro, and only the second argument get split, what might explain it works. Have a nice Sunday, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Removed [fragment] from @lilypond examples NR (issue2810041)
I've only reviewed the chords section, since Graham was unsure about it. I think that it most cases, there should be no \relative in these sections. Thanks, Carl http://codereview.appspot.com/2810041/diff/1/Documentation/notation/chords.itely File Documentation/notation/chords.itely (right): http://codereview.appspot.com/2810041/diff/1/Documentation/notation/chords.itely#newcode140 Documentation/notation/chords.itely:140: @lilypond[quote,ragged-right,verbatim,relative=1] I don't think any of these \chordmode examples should use relative, even though it's there in some of the previous file. We don't need to surround \chordmode with \relative. In fact, as the documentation says, all pitches in \chordmode are interpreted as absolute. I've tested this, just to make sure. I guess it doesn't hurt to have it this way, as the code compiles. But I would question manual code that had \chordmode surrounded with \relative, so I think it would be best to omit the \relative. http://codereview.appspot.com/2810041/diff/1/Documentation/notation/chords.itely#newcode814 Documentation/notation/chords.itely:814: @lilypond[verbatim,quote,ragged-right,relative=1] Figures also ignore octaves (in fact, the octave makes no sense to a figure), so please eliminate the relative here, as well. I think the relative should only be included with figures: 1. When there are notes, and 2. When we want the notes in relative mode. I don't think there are any examples like this in this section. http://codereview.appspot.com/2810041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Removed [fragment] from @lilypond examples NR (issue2810041)
On 2010/10/31 13:54:01, Carl wrote: I think the relative should only be included with figures: 1. When there are notes, and 2. When we want the notes in relative mode. Ok, I've removed all [relative=?] unless there's a combination of notes with \chordmode or \figures. Will upload once the docs finished compiling from scratch. http://codereview.appspot.com/2810041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond 2.13.38
Since the spacing alist bug seemed to be a problem for people experimenting with the spacing stuff, I went ahead with 2.13.38 to get that bugfix out there. Bug squad: Phil is busy with the opening of a musical, so it would be nice if somebody else could check the regression test comparisons for both 2.13.37 and 2.13.38. It would be a shame if some horrible bug was introduced in the past two weeks and nobody noticed. The next release will probably be labelled a beta test. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Clef support for cue notes
Clef support for cue notes -) Added \cleffedCueDuring, which allows to specify a clef for the cue notes. At the end of the cue section, the clef is automatically reset to the containing voice's clef. -) Cue clefs are implemented as CueClef and CueEndClef grobs, created by a dedicated Cue_clef_engraver, which reads some cueClef* context properties. -) After a line break, a cue clef does NOT override the global clef of the containing voice, but prints (in smaller size) after the containing clef. http://codereview.appspot.com/2726043/ Regtest showing how things work is included. Please review, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Music function extension...
Han-Wen Nienhuys hanw...@gmail.com writes: On Fri, Oct 29, 2010 at 8:46 AM, David Kastrup d...@gnu.org wrote: Are there good reasons left for not allowing music functions to take pitches as arguments? That would allow implementing something like how would you encode the pitch though? Does \func cis'' parse to FUNCTION PITCH or FUNCTION Music ? (PITCH - single note - Music ; names may not be exact wrt parser.yy) Perhaps I have not put myself forward reasonably clearly: the idea was not just to use a predicate in the function signature, but to let that predicate be special-cased in the parser. The function expands to a number of tokens representing the signature constituents (that is already being done, we just need another token type), and then those signature tokens are used for interpreting the actually upcoming tokens. So cis'' would never get interpreted or read as sequential music, but indeed only as a pitch specification. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Music function extension...
Valentin Villenave valen...@villenave.net writes:
On Sun, Oct 31, 2010 at 5:29 PM, David Kastrup d...@gnu.org wrote:
Perhaps I have not put myself forward reasonably clearly: the idea was
not just to use a predicate in the function signature, but to let that
predicate be special-cased in the parser. The function expands to a
number of tokens representing the signature constituents (that is
already being done, we just need another token type), and then those
signature tokens are used for interpreting the actually upcoming tokens.
Then we'd end up breaking all backwards compatibility with the old
\relative { c' d e }
syntax, wouldn't we? (Since \relative would expect a pitch, not a
music expression.)
Huh? Why would \relative be affected?
Besides, apart from \relative and \transpose, how many actual commands
would require a pitch argument?
I really don't understand what you are talking about.
I was talking about the ability to _define_ music functions taking a
pitch argument. Not about changing existing commands.
For all other commands, especially music-functions, the ability to
have an argument that's either a single note or a whole music
expression is a (really really nice) feature, not a bug :)
When I define a music command that requires a _pitch_ as an argument,
trying to extract that pitch from a whole sequential music expression is
both a nuisance as well as error-prone.
For example, I want to define a music function that takes a pitch and a
music expression as arguments, then wraps all of the music expression
into the octave starting at the specified pitch.
There is absolutely no sense in specifying anything but just a pitch for
that first argument. There is no way to make feature out of anything
but a pitch. Anything apart from just a pitch is going to be user input
error, and should be treated as one as directly as possible, namely in
the parser, rather than having a second-guessing engine declare failure
or result in unexplicable behavior.
Whilst (I think) I understand your proposal, I'm not sure I see the
advantages it would bring; could you give us some examples? From a
user point of view, what difference would it make? (Other than
possibly making the syntax slightly less fault-tolerant?)
Less fault-tolerant? There is absolute no _use_ in tolerating a fault
for which there is no sensible way to deal with.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clef support for cue notes (issue2726043)
Hi Reinhold, it certainly looks good! I haven't tested your patch set though, so these are just a couple of nitpicks off the top of my head. http://codereview.appspot.com/2726043/diff/1/input/regression/cue-clef.ly File input/regression/cue-clef.ly (right): http://codereview.appspot.com/2726043/diff/1/input/regression/cue-clef.ly#newcode4 input/regression/cue-clef.ly:4: texidoc = Clefs for cue notes: Normal clefs should be printed, and in addition Is it Normal that this word is capitalized? http://codereview.appspot.com/2726043/diff/1/lily/pitch-scheme.cc File lily/pitch-scheme.cc (right): http://codereview.appspot.com/2726043/diff/1/lily/pitch-scheme.cc#newcode175 lily/pitch-scheme.cc:175: } Just out of curiosity: have you checked that it isn't affected by #466? http://codereview.appspot.com/2726043/diff/1/ly/engraver-init.ly File ly/engraver-init.ly (right): http://codereview.appspot.com/2726043/diff/1/ly/engraver-init.ly#newcode79 ly/engraver-init.ly:79: Are you sure that we want to \consist the Cue_clef_engraver by default? Most of the time, it won't be needed at all... (I'm searching for a way to conditionally load it when needed, but I can't find any though.) http://codereview.appspot.com/2726043/diff/1/ly/music-functions-init.ly File ly/music-functions-init.ly (right): http://codereview.appspot.com/2726043/diff/1/ly/music-functions-init.ly#newcode219 ly/music-functions-init.ly:219: (make-cue-clef-set type)) I'm not sure this is the proper indentation for .ly code. http://codereview.appspot.com/2726043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clef support for cue notes (issue2726043)
On Sun, Oct 31, 2010 at 07:32:50PM +, v.villen...@gmail.com wrote: http://codereview.appspot.com/2726043/diff/1/input/regression/cue-clef.ly#newcode4 input/regression/cue-clef.ly:4: texidoc = Clefs for cue notes: Normal clefs should be printed, and in addition Is it Normal that this word is capitalized? In correct English, that word would be capitalized. However, most people don't bother to write that well. So it's not normal to see this capitalized correctly. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clef support for cue notes (issue2726043)
http://codereview.appspot.com/2726043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clef support for cue notes (issue2726043)
Oops, somehow I've just created an empty comment. http://codereview.appspot.com/2726043/diff/1/ly/music-functions-init.ly File ly/music-functions-init.ly (right): http://codereview.appspot.com/2726043/diff/1/ly/music-functions-init.ly#newcode238 ly/music-functions-init.ly:238: cleffedCueDuring = I very much dislike this name. What about \cueDuringWithClef? English speaking people are very creative in creating verbs out of nouns, but somehow `cleffed' really hurts to me... http://codereview.appspot.com/2726043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On Fri, 29 Oct 2010 21:04:06 -0700, lilypond-devel-requ...@gnu.org wrote: Mark Polesky wrote Friday, October 29, 2010 11:27 PM I've thought about it, and I think I slightly favor the term loose line over non-staff line [...] Also loose-staff-spacing sounds too much like something that gives staves a loose spacing (rather than a tight spacing) to anyone coming to this for the first time. Thanks for doing this, Mark. It seems you want a one-word _noun_, to refer to either a line of lyrics and a line of dynamics, in the limited context of its placement relative to the neighboring staffs, and similar lines of lyrics/dynamics. Simply 'line' ? Remember the user cannot see why they are called loose -- maybe indirectly in the way these lines are placed in a second step after the staff lines, but the docs about that second step do not use the word 'loose'. The visible difference from regular staffs is that lyrics/dynamics have an affinity. They are attached, in their spacing behavior, to one a parent staff, or centered between two parent staffs, and negotiate with their siblings for space. - Keith ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR: Move Modifying alists from 4.1.2 to 5.3. (issue2767043)
Reviewers: , Message: This patch... 1) adds a node to NR 5.3 Modifying properties that explains alist-modifying in a generic way, and 2) removes the similar material from NR 4.1.2 Page formatting. However, there are two statements I want to make, but I'm not certain if they are entirely true: 1) If an alist is a grob property or \paper variable, its keys can be modified individually without affecting other keys. Is this true for all grob properties and \paper variables? Are there any other classes of alists that allow setting keys individually with nested declarations? 2) Nested declarations will not work for context property alists (such as beamExceptions, keySignature, timeSignatureSettings, etc.). These properties can only be modified by completely re-defining them as alists. Is this correct? Or are there some context property alists that can accept a nested declaration to set one key? If the statement is incorrect, is there a pattern to the exceptions, or is it some sort of case-by-case basis? If both statements are correct, is this okay to push? Thanks! - Mark Description: Doc: NR: Move Modifying alists from 4.1.2 to 5.3. Please review this at http://codereview.appspot.com/2767043/ Affected files: M Documentation/notation/changing-defaults.itely M Documentation/notation/spacing.itely ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clef support for cue notes (issue2726043)
On Sun, Oct 31, 2010 at 8:43 PM, Graham Percival gra...@percival-music.ca wrote: In correct English, that word would be capitalized. However, most people don't bother to write that well. So it's not normal to see this capitalized correctly. :) Interesting. Could you elaborate? On Sun, Oct 31, 2010 at 8:59 PM, lemzw...@googlemail.com wrote: I very much dislike this name. What about \cueDuringWithClef? English speaking people are very creative in creating verbs out of nouns, but somehow `cleffed' really hurts to me... Ditto. I didn't want to point this out, but cleffed is plain ugly (at least to my French ears ;) Cheers. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
Hi Carl, This is too complicated (though that's really a criticism of Marc's Scheme engraver). The point of using 'tie-follow is that it defers the decision to parenthesize TabNoteHead to the point where it matters: in the callbacks for Glissando and Slur. Thus there should be no need to acknowledge glissandos and slurs in the engraver: we only need to check whether the tie's right bound is one of the acknowledged noteheads. Cheers, Neil http://codereview.appspot.com/2723043/diff/7001/lily/tab-tie-follow-engraver.cc File lily/tab-tie-follow-engraver.cc (right): http://codereview.appspot.com/2723043/diff/7001/lily/tab-tie-follow-engraver.cc#newcode69 lily/tab-tie-follow-engraver.cc:69: if (info.grob ()-name () == Glissando) If you needed to distinguish glissandos from other lines, it would be more idiomatic to add an interface (glissando-interface), then use info.grob-internal_has_interface (ly_symbol2scm (glissando-interface)) http://codereview.appspot.com/2723043/diff/7001/lily/tab-tie-follow-engraver.cc#newcode98 lily/tab-tie-follow-engraver.cc:98: scm_from_int (LEFT)); slurs_[j]-get_bound (LEFT) http://codereview.appspot.com/2723043/diff/7001/lily/tab-tie-follow-engraver.cc#newcode99 lily/tab-tie-follow-engraver.cc:99: if (scm_call_1 (ly_lily_module_constant (ly:grob?), left_bound) == SCM_BOOL_T) I'm not sure this serves any useful purpose; unless there's something seriously wrong, all slur bounds are grobs (of class Item). http://codereview.appspot.com/2723043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Clef support for cue notes (issue2726043)
-Original Message- From: lilypond-devel-bounces+james.lowe=datacore@gnu.org on behalf of Valentin Villenave Sent: Sun 31/10/2010 22:12 To: Graham Percival Cc: re...@codereview.appspotmail.com; lilypond-devel@gnu.org Subject: Re: Clef support for cue notes (issue2726043) On Sun, Oct 31, 2010 at 8:43 PM, Graham Percival gra...@percival-music.ca wrote: In correct English, that word would be capitalized. However, most people don't bother to write that well. So it's not normal to see this capitalized correctly. :) Interesting. Could you elaborate? -- If it's being used as a 'proper noun' it would be capitalised. But it seems the rules are slightly different for American English (which our Docs are in), here from wikipedia (so it must be true!) In English, the word following the colon is in lower case unless it is a proper noun or an acronym, or if it is normally capitalized for some other reason. However, in American English a colon may be followed either by a capital letter or by a lower-case letter, depending on usage; where direct speech follows, a capital letter is used; where an acronym or proper noun follows, a capital is used; otherwise, a lower-case letter is used. Some modern American style guides, including those published by the Associated Press and the Modern Language Association, prescribe capitalization where the colon is followed by an independent clause (i.e. a complete sentence). However, The Chicago Manual of Style requires capitalization only when the colon introduces two or more complete sentences. So either this is a proper noun or an independent clause. James PS It looks wrong to my eyes BTW (but I'm not American...or Canadian ;) ) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
On 2010/10/31 22:24:17, Neil Puttock wrote: Hi Carl, This is too complicated (though that's really a criticism of Marc's Scheme engraver). The point of using 'tie-follow is that it defers the decision to parenthesize TabNoteHead to the point where it matters: in the callbacks for Glissando and Slur. Thus there should be no need to acknowledge glissandos and slurs in the engraver: we only need to check whether the tie's right bound is one of the acknowledged noteheads. Ah, yes. I hadn't thought through the logic carefully; I was just implementing Marc's logic in C++. Glissandos and slurs are irrelevant for determining tied-to. A note is tied-to if it's at the right hand end of a tie. Whether it's parenthesized or not is determined by the presence of a split tie, a glissando, or a slur. So we don't need to acknowledge glissando or slur. Just tie and note_head. Got it! Thanks, Carl http://codereview.appspot.com/2723043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
On 2010/10/31 22:24:17, Neil Puttock wrote: http://codereview.appspot.com/2723043/diff/7001/lily/tab-tie-follow-engraver.cc#newcode69 lily/tab-tie-follow-engraver.cc:69: if (info.grob ()-name () == Glissando) If you needed to distinguish glissandos from other lines, it would be more idiomatic to add an interface (glissando-interface), then use info.grob-internal_has_interface (ly_symbol2scm (glissando-interface)) This is going away, so it won't apply to this patch (because we don't need to acknowledge glissandos). But if we did, and we added a glissando-interface, then instead of Tab_tie_follow_engraver::acknowledge_line_spanner wouldn't we just use Tab_tie_follow_engraver::acknowledge_glissando? But it would seem strange to me to add an interface with no properties that can be set, which is what I think I'd be doing if I added a glissando_interface. Any comment on this thought? Thanks, Carl http://codereview.appspot.com/2723043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clef support for cue notes (issue2726043)
On Sun, Oct 31, 2010 at 11:26 PM, James Lowe james.l...@datacore.com wrote: If it's being used as a 'proper noun' it would be capitalised. I fail to see how it is a proper noun. Clefs that are normal - adjective, isn't it? But it seems the rules are slightly different for American English (which our Docs are in), here from wikipedia (so it must be true!) capitalization where the colon is followed by an independent clause (i.e. a complete sentence). This clause doesn't exist in French. Has to be what Graham was referring to. PS It looks wrong to my eyes BTW (but I'm not American...or Canadian ;) ) What makes it look wrong is also that we do not have such grobs as NormalClef or whatever... Thank you for the explanation; nice to see that some people still speak proper English :) Cheers! Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
On 2010/10/31 22:40:57, Carl wrote: This is going away, so it won't apply to this patch (because we don't need to acknowledge glissandos). But if we did, and we added a glissando-interface, then instead of Tab_tie_follow_engraver::acknowledge_line_spanner wouldn't we just use Tab_tie_follow_engraver::acknowledge_glissando? Yes. But it would seem strange to me to add an interface with no properties that can be set, which is what I think I'd be doing if I added a glissando_interface. Any comment on this thought? If you look in define-grob-interfaces.scm, you'll see several interfaces with no properties: most of them exist just to allow engravers to distinguish between grobs which would normally be lumped together (e.g., acknowledging line-spanner-interface, when you really want something more specific). Cheers, Neil http://codereview.appspot.com/2723043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
New patch set with simplified engraver -- it only acknowledges ties and note-heads, and it still works. Thanks, Neil! Carl http://codereview.appspot.com/2723043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR: Move Modifying alists from 4.1.2 to 5.3. (issue2767043)
On 2010/10/31 21:54:41, Mark Polesky wrote: This patch... 1) adds a node to NR 5.3 Modifying properties that explains alist-modifying in a generic way, and 2) removes the similar material from NR 4.1.2 Page formatting. However, there are two statements I want to make, but I'm not certain if they are entirely true: 1) If an alist is a grob property or \paper variable, its keys can be modified individually without affecting other keys. Is this true for all grob properties and \paper variables? Are there any other classes of alists that allow setting keys individually with nested declarations? I think this is right for grob properties that are nested property alists, meaning that the keys are symbols. As far as I know, this is true of all the grob alists. 2) Nested declarations will not work for context property alists (such as beamExceptions, keySignature, timeSignatureSettings, etc.). These properties can only be modified by completely re-defining them as alists. timeSignatureSettings and beamExceptions are not nested property alists. They are properties with alist values. The keys to the alist that is the property value are not symbols, so the standard nested property alist methods don't apply there. Also, grob properties can be modified with \override, so the new property is prepended to the old, and the old properties still exist. Context properties cannot be modified with \override. They must be modified with \set, which redefines the full value of the context property and thus requires the full alist to be given. We had a discussion a while ago, and Han-wen was opposed to using nested overrides for context properties, so I developed a special handler for timeSignatureSettings. So in summary, I believe your statements are correct. Thanks, Carl Is this correct? Or are there some context property alists that can accept a nested declaration to set one key? If the statement is incorrect, is there a pattern to the exceptions, or is it some sort of case-by-case basis? If both statements are correct, is this okay to push? Thanks! - Mark http://codereview.appspot.com/2767043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On 10/31/10 3:00 PM, Keith E OHara k-ohara5...@oco.net wrote: On Fri, 29 Oct 2010 21:04:06 -0700, lilypond-devel-requ...@gnu.org wrote: Mark Polesky wrote Friday, October 29, 2010 11:27 PM I've thought about it, and I think I slightly favor the term loose line over non-staff line [...] Also loose-staff-spacing sounds too much like something that gives staves a loose spacing (rather than a tight spacing) to anyone coming to this for the first time. Thanks for doing this, Mark. It seems you want a one-word _noun_, to refer to either a line of lyrics and a line of dynamics, in the limited context of its placement relative to the neighboring staffs, and similar lines of lyrics/dynamics. Simply 'line' ? I think 'line' could easily be confused with a staff line. I think perhaps 'nonstaff' would be better. So we could have nonstaff-staff-spacing Remember the user cannot see why they are called loose -- maybe indirectly in the way these lines are placed in a second step after the staff lines, but the docs about that second step do not use the word 'loose'. But they might, once the terminology is finalized. The visible difference from regular staffs is that lyrics/dynamics have an affinity. They are attached, in their spacing behavior, to one a parent staff, or centered between two parent staffs, and negotiate with their siblings for space. This is a nice statement! Thanks! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
Further thought about this causes me to think the engraver should just be Tie_follow_engraver It doesn't change a TabNoteHead property, it changes a NoteHead property. The only reason it applies to TabNoteHeads is because it is in a TabVoice context. Am I wrong in thinking this? Thanks, Carl http://codereview.appspot.com/2723043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
Or perhaps the engraver should only listen to tab-note-heads, instead of to note-heads, since the tie-follow property is part of the tab-note-head interface. Thanks, Carl http://codereview.appspot.com/2723043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
