Re: Best practices for Da Capo/Dal Segno/al Fine/etc.

On 2018-02-20 5:21 PM, I asked: > … what is the current (2.19) best practice for typesetting the Da > Capo/‌Dal Segno/‌al Fine/‌etc. repeat marks? I’m having some trouble extracting a readable-but-useful minimal example from my code, but this excerpt might help the next fellow: \include "poly-mar

Best practices for Da Capo/Dal Segno/al Fine/etc.

… what is the current (2.19) best practice for typesetting the Da Capo/‌Dal Segno/‌al Fine/‌etc. repeat marks? (Last time I saw this come up on the list, the discussion became about a proposed input syntax, `\repeat coda {…} \alternative {…}`––which I’ll certainly use if & when it’s implemented, b

Re: best practices with tempo markings

viola part \score { \new Staff << \struct \violaNotes >> } % cello part \score { \new Staff << \struct \celloNotes >> } % bass part \score { \new Staff << \struct \bassNotes >> } There are a variety of ways to customize this to your tastes and uses, bu

best practices with tempo markings

Hi all, This one really is basic, but: a \tempo command in a large score will automatically register on each part, right? that is, if I insert the marking to change tempo in the flute part in bar 2, it will appear on every other part...so where is it advisable to put it? Thanks. Tobin _

Re: [Best Practices] splitting and combining choral parts

p.s. To see the power of the system I’m trying to develop, add a manual line break at m. 8 (e.g., change line 103 to s4*2 \break s4*2), and then observe how the third system reacts. =) Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.in

Re: [Best Practices] splitting and combining choral parts

Hi, > Can we focus on how to achieve automatic frenching based on divisi? Thanks. =) > this seems like a lot of work. Well, I’m know it won’t be trivial… But I was hoping we could come up with a "Goldilocks solution”: a rather elegant way of handling it, with a minimum of effort on the engr

Re: [Best Practices] splitting and combining choral parts

ne, and assign lyrics to the voice. -- View this message in context: http://lilypond.1069038.n5.nabble.com/Best-Practices-splitting-and-combining-choral-parts-tp184051p184123.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-use

Re: [Best Practices] splitting and combining choral parts

Hi Simon, > The other major point is that it doesn’t print ‘redundant’ lyrics, i.e. > passages with equal rhythm and wording in multiple voices have the lyrics > printed only once, mostly below the topmost of the staves. I finally looked at this example. (Thanks again for including it!) 1. To

Re: [Best Practices] splitting and combining choral parts

Hi Michael, Thanks for your response… But people are apparently missing my point/question. I’m not asking for advice about LyricExtenders, or whether this particular score should be in four staves, or about the spacing of the staves and lyrics, or autobeaming, or anything like that. The closes

Re: [Best Practices] splitting and combining choral parts

u will see a great deal of frenching and part-combining and choral-unison-with-occasional-polyphony.*** And whether or not the particular example ("Wither’s Carol” mm. 1-17) that I included should or should not be in four staves is irrelevant. I think it’s the perfect example to work o

Re: [Best Practices] splitting and combining choral parts

> > Last not least for vocal lines I always turn off autoBeam and manually > > put beams to groups that are sung on a single syllable. For my singers > > eyes that strongly helps to keep words and music in a proper flow. > > It’s rather a question of rhythmic complexity; with long and/or > oft-cha

Re: [Best Practices] splitting and combining choral parts

On 24.11.2015 23:36, Kieren MacMillan wrote: And I like for long syllables to be increasingly left-aligned This is one of the many, many lyric-related problems in Lilypond. (See my numerous other posts and sponsorship offers on that topic.) I solve almost all of them post-hoc, using the editio

Re: [Best Practices] splitting and combining choral parts

On 25.11.2015 00:03, Michael Gerdau wrote: Last not least for vocal lines I always turn off autoBeam and manually put beams to groups that are sung on a single syllable. For my singers eyes that strongly helps to keep words and music in a proper flow. It’s rather a question of rhythmic complexi

Re: [Best Practices] splitting and combining choral parts

Hie Kieren and Simon, > first of all: Looks like a nice piece! Yes :) > Second: offtopic nitpicks. There are some superfluous LyricExtenders > there – I’d rather leave them out if they are very short. I agree on that one. > And I like for long syllables > to be increasingly left-aligned, f

Re: [Best Practices] splitting and combining choral parts

Hi Simon, > I’d vote to keep with four staves, at least in this example. For the record, I sometimes do that. One good example is “Go Thy Way”, a score of which you can see at . But that’s a short a cap

Re: [Best Practices] splitting and combining choral parts

Hi Simon, > first of all: Looks like a nice piece! Thanks! You can hear it at , if you’re interested. > Second: offtopic nitpicks. There are some superfluous LyricExtenders there – > I’d rather leave them out if they are very short I include all Lyr

Re: [Best Practices] splitting and combining choral parts

Hello Kieren, first of all: Looks like a nice piece! Second: offtopic nitpicks. There are some superfluous LyricExtenders there – I’d rather leave them out if they are very short. ( …) And note the mid-air bar-numbers, where they are aligne

[Best Practices] splitting and combining choral parts

Hello list, I’ve posted this question several times before, but the discussion always got truncated or derailed… I’m hoping this time we can work this through to a solution. Choral pieces tend to have both sections of polyphony (requiring 4 or more staves) and sections of homophony (requiring

Re: Best Practices for file structures, score and parts

On 02.10.2015 12:03, Malte Meyn wrote: I remember an issue with note names in german (and perhaps other languages) when you have several names (asas and ases) for the same pitch (a flat). I’m not sure whether this has been fixed. You might check at the issue tracker:

Re: Best Practices for file structures, score and parts

On 02/10/2015 08:58, N. Andrew Walsh wrote: do I enter the transposing instruments into the score in concert pitch or transposed? Can Frescobaldi (my editor of choice) take an entire Voice and transpose it into concert pitch after I've edited, or should I enter the content in concert pitch (tra

Re: Best Practices for file structures, score and parts

Hi Malte, well, if I go by your setup, I could theoretically move the six \score blocks into my master file, so long as I rename the instruments for each movement (and then eventually for each mass as well, if I wanted to combine all six masses into one document), and then make a parts.ly file to

Re: Best Practices for file structures, score and parts

Andrew: > So, I'm in the process of transcribing some masses from part-books, and I'm > trying to figure out the best way to set up the file/variable/include > structure so that I have a minimum of clutter. > > There are six masses, with two brass (alternating between trumpet, horn, > and tacet),

Re: Best Practices for file structures, score and parts

Am 02.10.2015 um 09:58 schrieb N. Andrew Walsh: Is there a better way to structure the files? How do I extract the instrument variables into separate part files? Can I just \include all the separate movement files, and then add the Voice variables in sequence? In other words: each movement is a

Re: Best Practices for file structures, score and parts

Am 02.10.2015 um 09:58 schrieb N. Andrew Walsh: do I enter the transposing instruments into the score in concert pitch or transposed? Can Frescobaldi (my editor of choice) take an entire Voice and transpose it into concert pitch after I've edited, or should I enter the content in concert pitch

Best Practices for file structures, score and parts

Hi List, So, I'm in the process of transcribing some masses from part-books, and I'm trying to figure out the best way to set up the file/variable/include structure so that I have a minimum of clutter. There are six masses, with two brass (alternating between trumpet, horn, and tacet), tympani, t

Re: best practices for volta (was Re: Problem with repeat alternative endings that contain lyrics andleading rests)

Hi Trevor, >> You mean Lilypond can’t handle << \global \lyrics >>, where \global contains >> the repeat structure? > > Depends. Thanks for the clarification, and the various links. Interesting, all. I hope there’s an opportunity to fix this soon, and completely. Much like the irritating grac

Re: best practices for volta (was Re: Problem with repeat, alternative endings that contain lyrics andleading rests)

Hi, > I hope there is no intention to drop the MIDI output. Oh, goodness, no! Even though I don’t yet use it myself, I *want* to (soon), and I know it’s very important to others. Killer MIDI output would be a significant selling point for potential new users — along with MusicXML, it should b

Re: best practices for volta (was Re: Problem with repeat, alternative endings that contain lyrics andleading rests)

Gilles wrote Wednesday, April 22, 2015 11:52 AM > I hope there is no intention to drop the MIDI output. > For me, it is extremely useful to be able to figure out how > an arrangement will sound. > With all its shortcomings, it's still infinitely better than > nothing. :-) No, there's no suggesti

Re: best practices for volta (was Re: Problem with repeat, alternative endings that contain lyrics andleading rests)

Hello. [...] MIDI is widely acknowledged to be a relatively unimportant part of LP [...] I hope there is no intention to drop the MIDI output. For me, it is extremely useful to be able to figure out how an arrangement will sound. With all its shortcomings, it's still infinitely better than not

Fw: best practices for volta (was Re: Problem with repeat alternative endings that contain lyrics andleading rests)

From: "Trevor Daniels" To: "Kieren MacMillan" Sent: Wednesday, April 22, 2015 10:55 AM Subject: Re: best practices for volta (was Re: Problem with repeat alternative endings that contain lyrics andleading rests) Kieren MacMillan wrote Tuesday, April 21, 2015 3:19 PM

Re: best practices for volta (was Re: Problem with repeat, alternative endings that contain lyrics andleading rests)

Kieren MacMillan wrote Tuesday, April 21, 2015 2:13 PM > My question *was*, ultimately, more of a technical inquiry than a feature > request: I never use MIDI, or anything except visual output, so at least in > the foreseeable future this feature/bug/whatever has no noticeable impact on > my l

Re: best practices for volta (was Re: Problem with repeat alternative endings that contain lyrics andleading rests)

Hi Trevor, > Sure you did, but the point of the example the OP submitted from the NR was > to show how to allow lyrics to be unfolded along with the music. Ah. Sorry for the noise. >> 1. Shouldn’t we be [heavily] promoting, even in tiny snippets, the use of >> global variables to hold \repeat

Re: best practices for volta (was Re: Problem with repeat, alternative endings that contain lyrics andleading rests)

Hi Trevor, > I think the standard response to this is "patches welcome" ;) Touché! ;) > No doubt it could - but only if someone was prepared to put the effort into > coding it. My question *was*, ultimately, more of a technical inquiry than a feature request: I never use MIDI, or anything

Re: best practices for volta (was Re: Problem with repeat, alternative endings that contain lyrics andleading rests)

Kieren MacMillan wrote Monday, April 20, 2015 9:00 PM > Can \repeat not be defined so that — possibly with parameters/switches — it > will Do The Right Thing™ in all engraved (e.g., PDF), expressed (e.g., MIDI), > and other (e.g., MusicXML) output streams without requiring poor or > inefficien

Re: best practices for volta (was Re: Problem with repeat alternative endings that contain lyrics andleading rests)

Kieren MacMillan wrote Monday, April 20, 2015 5:05 PM > On Apr 19, 2015, at 6:11 AM, Trevor Daniels wrote: > >> [snip incomplete example] > > Is it really a best practice to put \repeat volta structures in multiple > locations? I just responded to a post a few days ago where (I believe, though

Re: best practices for volta (was Re: Problem with repeat, alternative endings that contain lyrics andleading rests)

Hi Mats, > No, that's asking for trouble! The code should primarily reflect the musical > interpretation, not just the notation. In know that it works to do as you > propose in many examples, but it clearly does not work if you use > \unfoldRepeats (in MIDI), for example. Can \repeat not be de

Re: best practices for volta (was Re: Problem with repeat, alternative endings that contain lyrics andleading rests)

On 04/20/2015 08:01 PM, Kieren MacMillan wrote: 1. Shouldn?t we be [heavily] promoting, even in tiny snippets, the use of global variables to hold \repeat structures that are used in multiple places? No, that's asking for trouble! The code should primarily reflect the musical interpretation

best practices for volta (was Re: Problem with repeat alternative endings that contain lyrics andleading rests)

Hi all, On Apr 19, 2015, at 6:11 AM, Trevor Daniels wrote: > \score { > << >\new Staff { > \time 2/4 > \new Voice = "melody" { >\relative c'' { > a4 a a a > \repeat volta 2 { b4 b } > \alternative { { \vrest b } { \vrest c } } >} > }

Re: Best practices in lyric typesetting

On Tue, Dec 18, 2012 at 11:59 AM, David Kastrup wrote: > Actually, singers don't like such things. It interferes with their > pitch sense. > > I think the "Carmina Burana" has some piece for a bass or baritone > falsettist and it is written in $#!! bass clef, with oodles of ledger > lines. No i

Re: Best practices in lyric typesetting

Werner LEMBERG writes: >>> "A line of text should be parallel to the stave for the length of >>> the system, and not be placed on different levels to accommodate >>> notes below the stave". >>> >>> This refers to lyrics. >>> >> >> I'll tell that to my singers as they tar and feather me. > > No

Re: Best practices in lyric typesetting

MS, > Putting aside the impossibility of the attached exercise, you'll see that the > lyrics stay shifted way down for the part of the attached example that moves > to D major. I ran into the reverse problem with pedal markings the other day: they were *not* aligned (and in fact seemed to beha

Re: Best practices in lyric typesetting

>> "A line of text should be parallel to the stave for the length of >> the system, and not be placed on different levels to accommodate >> notes below the stave". >> >> This refers to lyrics. >> > > I'll tell that to my singers as they tar and feather me. Now you know why different clefs do e

Re: Best practices in lyric typesetting

- Original Message - From: To: "Phil Holmes" Cc: ; Sent: Tuesday, December 18, 2012 9:23 AM Subject: Re: Best practices in lyric typesetting On 18 déc. 2012, at 10:19, "Phil Holmes" wrote: - Original Message - From: To: Sent: Tuesday, December 18,

Re: Best practices in lyric typesetting

Hello, 2012/12/18 m...@mikesolomon.org > I'll tell that to my singers as they tar and feather me. > > I would forse a line break in such a case. Marek Klein http://gregoriana.sk ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.or

Re: Best practices in lyric typesetting

On 18 December 2012 20:19, Phil Holmes wrote: > - Original Message - From: > To: > Sent: Tuesday, December 18, 2012 9:04 AM > Subject: Best practices in lyric typesetting > > > > Hey all, > > Putting aside the impossibility of the attached exercise, you

Re: Best practices in lyric typesetting

On 18 déc. 2012, at 10:19, "Phil Holmes" wrote: > - Original Message - From: > To: > Sent: Tuesday, December 18, 2012 9:04 AM > Subject: Best practices in lyric typesetting > > > Hey all, > > Putting aside the impossibility of the attached ex

Re: Best practices in lyric typesetting

- Original Message - From: To: Sent: Tuesday, December 18, 2012 9:04 AM Subject: Best practices in lyric typesetting Hey all, Putting aside the impossibility of the attached exercise, you'll see that the lyrics stay shifted way down for the part of the attached example that

Re: best practices for divisi string writing

but I think some combination of tags and instrumentChanges will accomplish all the things I need to do. -- View this message in context: http://old.nabble.com/best-practices-for-divisi-string-writing-tp32503916p32728162.html Sent from the Gnu - Lilypond - User mailing list archive a

Re: best practices for divisi string writing

Shevek saultobin.com> writes: > One thing that I have had trouble figuring out, though, > is the best way to do divisi string writing in Lilypond. I find it awkward to split the music among variables, so I learned to use the \tag system to mark different formatting options for part or score.

Re: best practices for divisi string writing

On Sep 25, 2011, at 10:50 AM, Shevek wrote: > > I'm a composer that has been using Finale for around 10 years, but recently > switched to Lilypond almost exclusively. The reasons for my switch are > numerous, including that I run Linux, Lilypond's beautiful engraving, and > the natural way Lilypo

best practices for divisi string writing

ate staves in the part. I'd really appreciate any suggestions for how to do this. -- View this message in context: http://old.nabble.com/best-practices-for-divisi-string-writing-tp32503916p32503916.html Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com. ___

Re: Best Practices for Multiple Part Scores

At Fri, 08 Jul 2011 11:32:15 +0800, James Harkins wrote: > > - Short lived divisi - is there a better method than using < > on > > every note? What about a passage with rhythmic differences? Must > > this be separated into yet another part? > > This is one area where I think lilypond beats final

Re: Best Practices for Multiple Part Scores

2011/7/7 Kieren MacMillan > > Hello Andrew, > > > What is frustrating to me is that doing something that > > seems to be standard in music notation (such as writing multiple > > parts) takes so much manual effort and so many hacks to look good. > > And there is much more documentation for strange

Re: Best Practices for Multiple Part Scores

Keith OHara oco.net> writes: > file: horns.ly [...] > \score { > \keepWithTag#'part \new Staff << > \horns_mvt_I \commonConductor_mvt_I >> > } > \score { > \keepWithTag#'part \new Staff << > \horns_mvt_II \commonConductor_mvt_II >> I had forgot

Re: Best Practices for Multiple Part Scores

couchand gmail.com gmail.com> writes: > > I would like to set a large piece with multiple parts, with the option > of producing single-part scores (e.g. an orchestral piece). I have > found that very quickly my source files get out of control. 1) http://www.mutopiaproject.org/ Jay Anderso

Re: Best Practices for Multiple Part Scores

> Date: Thu, 7 Jul 2011 09:25:43 -0400 > From: "couch...@gmail.com" > Subject: Best Practices for Multiple Part Scores I'm also relatively new to ly so I don't have detailed answers. > I am specifically looking for advice on the following subjects: > - Ti

Re: Best Practices for Multiple Part Scores

A lot of this is beyond me, Andrew, but : On Thu, Jul 7, 2011 at 9:25 AM, couch...@gmail.com wrote: > > - Short lived divisi - is there a better method than using < > on > every note? What about a passage with rhythmic differences? Must > this be separated into yet another part? > I've handled

Re: Best Practices for Multiple Part Scores

Am Donnerstag, 7. Juli 2011, 15:25:43 schrieb couch...@gmail.com: > I would like to set a large piece with multiple parts, with the option > of producing single-part scores (e.g. an orchestral piece). I have > found that very quickly my source files get out of control. What are &

Re: Best Practices for Multiple Part Scores

esn't really > contain all that much information. > > I would like to set a large piece with multiple parts, with the option > of producing single-part scores (e.g. an orchestral piece). I have > found that very quickly my source files get out of control. What are > the

Re: Best Practices for Multiple Part Scores

Hello Andrew, > What is frustrating to me is that doing something that > seems to be standard in music notation (such as writing multiple > parts) takes so much manual effort and so many hacks to look good. > And there is much more documentation for strange things (like printing > notes with color

Best Practices for Multiple Part Scores

n all that much information. I would like to set a large piece with multiple parts, with the option of producing single-part scores (e.g. an orchestral piece). I have found that very quickly my source files get out of control. What are the best practices I should be following to keep everything clean

Re: [Best Practices] instrument changes

2011/7/3 Gilles Sadowski : > >> I don't write much music for transposing instruments, so i cannot give >> any advice, but i have a question that may trigger a discussion: how >> to prepare scores with transposing instruments so that they are >> structurally correct? Consider this canon: >> >> commo

Re: [Best Practices] instrument changes

Hi. > > > > I would love to put together a "Best Practices" example/snippet/document > > Good idea! > I don't write much music for transposing instruments, so i cannot give > any advice, but i have a question that may trigger a discussion: how > to prep

Re: [Best Practices] instrument changes

2011/6/28 Kieren MacMillan : > Hello all, > > I would love to put together a "Best Practices" example/snippet/document Good idea! I don't write much music for transposing instruments, so i cannot give any advice, but i have a question that may trigger a discussion: ho

RE: [Best Practices] instrument changes

Kieren, From: Kieren MacMillan [kieren_macmil...@sympatico.ca] Sent: 28 June 2011 16:39 To: James Lowe Cc: Lilypond-User Mailing List Subject: Re: [Best Practices] instrument changes Q1: When you have a doubler-switch in the middle of a passage, do you use

Re: [Best Practices] instrument changes

Hi James, Thanks for chiming in! Very helpful. > 1. Always use music variables and THEN transpose them in the \score, rather > than transpose them in the variable (if that makes sense?) Definitely. This, I think, is Best Practice #1. In fact, "put the notes in variables and [try to] do everyth

RE: [Best Practices] instrument changes

: [Best Practices] instrument changes Hello all, I write a lot of music for "doublers", i.e., instrumentalists who play more than one instrument. Often (e.g., clarinet), these instruments have different transpositions. Furthermore, I usually need to print parts (in "performance pit

[Best Practices] instrument changes

ransposed" and "c" scores). I would love to put together a "Best Practices" example/snippet/document, but I want to make sure they *are* "best practices": a lot of what I do now would be better described as "crisis-mode hacking", in order to get the sco

Re: best practices

For what it's worth, my misunderstanding--beyond the "um"--had nothing to do with abbreviations. It was only in expecting to see the words "best practices" in the documentation, as it was the original post's subject.

Re: best practices

On Mon 20 Sep 2010, 10:08 David Kastrup wrote: > Anyway, if we have a sender knowing abbreviations, and a receiver _not_ > knowing them, they are not as much convenient for communication as for > establishing superiority. That was not about a (polite and convenient for all) way to answer emails in

Re: best practices

"Dmytro O. Redchuk" writes: > On Sun 19 Sep 2010, 21:36 David Kastrup wrote: >> It is agreed-upon best practice _not_ to use those abbreviations on the >> general user list. > Regarding abbreviations -- they're convenient, anyway. If I have been able to look far, it is because I have been steppi

Re: best practices

On Sun 19 Sep 2010, 21:36 David Kastrup wrote: > It is agreed-upon best practice _not_ to use those abbreviations on the > general user list. Regarding abbreviations -- they're convenient, anyway. -- Dmytro O. Redchuk Bug Squad Be careful! These are some commonly used abbreviations: •

Re: best practices

Graham Percival writes: > On Sun, Sep 19, 2010 at 10:07:28PM +0200, Martin Tarenskeen wrote: >> >> I agree, but: Since many people use these abbreviations, Would it be >> an an idea to mention those abreviations on manuals.html and in the >> titles at the top of the manuals. something like: >>

Re: best practices

On Sun, Sep 19, 2010 at 10:07:28PM +0200, Martin Tarenskeen wrote: > > On Sun, 19 Sep 2010, David Kastrup wrote: > > >It is agreed-upon best practice _not_ to use those abbreviations on the > >general user list. > > I agree, but: Since many people use these abbreviations, Would it be > an an ide

Re: best practices

- Original Message - From: "David Kastrup" To: Sent: Sunday, September 19, 2010 8:36 PM Subject: Re: best practices "Phil Holmes" writes: I'm generally normally quite helpful (or try to be). It was just that Graham had given you all the information you

Re: best practices

On Sun, 19 Sep 2010, David Kastrup wrote: "Phil Holmes" writes: Graham had given you all the information you needed - you just needed to read it and spend a little while wondering what LM could stand for. It is agreed-upon best practice _not_ to use those abbreviations on the general user

Re: best practices

On Sun, Sep 19, 2010 at 09:36:21PM +0200, David Kastrup wrote: > "Phil Holmes" writes: > > > I'm generally normally quite helpful (or try to be). It was just that > > Graham had given you all the information you needed - you just needed > > to read it and spend a little while wondering what LM c

Re: best practices

"Phil Holmes" writes: > I'm generally normally quite helpful (or try to be). It was just that > Graham had given you all the information you needed - you just needed > to read it and spend a little while wondering what LM could stand for. It is agreed-upon best practice _not_ to use those abbre

Re: best practices

> >>> Phil Holmes philholmes.net> writes: > And anyway, I only said "Um" It was an angry Um! :) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: best practices

- Original Message - From: "Trevor Daniels" To: "Graham Percival" ; "aliteralmind" Cc: Sent: Sunday, September 19, 2010 6:20 PM Subject: Re: best practices Graham Percival wrote Sunday, September 19, 2010 5:22 PM On Sun, Sep 19, 2010 at 5:09

Re: best practices

l. I didn't find the words "best practices" in it, and thought there was something else I was missing. My response was "They're LM 5 Working on LilyPond project". Granted, I missed the word "in", but why would you expect to find the word "best practices

Re: best practices

- Original Message - From: "aliteralmind" To: Sent: Sunday, September 19, 2010 5:34 PM Subject: Re: best practices Ok. I give I give. I have been studying the documentation intensely and thought there was something I missed. I already read it. It was a genuine question

Re: best practices

Ok. I give I give. I have been studying the documentation intensely and thought there was something I missed. I already read it. It was a genuine question and I was surprised by the response. Devs don't want to be pin pricked, and newbies don't want to be fearful. I appreciate and am amazed

Re: best practices

On Sun, Sep 19, 2010 at 5:09 PM, aliteralmind wrote: > Phil Holmes philholmes.net> writes: >> > Where exactly are they, please? >> >> Um.  Learning Manual 5.  Entitled "Working on LilyPond > projects". > > I read the learning manual. I didn't f

Re: best practices

On Sep 19, 2010, at 6:09 PM, aliteralmind wrote: > Phil Holmes philholmes.net> writes: >>> Where exactly are they, please? >> >> Um. Learning Manual 5. Entitled "Working on LilyPond > projects". > > I read the learning manual. I didn't fi

Re: best practices

Phil Holmes philholmes.net> writes: > > Where exactly are they, please? > > Um. Learning Manual 5. Entitled "Working on LilyPond projects". I read the learning manual. I didn't find the words "best practices" in it, and thought there was something

Re: best practices

- Original Message - From: "aliteralmind" To: Sent: Sunday, September 19, 2010 4:01 PM Subject: Re: best practices Graham Percival gmail.com> We *have* a set of "best practices". They're LM 5 Working on LilyPond projects. I wrote them two years ago,

Re: best practices

Graham Percival gmail.com> > We *have* a set of "best practices". They're LM 5 Working on > LilyPond projects. I wrote them two years ago, and AFAIK nobody > has ever read them. Where exactly are they, please? ___

Re: Best practices for book output?

On Wednesday 01 September 2010 00:03:33 Christopher Meredith wrote: > I may be in over my head. What I am trying to do is produce a hymnal. > After much experimentation, I have settled upon a layout I like that > I am using on a per-hymn basis. I have abstracted these portions of > my input files a

Best practices for book output?

I may be in over my head. What I am trying to do is produce a hymnal. After much experimentation, I have settled upon a layout I like that I am using on a per-hymn basis. I have abstracted these portions of my input files and created header.ly and footer.ly. For each individual hymn, I then use \in

Re: best practices

Hi Ian, I really appreciate the spirit of the challenge, but can you correct it as the alto flute's in G? Oops! I've been going back and forth in both directions (\transpose and \transposition) so much, I lost track! =\ Thanks for catching that... Best, Kieren. % \ve

Re: Re: best practices

Hi Kieran, I really appreciate the spirit of the challenge, but can you correct it as the alto flute's in G? I think only the lines with the text markup saying (in F) need changes, but can you repost the entire thing in case there's something I missed? Cheers, Ian Kieren MacMillan wrote

Re: best practices

Hello all, For anyone who is interested in putting their 2¢ in on this discussion... Here is a simple instrument-doubling-with-key-signature-changes challenge: % \version "2.11.49" \include "english.ly" #(set-global-staff-size 14) \layout { \context { \Score printKeyCa

Re: best practices

Hi Valentin, Not only have I read them too There you go, Graham: at least two people have read your "best practices" docs! ;-) I don't think the docs are incomplete, I think *we* are, as LilyPond coders. I'm afraid all of us are actually making history rig

Re: best practices

2008/6/29 Kieren MacMillan <[EMAIL PROTECTED]>: >> We *have* a set of "best practices". >> They're LM 5 Working on LilyPond projects. >> I wrote them two years ago, and AFAIK nobody has ever read them. Not only have I read them too, but I think I

Re: best practices

Graham, We *have* a set of "best practices". They're LM 5 Working on LilyPond projects. Unless I'm missing something, there is no "best practice" on how to (e.g.) efficiently handle instrument switching. There are, of course, several references to the conce

best practices

On Sat, 28 Jun 2008 11:26:46 -0400 Kieren MacMillan <[EMAIL PROTECTED]> wrote: > In any case, we should really -- as a community -- come up with a > set of "best practices" (or at least "guidelines"), since this is a > situation that is both common an