Re: Doc: NR: Move Modifying alists from 4.1.2 to 5.3. (issue2767043)
Looks ok as far as cutpaste goes, but I think it could use more work as a piece of our documentation. http://codereview.appspot.com/2767043/diff/1/Documentation/notation/changing-defaults.itely File Documentation/notation/changing-defaults.itely (right): http://codereview.appspot.com/2767043/diff/1/Documentation/notation/changing-defaults.itely#newcode2014 Documentation/notation/changing-defaults.itely:2014: My eyes are already starting to glaze over, and I'm not even halfway through the section. Could we get a @lilypond in here? Ideally a @lilypond showing all methods of setting these things, but at the minimum showing just one method. http://codereview.appspot.com/2767043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
Am 31.10.2010 23:24, schrieb n.putt...@gmail.com: Hi Carl, This is too complicated (though that's really a criticism of Marc's Scheme engraver). Thank you, Neil, for pointing this out! I was referring to your engraver example which checked for slurs, too, and I overlooked the fact that the slur callback just does the right thing when tie-follow is set. Sorry for causing so much trouble. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Le 01/11/2010 00:09, Carl Sorensen disait : On 10/31/10 3:00 PM, Keith E OHarak-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! May I suggest my point of view, which includes some taste of translation: I need in my score at least four containers: one line containing the staff (grid with a certain number of strokes), one line containing the dynamics, one line containing the lyrics, and one line containing the figured bass. The last three are not loose since their material is synchronized with the information displayed on the staff. At this point, everybody knows what a staff is, and what are the others: an alignment of characters, or at least not a staff. Then I would prefer the dichotomy staff vs. non-staff (being labeled nonstaff in grobs or properties). This was the thought of the day. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: improve 2.10 World music (issue2732043)
Reviewers: , Message: Hi everybody, here's a patch that will make Trevor happy: no more musics! :-) Please have a look; I am currently building the docs to make sure that it doesn't break anything, but I'm hopeful. Cheers. Description: Doc: improve 2.10 World music * Move Turkish note names table in the relevant subsection; * Add glossary entries (with stubs) * Add @seealso whereever possible * Improve wording, consistency. Please review this at http://codereview.appspot.com/2732043/ Affected files: M Documentation/music-glossary.tely M Documentation/notation/world.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 31/10/2010 22:50, Valentin Villenave wrote: On Sun, Oct 31, 2010 at 11:26 PM, James Lowejames.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? Yes I suppose, but if you substitute 'Normal' for something like 'Mensural' (if that is correct) or to use an erroneous example 'Eastern' as in Eastern Clefs which are 'Clefs from the East' it could apply. I wasn't confident enough in my knowledge of the whole musical lexicon to know that perhaps, in some parts of Music Notation (see what I did there?), a 'Normal' clef might be something specific. I've already shown my ignorance on the mail-lists (system vs score) so I was hedging my bets here. ;) James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
On 11/1/10 1:53 AM, Marc Hohl m...@hohlart.de wrote: Sorry for causing so much trouble. No trouble, Marc. You never need to apologize for working to improve LilyPond! Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Download server unavailable
Hi everybody, for the past 48 hours at least, downloading GUB binaries (for any version, any arch) has been impossible. The server does respond, but downloading is very slow and eventually times out (after having downloaded a mere 400KB or so). I can still use home-built LilyPond binaries, but we certainly don't want normal users to do that. Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: improve 2.10 World music (issue2732043)
http://codereview.appspot.com/2732043/diff/3001/Documentation/music-glossary.tely File Documentation/music-glossary.tely (right): http://codereview.appspot.com/2732043/diff/3001/Documentation/music-glossary.tely#newcode8765 Documentation/music-glossary.tely:8765: @node Non-Western terms A-Z Somebody might object that we're codifying non-western instead of non-common practice period. I personally don't care one way or the other. If /you/ care, or at least want to be polite to people who /do/ care, then I propose that you open a fluffy debate on -user about these terms. If you just want to get stuff done, then ignore the whole thing and just use non-western terms, and blame me for telling you to get stuff done if anybody objects. http://codereview.appspot.com/2732043/diff/3001/Documentation/notation/world.itely File Documentation/notation/world.itely (right): http://codereview.appspot.com/2732043/diff/3001/Documentation/notation/world.itely#newcode25 Documentation/notation/world.itely:25: @node Non-Western notation and tuning systems Technically, this should be Common notation for non-Western music. Then within that subsection, you'd have an @unnumberedsubsubsec Non-Western tuning systems http://codereview.appspot.com/2732043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: improve 2.10 World music (issue2732043)
here's a patch that will make Trevor happy: no more musics! :-) :) Looks pretty good to me, apart from a couple of minor rephrasings. http://codereview.appspot.com/2732043/diff/3001/Documentation/notation/world.itely File Documentation/notation/world.itely (left): http://codereview.appspot.com/2732043/diff/3001/Documentation/notation/world.itely#oldcode348 Documentation/notation/world.itely:348: automatic beaming and beaming the notes manually. Where matching The alternative is to switch off automatic beaming and beam the notes manually. [one is rarely used today, other than in caricatures of royalty.] http://codereview.appspot.com/2732043/diff/3001/Documentation/notation/world.itely#oldcode350 Documentation/notation/world.itely:350: adjust the beaming behaviour and/or use compound time signatures. Even if a match to existing typeset music is not required it may still be desirable to adjust the beaming behaviour and/or use compound time signatures. http://codereview.appspot.com/2732043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clef support for cue notes (issue2726043)
Code not checked; and I still don't understand Scheme indentation, but at least it ought to be consistent. Trevor 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 On 2010/10/31 19:32:50, Valentin Villenave wrote: Is it Normal that this word is capitalized? Not normally, but in this case it is correct, even in English English. The part before the colon is a heading, and the actual sentence begins after the colon, so has a capitalised first word. http://codereview.appspot.com/2726043/diff/1/lily/cue-clef-engraver.cc File lily/cue-clef-engraver.cc (right): http://codereview.appspot.com/2726043/diff/1/lily/cue-clef-engraver.cc#newcode108 lily/cue-clef-engraver.cc:108: if (!clef_) Indentation? http://codereview.appspot.com/2726043/diff/1/scm/define-context-properties.scm File scm/define-context-properties.scm (right): http://codereview.appspot.com/2726043/diff/1/scm/define-context-properties.scm#newcode250 scm/define-context-properties.scm:250: (forceCueClef ,boolean? Show cue clef symbol, even if it has not spacing http://codereview.appspot.com/2726043/diff/1/scm/define-grobs.scm File scm/define-grobs.scm (right): http://codereview.appspot.com/2726043/diff/1/scm/define-grobs.scm#newcode572 scm/define-grobs.scm:572: (break-align-anchor . ,ly:break-aligned-interface::calc-extent-aligned-anchor) Indentation http://codereview.appspot.com/2726043/diff/1/scm/define-grobs.scm#newcode594 scm/define-grobs.scm:594: (break-align-anchor . ,ly:break-aligned-interface::calc-extent-aligned-anchor) Indentation http://codereview.appspot.com/2726043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: improve 2.10 World music (issue2732043)
OK, new patch set. On Mon, Nov 1, 2010 at 4:22 PM, percival.music...@gmail.com wrote: Somebody might object that we're codifying non-western instead of non-common practice period. I personally don't care one way or the other. I do. Hans has a point in saying that non-Western isn't quite appropriate; however there's no way we'll start putting acronyms in section titles (non-CPP), and Common Practice Period is just too long and confusing. What I really really dislike is World music. However I never objected or made a fuss about it, because I realize we need to give this section a title, and it has to be short and easy-to-get, no matter how obnoxious and crypto-colonialist it may otherwise sound. Technically, this should be Common notation for non-Western music. Then within that subsection, you'd have an @unnumberedsubsubsec Non-Western tuning systems Oh, that was what I've been looking for without realizing it! Indeed, it will make things much more consistent. On Mon, Nov 1, 2010 at 5:41 PM, tdanielsmu...@googlemail.com wrote: [one is rarely used today, other than in caricatures of royalty.] Oh, really? Then we are not amused. Even if a match to existing typeset music is not required it may still be desirable to adjust the beaming behaviour and/or use compound time signatures. I've added *automatic* beaming behaviour, as it makes a lot more sense to me. And now, how GTY does it L? :-) Valentin. ___ 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'm happy with the changes to vocal.itely, although ragged-right could also be removed in many (maybe all) of the @lilyponds. Trevor http://codereview.appspot.com/2810041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add tab-tie-follow-engraver (issue2723043)
Updated to only acknowledge tab-note-head, not note-head. Thanks, 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)
http://codereview.appspot.com/2767043/diff/1/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (right):
http://codereview.appspot.com/2767043/diff/1/Documentation/notation/changing-defaults.itely#newcode2014
Documentation/notation/changing-defaults.itely:2014:
On 2010/11/01 06:47:58, Graham Percival wrote:
My eyes are already starting to glaze over, and I'm not
even halfway through the section. Could we get a
@lilypond in here? Ideally a @lilypond showing all
methods of setting these things, but at the minimum
showing just one method.
Graham,
Is this better? I added two examples, but there's the
obvious problem of \paper variables being ignored from
within a @lilypond. CG 4.3.4 says:
If you are making an example demonstrating special
\paper{} values, contact the Documentation Editor.
Consider yourself contacted!
- Mark
http://codereview.appspot.com/2767043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
