Re: \repeat with upbeat (partial) and alternatives
Reinhold Kainhofer wrote: > All the choral scores that I have seen put the pickup note before the |: and > use whole measures for the voltas (like in the attached example). > > Patrick Horgan wrote: > > What else are you going to do if there's a pickup note > > and the 2nd ending goes on? You can write the second ending as an end > > followed by a partial pickup, but this solution seems more elegant, and why > > reading voice would certainly be simpler to read. Choirs are filled with > > folks whose reading skills are minimal to nonexistant. > Exactly, that's why voltas typically span whole measures... This is surely not the whole story. The repeated music |: to :| is then not congruent with the lyrics. In a song with several verses the first verse is ok, but subsequent verses get split. Their upbeat lyrics are off somewhere on another page. But for easy reading, these should be up front, especially if words get split. ___ 1. Close your | eyes and I'll ... | 2. tend that I'm ... ___ 1. Es war schon | dunkel, als ... | 2. zählten sie ... ___ Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: small notes etc.
David Biddiscombe wrote on the bug list:
> Below is an input file representing small parts of a file for a four-verse
song.
> The rhythm of the fourth verse, which differs from that of the other verses,
is
> shown in the .pdf file by the small notes above the top staff, except that
the
> two small quavers must be (a) beamed, (b) with a slur/tie **above** the beam,
> and (c) in line with the other three small notes. (The markups are attached
to
> the **alto** input to avoid complications over stem directions.) I've tried a
> number of markup variations, but can't get the necessary output.
>
> Also, for some reason, the first alto crotchet f is not offset from the
soprano
> g, although in every similar case in the the complete song (as for example in
> the last chord in this extract) the output is correct.
>
> Lastly, is it possible to make bar lines (of all types) thinner? Line 10 of
the
> file below is an attempt (but doesn't work).
Answering in reverse order:
Barlines belong under Staff and have two specially named thicknesses.
Try
\override Staff.BarLine #'hair-thickness = #1
These offsets are normally set up by \voiceOne, \voiceTwo etc.
which you have done explicitly (inside ChoirStaff).
But the << {...} // {...} >> construction implicitly
sets up its own \voiceOne, \voiceTwo etc.
You can see the effect of this by swapping the order of these {...}
I don't know enough about it, but my feeling is that markup is unsuitable for
this.
Search LSR for "rhythmMark" to see how complicated it can get.
You are using separate markups to get the horizontal alignment.
But to get a single vertical alignment you should have just one markup.
I would suggest setting up an auxiliary staff having everything but the notes
blanked out.
Search LSR for "Engravers one-by-one".
Also, with this approach no local << {...} // {...} >> construction is
needed.
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
SLopUF = sporadic low-powered user feedback
Graham Percival wrote on -dev Well, the fact is that most users don't seem interested in helping with the docs, even to the extent of reading them. :| I had my first contact with Lilypond over two years ago (2.6.5 on win98). I was extremely confused before I could get it to compile something, even though I wasn't expecting a GUI application. In my initial enthusiasm I wrote up a short account of my newbie experience, thinking this might be useful to the experts, especially those writing the docs. But on rereading it, I realized it wasn't very helpful. It jumped around, touching on all sorts of irrelevancies, i.e. it was just as confused as I was. And then it just might have been construed as a rant. So I sat on it. And soon it referred to an obsolete version and an unsupported OS. This still applies in a sense: I can offer maybe 10% essence and 90% personal confusion, i.e. not only is the user low-powered but timely feedback would be too. I will preface any such offerings with "SLopUF" to warn off those readers not interested in baroque instantiations of trivial use cases. Cheers, Robin r0b lilypond 2.6.5; win98SE; ie6.0.2800.1106SP1; gs6.0 This relates my first contact with lilypond, my confusion as a windows user. This feedback is my way of saying thank you. The starting point is me, soon to be joining a small jazz combo on piano, never having done anything similar, preparing for the first practice session. We will be working through 4 standards so I want a realbook-like lead sheet for each, clear and uncluttered. The singer requires all of these transposed, so I want my sheets transposed too. I started out with a manuscript pad, working in pencil. To avoid confusion with later pencil jottings I would have to photocopy these. And to make room for such jottings: leave off the empty staves; maybe even space out the other staves. (Or use Fidolino staves, but with me these are too uneven.) I remembered trying a freeware program a few years ago and getting horribly bogged down in getting things reasonably spaced out. But I thought it might be worth trying layout on the PC again and found lilypond. I took a quick look through the docs and liked 1) the char input 2) the nonproprietary output 3) the layout promises 4) voicings. By the way, I am definitely not an early adopter. I prefer to let the more enthusiastic ones cope with any teething troubles. And having found something that more or less suffices, I stick with it. This explains the win98 above (but SE for USB), and anything else that may seem archaic. I downloaded the latest stable version. It let me install it in my apps partition (thankyou). And then somehow, I was being invited to drag and drop for a demo. Ok; but how are you supposed to find welcome.pdf??? It may look as though I am a desktop messy but I'm not really. It's just that there a *lot* of icons on it. This is annoying, but fortunately I know (how) to point windows explorer to the desktop and get a list view. So this is how it is to be used? I will improve on this by opening a folder (e.g. 'lilypond') on the desktop and working inside that. But the lilypond shortcut presumably needs adapting: change its [Start in] from 'C:\WINDOWS\Desktop' to 'C:\WINDOWS\Desktop\lilypond'. Test the same drag and drop inside folder 'lilypond'. No output files in this folder. No output files on the desktop either.. Eventually found the output files lurking in c:\ This is some sort of default behaviour: - not the [Start in] folder - not the .exe folder - but the DOS current directory for partition C: ? No good for me. I want to be in control. The tutorial doesn't say how to specify the output file. I am extremely doc-disoriented until I realise that the tutorial (which I was led to, and have concentrated on) is *inside* the user manual. 1.6. says of the Tutorial 'First time users should start here'. In that case, the Tutorial should also point to the user manual. N.B. 'http://lilypond.org/doc/v2.6/Documentation/' says 'start here'. Ah yes, the output file. I find '5 Running Lilypond' with a list of options. But this is written in Unixmanualspeak with usage context assumed. And what is /FILE/? with/without path? with/without blanks? No, this is too steep for me. So then what is 'the default output file' when no /FILE/ is given? Erh, .. just above this it is talking about an 'init file' Is this the unix equivalent of what windows programs nowadays put in the registry? But it is normally of type .ly so this must be the wrong level. So maybe somewhere there is an environment. In the registry I find a 'Session Manager' but right next to it is a 'SessionManager' so I capitulate. (And should I have been able to find out what '-dgui' in the shortcut is doing?) I write a 2-line batch file to - delete .ps - mimic the shortcuts invocation all for the file 1.ly which I base on '3.1.3 Notes and chords'.
SLopUF: linear LM
I've already had a look at the first few pages of the LM and this time I'm going to start on it properly. So I'm back at the web page for the docs. [see webdoc.png] I click on it's "Learning Manual (LM)" link - the one saying "(start here)" - and then again on "Tutorial: A tutorial introduction." Hmmm - not very much to read here. Try clicking "First steps" Huh? - even less to read here. Try clicking "Compiling a file" That's more like it! read .. read .. read, and then at the bottom click on "Simple notation" - because it says "Next" .. read .. read .. read, and then at the bottom click on "Working on input files" - because it says "Next" .. read .. read .. read, and then at the bottom click on "How to read the manual" - because it says "Next" .. read .. read .. read, and then at the bottom click on Huh? - there is no "Next" to click on! So what am I supposed to do? It would be silly to click on "Previous" "Working on input files" The only other one is "Up" "First steps" but I've been there already. Just above these links it says "..it might be best to read through the rest of the tutorial first." I agree; but this suggestion is not offered as a link you can click on. Losing confidence (and short term memory of the lilypond content) I try "Up" "First Steps" and see that at the bottom that I can click on "Next" "Single staff notation" Huh? - another one of those pages with nothing to read! And now, feeling caught in a maze, I have to concentrate: I would have clicked on "Next", because I want to get on with reading; but I realize maybe I should click on the bullet links first. By now I'm not thinking about lilypond; I'm working fulltime on not getting lost. And when I do click (correctly) on "Accidentals and key signatures" I'm not paying full attention to what I'm reading, because I feel I have to remember what where I just came from looked like because I may need to recognise it again when the next lot of "Next"s run out. OK, that's enough. Let us ponder LM.1.2(.LM): "This book explains how to begin learning LilyPond, as well as explaining some key concepts in easy terms. You should read these chapters in a linear fashion." The web page should not take you to something which makes this difficult. It should take you to a linear LM. The crudest form of linear is like "PDF" and "bigpage" where you can traverse the whole document with one action pair i.e. PageUp/PageDown or scroll up/down. This is what is missing. (Pagewise-linear needs two action pairs, and probably requires pointing.) OK, it's not missing, but it took me half a year to realize it wasn't. - the web page [see webdoc.png] shows all the other doc things having PDF and/or bigpage versions, implying that this is not the case with LM. - When you arrive at the LM, the first page is all TOC (short/full) apart from some boilerplate at the top about copyright, which efficient readers skim over, thus missing the import of very first line. Two further points: - The tree version will benefit from CSS TOC, but still offer no pageturning. - The very first line of bigpage-LM points to bigpage-LM. Cheers, Robin r1b <>___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SLopUF: linear LM
Graham Percival wrote: If you look at the latest docs using texi2html, this has already been dealt with: http://kainhofer.com/~lilypond/texi2html-out/Documentation/index.html Well, well, thank you very much. Robin Bannister had written: Two further points: - The tree version will benefit from CSS TOC, but still offer no pageturning. which is (/will soon be) apparently incorrect. So much for my "timely feedback". On being confronted with this new document, a certain LopU (lowpowered user), admittedly unprepared, unfortunately found the navigation much too highpowered, didn't know what to click on upon reaching [ << Tutorial ] [Top][Contents][Index][ ? ] [ Fundamental concepts >> ] [ < First steps ] [ Up : First steps ] [ Simple notation > ] because there was nothing called "Next" or somesuch. It seemed to expect that you knew what the next page was called. I was able to help out here and explain that you could always chicken out, go back to the [Top], and click on "one big page". But the wily lilypond programmers were clearly one step ahead of us because this led us not to our escape but to a help page talking about buttons. And here we found that "Next" was now called "Forward" and meant "Next .. in reading order" i.e. pageturning ! and the only thing we hadn't known was: to look for ">" as in [ Simple notation > ] If you remember this only vaguely, there are tool tips to help out. And it really does go from 1.2.4. to 2.2. to 2.2.1 ! [But sometimes IE6 Back is vertically challenged] And it has nice Easter Eggs to keep you on your toes: e.g. the green bit in 2.1.3 is in a different language; Viennese, I think. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: drumpitches
But could someone please tell me, where I can find this file For (a default installation on) Windows (de), I suggest C:\Programme\LilyPond\usr\share\lilypond\current\ly\drumpitch-init.ly Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
GDP NR talking about IR
There are a few places in the NR (version 2008-08-09) still mentioning - program reference - programmer's reference i.e. terms obsoleted by GDP. And in NR 5.2.1 it says This section will be much more difficult to understand if you are using the PDF manual. Did / does / will this exist? Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP NR talking about IR
Trevor Daniels wrote You don't say where these are, but I suspect they are still in sections not yet completed within GDP, ie sections 3 onward. NR sections 5.2.1 to 5.7.1 but I can't see a mention of the PDF version. Well, er - I was using the PDF version (easier for me to search) It says: See also Internals Reference: Fingering. The programmer's reference is available as an HTML document. It is highly recommended that you read it in HTML form, either online or by downloading the HTML documentation. This section will be much more difficult to understand if you are using the PDF manual. Follow the link to Fingering. where the current HTML version says just See also Internals Reference: Fingering. Follow the link to Fingering. Does this mean I shouldn't check/search/quote/etc. the PDF version? Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Comments on Learning Manual 3 -- Fundamental concepts
Trevor Daniels wrote I learned you can have digits in context names! --- as long as the names are in quotation marks. which I regard as slightly more confirmation of my fragile suspicion that in (the current GDP) Learning Manual 3.1.1 - In summary there shouldn't be a backslash in front of "StaffGroup" where it says Every \context block will affect the named context (e.g., \StaffGroup) Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Comments on Learning Manual 3 -- Fundamental concepts
Trevor Daniels wrote
Thanks, Robin
Well, you're welcome. Glad to be of some use.
But also disappointed,
because I thought I had understood something (from reading the manual!),
and now it seems I hadn't.
Statistics for NR (pdf dated 2008-08-09, only slightly stale):
A: 21 hits for "\context Staff"
B: 14 hits for "\context { \Staff"
Or is it that I'm talking about A, and you are talking about B?
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Comments on Learning Manual 3 -- Fundamental concepts
Robin Bannister wrote
A: 21 hits for "\context Staff"
B: 14 hits for "\context { \Staff"
I think I get it now.
It must be that "\context" is overloaded,
does two quite different things.
Upon meeting a "\context" you must categorise it as A or B.
The uninitiated attach no particular significance to
the decisive "{" or, in my case, the word "block".
Especially when they're still chewing over \context vs.\new.
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
SLopUF: context name
Hallo again! At the end of LM 3.3.2. there is the caution: Note the distinction between the name of the context type, Staff, Voice, etc, and the identifying name of a particular instance of that type ... Well, I can manage that, I think. Because when I'm looking at the snippets, these names look quite different: one lot are in quotes. But when I start reading in the manuals about using these names I get confused. LM says, for example, > context name (like Staff or Voice) But when NR says > when setting lyrics the melody is in a named context it is talking about an identifying name. And quite often they mention > context type which could make someone think that that was something different again, i.e. something else to learn about, but maybe it is because it would be inappropriate to say "name" at that point or maybe "name" is being used nearby for something else. OK. I know this doesn't fit in with the docs schedule. And I shouldn't really be reading NR 5 yet. This feedback goes orthogonal to the section view, and so will be untimely in many different ways. Feel free to ignore it (for the time being). Two weak rules: WR1 Avoid "name" as a verb. WR2. Keep "context" and "name" words well apart. WR1 is because the this verb is ambiguous: A: to refer to by name (like the of \context) B: to give a name to (like the = of \context) i.e. this is important when used near "\context" where the author might mean A and the reader understands B. (This may only apply to English, but English is the language being translated.) WR2 is like taking big strides when your shoelaces are undone. It doesn't apply if there is a qualifier which reduces the ambiguity sufficiently: e.g. named voice context (already has a type name, so must mean id) The lilypond word "context" itself is ambiguous if alone, applying to either type or instance. (I'm not talking about normal discourse, which copes with ambiguity). Unambiguity is most important in the command syntax sections. It is less important elsewhere but only if there are watertight definitions the puzzled reader can refer to when needing clarification. To apply these rules you have to find suitable words/phrases to replace the forbidden ones. I thought I would try this out to see if it produced something clearer for me. On starting I ran into a different problem: the placeholders used in the new/context/set/override syntax sections vary a lot, making it difficult for the reader to see the similarities. I unified the placeholders for and (but left the others unchanged) and thought up some new verbs. The result is attached as TAB-separated csv with 3 columns: - section numbering - phrases/sentences I considered relevant to to "context" and "name" - my rewording of those phrases/sentences which violated WR1/2. Cheers, Robin r2b LM.csv Description: Binary data NR.csv Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: doc work
Graham Percival wrote I would prefer that early users placed a \tempo 4 = 60 in their score block, which is easier to understand, works in MIDI, and permits dotted notes to be used Early users would think in terms of dotted notes and write \tempo 4. = 60 But no, no. You had to write \tempo 4 .= 60 which - is not easy to understand - is easy to forget - has an easily overseen dot (because the 4 is obviously not dotted) Something easy would have to let you say "4." like for dotted notes. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: doc work
Trevor Daniels wrote ? I don't understand. \tempo 4.=60 works fine in the \score block. Sorry. For "early" read "prehistoric", I suppose. Because [1] worked, I never needed to do anything differently. And convert-ly.py (2.10.33) now removes \tempo from my files. [1] http://lists.gnu.org/archive/html/bug-lilypond/2006-01/msg00028.html Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
SLopUF: Sumatra and issue 635 (pdf locking)
2.10.33 on Win XP SP3 I started using XP for Lilypond work about half a year ago, leaving behind 2.8.6. on Win98, where I had had Adobe Reader for viewing pdf output. I thought being on XP might offer the chance of finding a viewer which didn't get in the way of Lilypond generating its pdf. In the wikipedia entry for SumatraPDF it said .. unlike other PDF viewers it does not lock the PDF file. So I tried 0.8, but it blocked Lilypond just the same. So did 0.7, but at least it seemed more stable. And I continued working rather like on Win98: - double click on 1.ly (my invariant filename) - File > Close in Sumatra 0.7 - wait for console window (Ghostscript) to come and go - drag (the new) 1.pdf onto Sumatra i.e. the usual mouse drudgery, but there were two benefits: - Sumatra usually applied the old position and zoom to the new file - using Adobe for other things didn't interfere with my Lilypond work The irritation remained: why must this be, when at the same time Lilypond is not bothered by the log file being left open in notepad? The discussion re issue 635 [1] reminded me of this, and a week ago I revisited Sumatra and saw that it now offered automatic reloading, i.e. indirectly reaffirming that you didn't have to close to allow updates. I thought of testing this using Windows Explorer and found that Sumatra - doesn't let you drag or delete the file (whereas notepad does) - but does let you overwrite it (as when dropping with +). I later found this distinction confirmed on the Sumatra forum [2]. So an effective workaround is to point Sumatra to a different file, e.g. viewer.pdf, and overwrite this when Lilypond is finished (like [3]): copy 1.pdf viewer.pdf The high-powered variant of this involves disabling (if (access? pdf-name W_OK) (delete-file pdf-name)) as in issue 635, letting Lilypond do the overwriting (of 1.pdf) itself. This may be sufficient for some; things are now nicely streamlined. But I don't like the way the view gets out of sync when Lilypond aborts early due to a syntax error or somesuch. I might be distracted while waiting for the console window and the Sumatra refresh, and then think that my latest edit (e.g. an override) hadn't changed anything. So I recommend making the state of progress more obvious by doing del 1.pdf copy dummy.pdf viewer.pdf before starting Lilypond, dummy.pdf being chosen as obviously different. [1] http://lists.gnu.org/archive/html/lilypond-devel/2008-06/msg00088.html [2] http://forums.fofou.org/sumatrapdf/topic?id=4933 [3] http://lists.gnu.org/archive/html/lilypond-user/2006-07/msg00453.html Cheers, Robin r3b ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SLopUF: Sumatra and issue 635 (pdf locking)
James E. Bailey wrote open the pdf in a web [b]rowser ... and then just refresh the page. Yes, a copy (like viewer.pdf) would then be held in the browser's cache. I have the pdf add-on disabled because it obstructs my browsing habits. But I tried this out just to see how it felt (using AR8 in IE6): Lilypond still got blocked, so presumably the cache was bypassed. Gilles THIBAULT wrote: Here is the little script (lily.bat ) i use to run lilypond. I had thought that the automatic reloading offered by Sumatra would let me eliminate the mouse drudgery *without* using a script. But the Lilypond conflict prevents that. And now I see that automation makes important the secondary things which I hadn't really noticed when in manual mode: - the sync problem I mentioned - keeping the viewer window on top (or not). I have now tried out 3 different methods: A using automatic reload, via a copy as I outlined. This needs an annoying initialisation phase to start up the viewer. B closing the view but not the viewer and then reopening the view in the same viewer instance (as I did manually). This needs no initialisation but offers no other advantages C using taskkill and start, as you do. This puts the viewer window on top by default. At the moment I favour C. Here is my version (simplified) , which also copes with the log getting out of sync - dummy.log says "nothing logged". __ taskkill /FI "WINDOWTITLE eq 1.pdf*" taskkill /FI "WINDOWTITLE eq 1.log*" copy dummy.log 1.log del 1.pdf 1.ly if exist 1.pdf start 1.pdf start notepad 1.log __ Bertalan Fodor wrote LilyPondTool's PDF viewer solves this problem by automatically closing ... Sumatra solves the Write problem but the Delete problem remains. On the other hand, this has now become almost irrelevant to me because, in automatic mode, I want the pdf deleted before Lilypond is started. Someone might just have happened by and concluded that also on Windows Lilypond should not delete (or at least not abort when delete fails). Maybe the "SLopUF" warned them off. Or maybe it's cecause cackend clogs can ce a cit coring. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: notation TAB matching
Grammostola Rosea wrote:
there are not ties between the and
To get ties between
and
you must put a squiggle between them,
( like you did between a, and ).
This then looks like:
~
the a is now connected to the e which is wrong
You are using "\(" and "\)" for phrasing slurs.
But you should finish one phrasing slur before you start the next. [1]
Look in the log:
- Lilypond complains (five times)
- it ignores all the following slur marks
- and then complains that the (initial) slur is unterminated.
This unterminated slur is stopped at the end, which happens to be the note e.
So keep "\(" at a,4 ,
remove all the other marks
and put a closing "\)" after
[1]
http://kainhofer.com/%7Elilypond/Documentation/user/lilypond/Phrasing-slurs.html#Phrasing-slurs
where it say "Simultaneous ..."
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: notation TAB matching
Grammostola Rosea wrote: 1) You see the last two low a's (a,) doesn't have an tie. I like to have one between them. I can't connect them with ~ cause there are other notes between the two a's (e.g. gis and b). ... Ok, I think I solved problem 1 for 90% ... a,8~4. a,4 (8 ~ 4) a, You have chosen to use a slur to join the two low "a"s. Here are some comments on what remains unsolved (10%?): A In the upper staff this slur "looks" like a tie; it goes horizontally. But in the lower staff it is obviously not a tie; it climbs up and over. B In midi output you will hear the attack at the start of the second "a". C These two "a"s are separated by an eighth (during the first ). Did you rather want them to abut? A 100% solution (?): Lilypond does in fact let you tie the two low "a"s in this particular case. Reread the documentation for ties, looking for "tieWaitForNote". This can be applied as follows: a,8~4. \set tieWaitForNote = ##t a,4 ~ 8 ~ 4 \set tieWaitForNote = ##f a, - the slur has been removed - the curve in the lower staff is now horizontal (because it is a true tie) - the gap of an eighth is bridged. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: notation TAB matching
Grammostola Rosea wrote: Question 2) still remains There will be other problems like this in the bars to come, each needing a special effort to overcome, usually in an unsatisfactory way. This is because you are trying to put overlapping durations into a single voice. Try starting again, but this time using several voices. A clear example of doing this for guitar was quoted [1] here recently. See, for example, how the bass line keeps sounding while other notes are being plucked. And it shows that you needn't stop at bass/middle/top; you even can put other things (like dynamics) into separate voices. The things for overlapping durations, e.g. - tieWaitForNote - the polyphonic construct << ... \\ ... >> - laisserVibrer are still available of course. But if you have sufficient voices you will rarely need them. There are occasionally new problems to do with coordination between the several voices but these are a lot easier to solve. [1] http://lists.gnu.org/archive/html/lilypond-user/2008-08/msg01197.html Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: guitar slide with lilypond
Grammostola Rosea wrote I think I can use this for bends: http://lilypond.org/doc/v2.9/Documentation/user/lilypond/Falls-and-doits This 2.9 page doesn't say very much, does it? Have a look in the 2.11 docs for a bit more. (You seem to be using 2.11 anyway.) Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Left margins
Cath Downie wrote: I'd be grateful if anyone could advise me on what I'm doing wrong. These other things you tried don't belong in \layout. Look at the Notation Reference [1] In 4.2.2. the \layout and \paper blocks are contrasted. You will find the things you tried in 4.1.2, where it is talking about the \paper block. [1] http://lilypond.org/doc/v2.11/Documentation/user/lilypond/index Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: moving individual bar numbers / 'padding' beginning of bar?
jo.clarinet wrote: do padding of some sort - either to get just the relevant bar numbers moved up a little (but NOT the rest of them) Follow the reference to BarNumber in the Notation Reference [1] index. This talks mostly about moving sideways (using self-alignment-X). But you probably want what is mentioned further down the padding property of BarNumber can be used to position the number correctly. Follow this through to "BarNumber" in the Internal Reference. To change this for just one bar number, you say (in the previous bar) \once \override Score.BarNumber #'padding = #1.0 and play around with the value at the end, e.g. try #0.5 [1] http://lilypond.org/doc/v2.11/Documentation/user/lilypond/index. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Recalcitrant midi instruments
T Högvall wrote: I did attempt to put in the real instruments then, by including lines like \set Staff.midiInstrument = #"clarinet" in the score section ... What am I missing? Either A or B. A: In the score section you have put your \set command between one "\new Staff" block and the next. This leaves it outside these blocks, where it has no influence: - too late for the preceding block - the subsequent block establishes its own (default) midiInstrument. So move your \set command inside i.e. to before or after \global. Maybe you influenced the containing "\new StaffGroup" in some way. B: In the "\new Voice" blocks your \set commands for midiInstrument should say "Staff.", just like you did for instrumentName. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: note entry suddenly stops
Michae Phillips wrote: Is there a reason why entering notes in a score is suddenly stopped? Well, I had a hunch and followed it up. Lilypad handles up to 3 bytes and no more. [1] Maybe you are using Lilypad and your file has become too large for it. By way of explanation: When you give the Lilypond program a text file that it understands, it produces sheet music in a pdf file. For example, to get sheet music of a Bach concerto in the file "bach.pdf", you have to - type it up for Lilypond in a text file called "bach.ly", - then give this text file to Lilypond for processing. When you download the Lilypond software package you get, among other things, - the Lilypond program (for generating "bach.pdf") - a text editor program called Lilypad (for preparing "bach.ly"). When you replied Version 2.6.5 you seemed to be talking about the Lilypond program, not about the text editor program which you are using. But maybe you meant that you are using the Lilypad program which came with the 2.6.5 download. If you had this input problem while using Lilypad, you will see the size of your "bach.ly" file listed as something like 29KB or 30KB. If so, try one of the following: A. Maybe you can delete an unimportant part of your text file. Then you can reach the end of the concerto without needing 3 bytes. B. Split your single text file into several text files. See "Including LilyPond files" in the Notation Reference [2] C. Continue with a different text editor. (You don't *have* to use Lilypad. Lilypond will still work.) For example, Windows comes with Notepad, which is similar to Lilypad but can handle bigger files. Consult the mailing list for other suggestions. [1] as seen with 2.10.33's Lilypad on WinXP SP3. [2] http://lilypond.org/doc/v2.11/Documentation/user/lilypond/index Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: note entry suddenly stops
Michael Phillips wrote: Thanks for your input You're welcome. It was pretty much a wild guess; there was so little to go on. And I've never used Lilypad. there is very little unimportant content I can remove. Certainly, no music notes There is another way to reduce the file size slightly, but it may be a bit cumbersome to work with: Identify a repeatedly occurring phrase and set up a variable for its notes. Then use the (short) variable name whereever the phrase occurs. And there may even be places where you could usefully apply "\repeat unfold". a newer version of Lilypad - though this may have the same limit-problem. Well, it certainly does with 2.10.33. Actually, Lilypad probably relies on Windows for most of what it does, getting not only Windows' edit functionality but also its limitations, e.g. http://support.microsoft.com/kb/74225 Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: no tuplet bracket, why?
Stefan Thomas wrote: why in the below quoted example the tuplet bracket is hidden? But in the example you supplied, both tuplet brackets are visible [1]. Did you test your example before posting? However, the tuplet brackets get shorter as additional measures are added. If enough measures are added (or ragged-right is applied), the first bracket disappears, probably because it would be too short to be readable. One way to keep it longer would be to spread out the tuplet contents, e.g. apply the following to the initial r8 : \once \override Rest #'X-extent = #'( 0 . 3 ) [1] with 2.10.33 on WinXP SP3 Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: no tuplet bracket, why?
One way to keep it longer would be to make the tuplet contents wider, Another way, illustrated in the LSR [1], is easier to apply: \once \set tupletFullLength = ##t [1] http://lsr.dsi.unimi.it/LSR/Item?id=398 Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
I like the comprehensive navigation of the new layout [1], but feel there is still something missing. __ Say I am reading the mailing list, looking at a thread or message. I see something which gets me thinking about a problem I have, and I follow a link there which takes me into the documentation. There is something useful to read, and I may navigate around a bit, looking for something even more relevant. I feel safe doing this because the TOC panel shows me not only the breadcrumbs [3] in bold, but also the lie of the land, providing a sort of peripheral vision. I click on another link and go on reading, still thinking mainly about my problem. And then I notice that I'm not so sure where I am, even though the nice TOC panel is still there. I would like to reread a section that I read just after coming in. I can remember its title, more or less. But I can't find it anywhere. __ This would not happen to an experienced reader, who - recognises LM/NR/IR by page layout and treatment style - notices how links are grouped LM/NR/IR-wise and therefore has no trouble tracking movements across LM/NR/IR boundaries. But for the inexperienced reader, thinking about something else, these indications are too subtle. At first I thought, each document is a room (in the documentation house), and something in the rooms could be coloured as a key, e.g. LM green, NR blue, IR red, (to follow a famous example). This does let you notice the boundaries, but it is not explicit, and so could confuse and frustrate. So I propose A Replace the (passive) text "Table of Contents" in the TOC panel, with the document title, e.g. "Learning Manual". This nearly always visible (on biggish screens). (And when offscreen, near the end of NR, it is not far away.) And to follow this up with additional suggestions: B Make this document title [A] be like a breadcrumb at the document level i.e. it is a link to the start of the document. C All documents have their document title headlined on the first page. (Only LM has this sort of title at the moment.) D When you follow the link [B] (or ) you immediately see this title [C]. This reassures those who are getting disoriented. E Just above [B], add a (smallish) link called "Documentation", which goes to "higher than top" [2] [3]. F Because [E] is in the (extended) TOC panel, this link need not be provided as a button in the main pane. This provides another type of reassurance: - the main pane buttons never take you outside the document. And "Top" does not become ambiguous: it means only "Top of document". [1] http://kainhofer.com/~lilypond/Documentation/index.html [2] http://lists.gnu.org/archive/html/lilypond-user/2008-07/msg00485.html [3] http://lists.gnu.org/archive/html/lilypond-user/2008-09/msg00715.html Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: leadsheet with intro an lyrics
Sebastian Menge wrote: But then the second part starts a new staff. How can I prevent that? One way would be to have just one part, which starts all three things together (like your second part) and then make the lyrics skip the intro bars. To see how, search (twice) for "Skips in lyric mode" in the vocal snippets: http://lilypond.org/doc/v2.11/input/lsr/lilypond-snippets/Vocal-music Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: trouble with slur
And for your second question: B. Wha I can make a different size of staff? Upper bigest look for "Changing the staff size" in http://lilypond.org/doc/v2.11/input/lsr/lilypond-snippets/Staff-notation Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Reinhold Kainhofer wrote: Am Montag, 22. September 2008 schrieb Robin Bannister: > So I propose > > A > Replace the (passive) text "Table of Contents" in the TOC panel, > with the document title, e.g. "Learning Manual". > This nearly always visible (on biggish screens). > (And when offscreen, near the end of NR, it is not far away.) > I've done this now. Thanks. This helps. However, this entry currently includes the title prefix "GNU LilyPond - ", which I consider out of place here: - it dilutes the contrast between the different document titles - it increases the effort needed to check the title (a glance is insufficient; you have to read and parse) - in narrow windows the title is more likely to be split onto two lines - it blurs the hierachical succession of section < document < documentation. Without the prefix the title is then just e.g. "Learning Manual", which corresponds to what you see in the documentation overview. > B > Make this document title [A] be like a breadcrumb at the document level > i.e. it is a link to the start of the document. Also done. Maybe you consider this superfluous, but by "breadcrumb" I was also implying that it should be emphasised in the same way as the other breadcrumbs, i.e. you see *all* levels of the vertical path. This is because I regard B as just another entry in the TOC. The TOC does not need a title. And in the meantime the latest styling more or less hides this new feature ... Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Reinhold Kainhofer wrote: so basically, you want ... a link to the back to the documentation index No, I didn't mean that. That is in your TODO, and not at all urgent for regular users. Robin Bannister wrote: This is because I regard B as just another entry in the TOC. The TOC does not need a title. I only meant that B would look something like this (B.png). Cheers, Robin <>___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Patrick McCarty wrote: Okay, see if this design looks better: ... What do you think? Well, I ought to be asleep. But that hasn't worked out too well yet. I realised I had messed up my last two posts (png uncompressed) and got back online to patch things up a bit. What do you think? Well, I'm honoured. And you are very quick off the mark. In fact, you are away ahead of the others, doing "higher than top" and "GNU Lilypond -" elision just like that. :) What do you think? Yes, well the smoke has thinned a little. Look, when this thread started I thought I might keep an eye on what happened to the navigation, but I would keep well away from the styling stuff. But it's not working out that way. So, to styling: I'm older than the other Patrick [1] and don't take to any darkish background. But what I think is more radical than your rework: G The TOC panel needs no title area (I'm repeating myself) H The TOC panel and the navigation bars should be the same colour to show the user their similarity in affordance: - they show you where you are and where you can go to - they are packed full of things to click on - unlike the main page they have no sentences/paragraphs/etc So the TOC panel is (e.g.) pale yellow all over. Navigation bars too. And yes, the "higher than top" link is up there above the toc (E in [2]). And there may be room for some other links (left unexplained), as shown in the attached (compressed) png. [1] http://lists.gnu.org/archive/html/lilypond-user/2008-10/msg1.html [2] http://lists.gnu.org/archive/html/lilypond-user/2008-09/msg00770.html Cheers, Robin<>___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Kurt Kroon wrote: the CSS "quasi-frames" already provide the affordance of a fixed navigation frame, so it isn't necessary to make their backgrounds "matchy-matchy". I don't understand which background areas you are referring to. By "navigation bars" I was referring to the horizontal stripes where you can click to go up or along. These are embedded in the main pane; they move with it when you scroll. Yes, the TOC panel is fixed in this way. If you arrive at a web page with - a list of things in a vertical strip on the left you would probably expect this to be for navigation. If, additionally, - the things are shortish and more or less regularly arranged - there is not much else, e.g. no long sentences it becomes that much more likely. The TOC panel fits this very well. The links in our ... designs provide affordance of clickability by being underlined I suggest that as long as the TOC panel (or whatever) is easily recognised as being for navigation there is no need to indicate clickability. See also [1]. In fact, I think the TOC has too many sorts of indications at the moment. Unlike the main pane, it is not for normal reading, but for scanning: eyewise, you zoom out a bit and apply a sort of filter. This filter gets bogged down by the underlining and the different colours. Scanning is slower and takes more effort. And you can no longer see the breadcrumbs at a glance. They are indeed italic and bold, but - their unity is broken (they can differ in colour) - they do not stand out (they are mottled in mottled surroundings). Which means I'm going against a Nielsen thing - the colouring of visited links. But he is mostly concerned with sporadic visits to typical web sites. This corresponds to use cases like: - somebody working through LM for the first time - after a new stable release somebody reads through AU again. But the main doc usage is surely referring to NR/IR(/LM) to solve problems. And here, the history of yesterdays problem is still prominent when consulting the docs about today's different problem. There is a masking, and after a few such consultations "visited" has lost its effectiveness. So as far as links in the navigation areas are concerned, I think something like the old styling is the way to go. [1] http://lists.gnu.org/archive/html/lilypond-user/2008-09/msg00511.html Cheers, Robin<><>___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Reinhold Kainhofer wrote: This is always a good argument (similar things should look similar), however, I think in our case we can afford to use a "nicer" color in the sidebar, since it is already spacially separated from the contents (by having its own column on the left). I would turn this argument around. Since the side bar is already recognisable as separate, colour need not be used to show that it is separate. (See [1]) This means we are free to use colour to show something else. This is an opportunity. What would the reason for wasting it be? > > So the TOC panel is (e.g.) pale yellow all over. Navigation bars too. The pale yellow/light brown would make the navbars almost invisible on TFT screens, so I think the current state is much better. I wasn't *recommending* pale yellow. I was trying to be neutral with respect to hue and therefore quoted - Patrick's colour - as an example. On kainhofer.com it is pale yellow too. So what/where is the current state? [1] http://lists.gnu.org/archive/html/lilypond-user/2008-09/msg01002.html Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Me answering Rheinhold: > The pale yellow/light brown would make the navbars almost invisible on TFT > screens, so I think the current state is much better. ... So what/where is the current state? Sorry, I got mixed up; I thought this meant the navbars would disappear. But now I think it means they would still be legible (and could be used) but the cohesion provided by their background would be lost. Patrick McCarty wrote: In the case where the vertical scrollbar is visible for the TOC pane, using a white background would be fine. But for a page like [1], the TOC pane would no longer appear to be a pane, and I would argue for using color to indicate its separation (as it currently is). [1] http://kainhofer.com/~lilypond/Documentation/user/lilypond-internals/index.html Yes, I wasn't proposing white; that was just an intermediate stage in the argument. But this is a good answer for Patrick H. Well, fairly good. If the backgound difference can become "almost invisible" then the separation will surely be lost in this case too. But I suppose secondary clues (like placement) help out a bit. I wanted to see what "almost invisible" meant and tried this out (with IE6) on some flat screens. Navbars very visible on a BenQ monitor and an Inspiron laptop, both 2006. I could see the effect an a low-end 1998 laptop, but was a lot more bothered by other presentation problems, like text size versus screen size. Things were squeezed together too much; colour wouldn't have unjumbled it. The navbars have their own secondary clues (like brackety buttons and the grouped layout) so you would hardly mistake them for normal text. But a backgound is helpful for recognition, e.g. when a scrolling moves a navbar back into view. So: navbars same hue as TOC, but (only) slightly denser. Me, toeing my line. :) Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Patrick McCarty wrote: I agree with yours and Reinhold's idea to remove underlining and visited link colors in the TOC pane. Should the same apply to the main doc pane? NAV BAR What I said about TOC scanning doesn't apply here; there is no list. There are probably two main sorts of usages: - very quick, where you are only concerned with the direction to step in. - slowish, where you read some of the names. Within the 2 * 3 grouping there is a semantic synergy e.g. the upper [<< reinforces the lower [< (and vice versa) and symmetry of [< and >] reinforces their opposition. This effect makes selection for stepping easier. But when "visited" colours just the bottom row or just one side, the 2 * 3 is fractured, and you have to look twice. [1] Otherwise it is just mottled and vaguely confusing. Slowish is even slower. The previous/next section buttons are the best candidates for "visited", but it is precisely these buttons which will devalue this. See below. LANG BAR A language link will rarely indicate "visited", and when it does, it is of no import (breadcrumbs unchanged). FOOTER These are exits, so who cares? MAIN TEXT If there were only long text passages containing a few embedded links, then feel free to colour them "visited". But it is mostly not like that: The links tend to be grouped into lists such as - mini-TOCs - "References for" - "See also". Some of these lists have only one or two entries. But there is a very wide range: e.g. music-event or grob! I think the longish lists should not be mottled. CONCLUSION. Most of the above tends towards no "visited" colouring. And repeated consultations devalue "visited" here too. [2] And maybe another effect will be even more important: the navbar makes it so easy to page through the document. This browsing mode will be popular with those - who don't know what key to search for, or - who like navigating by png instead of navigating by title. You stride down the corridor glancing in through the half-open doors. So my answer is yes; apply these changes to the main pane too. Cheers, Robin [1] but lt and gt don't have to be coloured too, do they? [2] a partial workaround: learn spanish, french and german. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Patrick McCarty wrote: I've created another design with a color palette that passes the W3C Web Content Accessibility guidelines for color contrast Yes, yes, yes! Thank you very much. At last I feel the web designer was more concerned about making it easy to read rather than easy to look at. And on long hunts in these extensive docs, easy to read is easy on the eye. Yes please. I like #006078 a lot. It blends with the other colors very well. Well, exactly. It blends. An enormous loss of contrast. The Brett's #0030B8 and Andrew's #1a1aaa seem much the same to me. The reduction in contrast is such that - on white, the links are not quickly distinguishable from ordinary text. - the TOC font would need to be larger to achieve the clarity of #0308fc. And the backgrounds work well in their context. I feel sufficient coordination is achieved without being obtrusive. I do have one caveat though. The bottom navbar and the footer now have the same backgound. They are indeed separated by a gap, but this is insufficient. When you scroll to the bottom of a page and see these appear, the navbar is not so easily recognised as such, i.e. you don't immediately see that it is the same thing as was up at the top. Rather than invoke an additional footer colour, I suggest that the language bar be moved up, and thus act as a more effective gap. Something like footer.png. Cheers, Robin <>___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
It's fine having the language bar down at the bottom of a docs page. But in the bigpage case you've probably done a lot of reading before you reach it, and wish you had seen it earlier. So I suggest something like bighead.png: I Put an additional language bar at the top of bigpages. Cheers, Robin<>___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Some thoughts on searching. Valentin Villenave wrote: the search function should show the results in the main "frame" on the right, without making the tocframe disappear The toc pane and the main pane are a coherent unit. The user refers to the toc to see e.g. - what part of the document the main pane is showing (the breadcrumbs) - if there are immediately relevant sections nearby. And after a navigation move, the toc provides confirmation of the move. (Exception: meta-infos [Contents] and [?] are not shown as being inline.) If the toc pane can get disengaged, people will lose confidence in it. And those who don't realise it has become disengaged will be disoriented. So (without knowing the pros), definitely not. a search box at the top of the tocframe This search box is too small for something realistic like, say VerticalAxisGroup #'minimum-Y-extent Anything big enough would be wasting valuable toc space. To do realistic searches you would use something else which, at the very least, would have a bigger box. But then you could use this for the simpler searches too. This (of course!) leads to what I hinted at in a previous post [1]: The toc pane offers just a [search] link, no box. This takes you to a search page with a bigger box and some other features. It is an ordinary link; you can easily open it in another window if you like. And the cursor is already there in the box, so no extra clicks are needed. The search page is a separate file, e.g. in doc root. So it is easy to have variants, e.g. offer an offline version for the tarball. Sebastian Menge wrote: Another refinement Add "intitle:Manual" or "intitle:Reference" to search only the manual or the reference. Well, you also get Manual beams in NR, or the big-page for IR. This got me wondering how far you could go with "inurl:". And then, instead of just wondering, I built a testrig to try it out. While playing around with this, I discovered inurl could match not just "learning" but "lilypond-learning", an important feature, but one which Google seems to imply doesn't exist. To make inurl searches completely unambiguous, you could embed some sort of codewords in the current urls. But with the above feature, you can get most things filtered correctly, except for NR, which (for historical reasons ?) has a very generic url. So I suggest (to ease path-filtered searching): J Rename NR root from "lilypond" to "lilypond-notation". The next suggestion would be for everything english to have .en. That would make filtering easier, but are there special categories of english which should be filtered differently? e.g. - IR (never to be translated?) - translation pending. And Google's "lr" (language restrict) might be more suitable. The testrig demonstrates how well/badly things work and documents these issues. So I have polished it up a bit and attached it to this post. It is OK with my IE6 on XP SP3; it might just work somewhere else too. The search results only resolve whole web pages. So you often need to start a search inside the page to find what Google found. I prefer a fast scroll through the cached version looking for highlighting. But I can't do this with the new docs: (in the full version) the page is right shifted and the scrollbar is disabled. [1] http://lists.gnu.org/archive/html/lilypond-user/2008-10/pngwjlRMg29EL.png Cheers, Robin Title: doc search with URL filtering LANGUAGE any en fr es de OTHER OPTIONS exclude pdf / big-page stable development SEARCH IN everything NR LM IR AU Snippets Snippet source FOR GO Testbed for URL-filtered googling of the online docs Select the filtering and enter your search terms. The quotes are for phrases, and can be left empty. Use the Escape key to discard all search terms. The Enter key opens the search results in this window. GO does that too, but you can also - drag it onto an existing window / tab - let it open in a new window / tab. [context] [words in google] [words in urls] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Drum parts and horizontal beams
Carl D. Sorensen wrote: You could also go to the LilyPond Snippet Repository and search for beam: If you are feeling lucky you could also google for beam horizontal inurl:v2-11 site:lilypond.org/doc/ Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Francisco Vila wrote [Re: translated big pages]: Additionally, would it be possible to internationalize the "Back To Documentation Index" link? Some usability comments, please, before this gets translated. This is currently displayed as << Back to Documentation Index _a___ I suppose the "<<" is echoing the "<<" in the navbar. There, it means up and along, i.e to the preceding position in the linear sequence of higher nodes. But in this case there is no established linear sequence. It is therefore meaningless or confusing. _b___ "Back to" implies that the reader has been there. But those who came via search results or a mailing list post have not. And "Back" is already well established as a *history* step. (The navbar avoids this overloading by saying "Previous".) _c___ When you click on [Index] in the navbar, you are taken to "Lilypond Index" or somesuch; a long detailed list, such as you see in the back of books. This is what the reader is meant to understand by "Index". So "Documentation Index" raises the wrong expectations. This "Index" is surely web coder jargon; it doesn't belong at the user level. K I suggest removing "<<", "Back to" and "Index". "Documentation" is probably sufficient. After all, when you arrive at the page, this is all the title says. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Reinhold Kainhofer wrote: unless someone can come up with something better than "<<", which also indicates a navigational element But *you* did, some time ago! [Top][Contents][Index][ ? ] All you need is the above. See it at http://lists.gnu.org/archive/html/lilypond-user/2008-10/pngwjlRMg29EL.png Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Reinhold Kainhofer wrote: How about "Overview" instead of "Index"? A better choice! And I counter with "Documentation Home". But a second word is overkill. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: help with tieWaitForNote
Richard Wattenbarger wrote:
the d-flat tie doesn't render in the upper voice
When you ask for tieWaitForNote like this, it gets turned on for the voice
and doesn't affect any other voices, e.g. a voice for the right hand.
The << {} // {} >> construct needs two voices and sets up its own,
and these, by default, have tieWaitForNote turned off.
So you have to turn it on for these.
But you don't necessarily have to do this each time you use << {} // {} >>.
You can turn it on for all voices in this staff:
\set Staff.tieWaitForNote = ##t
And for "concave upward" you want not \slurDown but \tieDown, and just once;
but then you find that Lilypond won't let you say \once \tieDown.
Version 2.12 will support "_~" but for 2.10.33 you need something like
f!16( \once \override Tie #'direction = #DOWN des' ~ a'16~)
This gets nearly everything, but at the end there is no tie for the bes.
This is because the << {} // {} >> has put the bes16 and bes8 in
different voices, and ties don't cross between voices.
This case looks rather like just before where the low f is tied.
But that tie starts not on the f16 but on the f8.
You can do something similar here by introducing a b16 before the b8:
replace s4 bes'8 with s8. bes'16 ~ bes8
Learning Manual 4.6.1 tells you how to make this look nice.
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Reinhold Kainhofer wrote: No! After all, you are already reading the documentation, so a link to "Documentation" simply does not make sense. I was visiting LM 4.6.1 this morning, reading about tweaking output, and I wondered afterwards if, while there, I could have argued that a link to "Tweaking Output" simply would not make sense. Cheers, Robin http://lilypond.org/doc/v2.11/Documentation/user/lilypond-learning/Other-uses-for-tweaks ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Patrick McCarty wrote: I would greatly appreciate any feedback on the new color choices. My quoted "Yes please" was to "Blue in Green" which really shouted at you. This one is a lot more restrained but just as easy to read. OK, the tocpane is not unified with the navbar in any way, but I can accept this, because in this combination I think it well meets Reinhold's concern about the way it was "drawing more attention than the main pane" (And the tocpane contrast is much better than in the devlist version of a week ago.) In fact now that only the main text has blue links, they show up well when scattered around there; all the more so because the navbar is no longer competing for attention using the same means. So, yes please. And thank you! Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
Hallo. Me again, this time with a navbar suggestion. The first time I saw the navbar it seemed rather indigestible - so much text to read. But I did understand that the square brackets were indicating buttons. The second time was after visiting help, where I came to see that, for me at any rate, if you paid attention to the arrow heads, you didn't have to read all the text each time. And then I puzzled about the layout: [Up] seemed to be rather like [<<] and [>>], but it wasn't placed on their level. I supposed that was because you really needed three levels to hint at the destinations, i.e. [Top] [<<][Up ][>>] [< ] [ >] and this had been squashed together to save space: [<<][Top][>>] [< ][Up ][ >] So there wasn't very much you could do about it, because [Top]'s destination was obviously higher than [Up]'s destination. But recently I have come to see that it is not quite like that. The group [Top][Contents][Index][?] is a mixed bag: - [Index] goes in exactly the opposite direction to [Top] - [Contents] and [?] head off into Metaland - and [Top] might well have been less vertical e.g. [<<<]. So I think this group is pretty neutral as regards destination, and propose: L Swap the [Top] and [Up] groups in the navbar. This is accompanied by two adjustments: - replace [Up] with [^] this extends the signpost motif to a (squashed) compass rose motif, making the arrow heads that much more effective. - rename [Top] to the more neutral [Start] (as currently used in the tocpane tooltip text) Navbar.png shows an example of the result: [<<] [^] [>>] [< ][etc][ >] Cheers, Robin <>___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: partials and midi
Joe Mc Cool wrote:
Surely the repeat should play from
d4 d8 e d c.
What am I doing wrong ?
The \bar commands are only graphical.
They make it look, on paper, as if the repeat would start from d4.
But the repeat actually starts where you have placed the \repeat command.
Put the \repeat command in the right place.
This will also give you those barlines automatically,
so omit the \bar commands to avoid confusion.
\time 3/4
\key g \major
\partial 8*2 g'8 b
\repeat volta 2 {
d4 d8 e d c
b4 g g8 b
}
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: collision between glissando and sharp
Trevor Daniels wrote: This is a known bug - see issue 40. The workaround given there is: \once \override Glissando #'gap = #0.5 \once \override Glissando #'extra-offset = #'(-0.5 . 0) Hope that's good enough for you, as the bug priority is low! I was going to try and answer this one, having had to do this several times myself (using 2.10.33). But I got badly bogged down while checking my suggestion. This is because I have now moved to 2.12.1. A It seems to me that gap overrides are now ineffective. (And convert says nothing about this.) B With 2.12.1 a different override is effective: \override Glissando #'(bound-details right padding) = #2.5 This is a lot easier to apply! C And re issue 40 (gathering dust): Why did Graham's workaround specifiy a gap of 0.5? This was 2.7.5's default too. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \credenzaOn and forced line break
Chip wrote: How do I get a staff line to break when I am using \credenzaOn? Insert a \bar command where you want to allow a line break i.e.\bar ""(or \bar "|") I don't see any info on this in the manuals http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Line-breaking end of first paragraph Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: grace note without slurred but needs a slashed stem
Dmytro O. Redchuk wrote: You probably can make slur transparent? Or precede \grace with \once \override Stem #'stroke-style = #"grace" Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: grace note without slurred but needs a slashed stem
Mark Polesky wrote:
... with an identifier:
.. which can be adapted to cope with a group of grace notes:
mygrace = #(define-music-function (parser location music) (ly:music?)
#{ \override Stem #'stroke-style = #"grace" \grace $music
\revert Stem #'stroke-style #})
N.B. - any beaming suppresses such grace slashes.
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: newbie issues:repetition, midi & lyrics
Grateful Frog wrote:
how to get that out in a midi file that plays properly,
and only the melody not the lyrics and chords?
You can get the midi output to do repeats,
but it won't know about the D.C.
So give it a helping hand by defining
myNotesDC = {
\repeat volta 2 \notesOne
\repeat volta 2 \notesBridge
\alternative {
{\notesBridgeEndA}
{\notesBridgeEndB}
}
\relative c'
\notesOne
\notesCoda
}
and then set up a separate score block, just for the midi.
% MIDI Output
\score {
\unfoldRepeats { \relative c' \myNotesDC }
\midi {
\context {
\Score tempoWholesPerMinute = #(ly:make-moment 86 4)
}
}
}
Keep the first score block for the sheet music alone
i.e. remove its midi block.
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Unable to force hshift
Stefan Waler wrote: I'm not able anymore to set a manual shift for a note. Any workaround...? I'm not sure what you want. How about this? \once \override NoteColumn #'horizontal-shift = #-1 Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Issue with cross staff beam
A similar problem was discussed recently http://lists.gnu.org/archive/html/lilypond-user/2009-01/msg00530.html Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Unable to force hshift
Stefan Waler wrote:" \once \override NoteColumn #'horizontal-shift = #-1 As you can see, this is part of my score - but is has no effect. Please reconsider. There are two note-column-interface shifts; this is the other one. And if this turns out to be more like what you are looking for, you can then align the second f with \once \override NoteColumn #'force-hshift = #-0.5 Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: bar "||" kills start-repeat
Simon Bailey wrote:
so basically that paragraph is telling me to NOT use
the manual repeat barlines and use \repeat volta instead.
The documentation uses a lot of different names for repeats.
When you say "manual repeat barlines" it sounds as though
you may not be distinguishing
- manual barlines (inserted using \bar)
- manual repeats (inserted using \set Score.repeatCommands)
When BarLines says "various repeat commands"
the partially-initiated might think this means using the command
"\repeat" in its several variations such as "volta", "unfold", etc.
But I think it is referring to NR 1.4.1.[1] Specifically, the two sections on
- Normal repeats [2], which are applied to { ... }
- Manual repeat marks, which are inserted inline where branching can occur.
So instead of "manual barlines", have a look at "manual repeats".
[1] http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Long-repeats
[2] aka "standard", and maybe thought of as "automatic" because not "manual".
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staff collision because of a postscript line
Stefan Thomas wrote: Is there a possibilitie to avoid automatically this collision The eyeglasses example in NR B.8.3. uses the \with-dimensions command for this. \with-dimensions #'(0 . 3.5) #'(0 . 4) for your case? Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staff collision because of a postscript line
Stefan Thomas wrote: What does this \with-dimensions-command exactly do? Is it explained in the manual? It is mentioned right at the end of NR B.8.6. I think that by "dimensions" you are meant to understand the X-extent and Y-extent [1] of the markup that follows. I suppose that if the markup involves text, Lilypond can use the font information to calculate these dimensions, but if it involves just Postscript, Lilypond doesn't try. [1] as described for "ly:make-stencil" in NR B.15. Also mentioned in NR 5.5.1, second paragraph. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: phrasing slur continued through a repeat?
Well, \repeatTie doesn't take you very far into the ensuing phrase.
And it doesn't swoop properly.
A fairly easy way in this case is to add a hidden grace note:
{ \hideNotes \grace b16\( \unHideNotes c8 g8 c8 \) | }
And you can use the grace pitch to adjust the starting height.
This is usually necessary if you want to make the trailing fragment
appear any way related to the (both-times) leading section.
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: phrasing slur continued through a repeat?
Ed Ravin wrote:
Would the extra grace notes corrupt the MIDI output?
No.
But you can hear them, and you might think that inappropriate. :)
Try out this:
{ \once \override Rest #'transparent = ##t \grace b4\rest\( c8 g8 c8 \) | }
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: phrasing slur continued through a repeat?
Ed Ravin wrote: I'm guessing the silent rest somehow makes the grace note silent? I wanted a rest (for silence). If you say just "r32", lilypond gives you silence OK, but also does the vertical positioning automatically, so you can't adjust the slur any more. \rest lets you do the vertical positioning yourself: http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Writing-rests#Rests And \grace just squashes everything up; not just notes, but rests too. Omitting those spaces isn't primarily a shortcut, more an idiom for a common readability style. Most of the snippets are done like that. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: multimeasure rest with no number of measures?
Chipwrote: I want a multi-measure rest with no number on it. This gets rid of the number: mmrNoNum = \once \override MultiMeasureRestNumber #'stencil = ##f as in: \mmrNoNum R1*16 Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: controlling the alignment of FretBoards
Eluze wrote:
looking at the example(s) (\sourcefileline 765 and following) in _notation
reference_ the finger indications seem to be on the same line and so do the
top fret lines (in the pdf and html version).
when i compile these examples the results look different and unbalanced:
I get different results:
The current (2.12.2) online NR 2.4.1 at line 782 has
neither the first fret nor the fingering aligned.
It looks prrety much like your align_chordmode.png.
If I run the 782 snippet with my 2.12.1, it is aligned.
The F chord has no open/mute indications, so maybe it is less constrained vertically.
The following variation outlines the diagrams to reveal any vertical gaps:
%
\include "predefined-guitar-fretboards.ly"
mychords = \chordmode{
c1 f g
}
<<
\context ChordNames {
\mychords
}
\context FretBoards {
\override FretBoard #'stencil =
#(lambda (grob) (box-stencil (fret-board::calc-stencil grob ) 0 0))
\mychords
}
%
Cheers,
Robin
<>___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to tie a note in a chord to a note outside a chord
Jayaratna wrote:
This does not seem to work:
<<{\stemUp c2^~ c4}\\{\stemDown g4 \stemUp a4_~ a}>>
Well, this looks like (part of) what you want!
Or is it that you then don't see how to cope with the d2.?
The manual mentions connecting ties across voices
( Snippets / Rhythms / Making an object invisible with the transparent property)
but only deals with a simple case.
Using that approach here probably involves a _third_ voice,
which then needs some more tweaking to get things aligned.
But do you know about tieWaitForNote?
Try this:
%%
twfon = { \set tieWaitForNote = ##t }
twfoff = { \set tieWaitForNote = ##f }
\relative c''
<<
{c4 g4 \twfon c4^~ a4_~ 4 \twfoff 8 8 4 4}
\\
{g8 f8 e8 f8 g4 s4 d2. e4 }
%%
This is quite readable.
But if you insist on an exact match,
replace the c4^~ with c2*1/2^~
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: controlling the alignment of FretBoards
Carl D. Sorensen wrote: Please file a bug report Already started, now done. http://lists.gnu.org/archive/html/bug-lilypond/2009-02/msg00014.html ? Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: long text in "composer" / invisible TimeSignature
Zbyněk Burget wrote: How I can write long text to composer to header? Try composer = \markup \right-align "Some long text ... " If this isn't what you want, have a look at NR 3.2.1 where the demo splits the composer text onto two lines using \center-column. Why don't hide TimeSignature? I think this is because - "break-visibility" is (mainly) to do with responding to line breaks, - the start of the first line does not involve a line break. Not very convincing? Read more in NR 5.4.6 / Using break-visibility. So just override the stencil. Removing the engraver may disable other things as well. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: long text in "composer" / invisible TimeSignature
Zbyněk Burget wrote:
Splitting it onto two lines is unavailing. Therefore i want way to expanding
width of
this line.
The default layout puts poet, instrument and composer all on one line.
This is not compatible with the length of your composer text.
Even if instrument is unused, its (centred) layout is still active and this
obstructs leftward expansion of the composer text.
If you want to stay close to what the default offers, you could
move the composer field down onto its own line:
i.e. insert"" } \fill-line { "" into bookTitleMarkup
using the technique suggested in NR 3.2.2.
Cheers,
Robin
\paper {
bookTitleMarkup = \markup {
\override #'(baseline-skip . 3.5)
\column {
\fill-line { \fromproperty #'header:dedication }
\override #'(baseline-skip . 3.5)
\column {
\huge \larger \bold
\fill-line {
\larger \fromproperty #'header:title
}
\fill-line {
\large \smaller \bold
\larger \fromproperty #'header:subtitle
}
\fill-line {
\smaller \bold
\fromproperty #'header:subsubtitle
}
\fill-line {
\fromproperty #'header:poet
{ \large \bold \fromproperty #'header:instrument }
""
}
\fill-line {
""
\fromproperty #'header:composer
}
\fill-line {
\fromproperty #'header:meter
\fromproperty #'header:arranger
}
}
}
}
}
\header {
title = "title_line"
poet = "poet_line"
instrument = "instrument_line"
composer = "composer_line_20304050607080"
meter = "meter_line"
arranger = "arranger_line"
}
{s1*50}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Colliding rests warning
Nick Payne wrote: I couldn't find anything in the documentation. This comment in the rest collision source code might be relevant. TODO: look at horizontal-shift to determine ordering between rests for more than two voices. So maybe you just have to ignore it? Or do something like this :-) s32 \once \override Rest #'X-extent = #'( 2 . 2 ) \once \override Rest #'X-offset = #'-3 a8*3/4\rest Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Question: VerticalAxisGroup #'minimum-Y-extent
Thomas Scharkowski wrote:
Since Lilypond 2.11. this does not work anymore
I have a lot of single sheets based on a 2.10 template which ensured
I had enough vertical space for pencilling in fingering.
The vertical spacing rework in 2.11 gave me the same problem.
This is probably to do with the skyline feature which tries to let
the vertical outliers of neighboring systems mesh. This won't happen if
the system extents aren't allowed to overlap.
You can see this difference by redoing your two cases with the LSR 257 code
\layout {
\context {
\Score
\override System #'stencil = #box-grob-stencil
}
}
So minimum-Y-extent is pretty useless for this sort of thing.
Have a look at the \paper variables in NR 4.1.2, e.g. try
between-system-space = 29\mm
I found the Measure dialog box in GSview very useful when experimenting.
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: NR 4.3.6 Explicit Breaks
Chip wrote: Lily still breaks lines where it wants to. You are fighting something very powerful and don't know it. All that blank space on those pages! It is reasonable to think that saying \pageBreak means that you are quite happy with whatever blank space is needed to skip the rest of the current page. But the default page breaking algorithm doesn't see it the same way; it abhors that bare expanse, and tries to make your meagre snippets stretch all the way down to the bottom, i.e. it takes charge of the line breaking. What makes this confusing is that it seems to behave very erratically: some pages are stretched a lot, others hardly at all; just changing between A4 and Letter can make a big difference. Three alternatives: A In \paper, add page-spacing-weight = #0 which tells the default algorithm to let the blank space stay blank. But have you noticed how _long_ it takes to do what it does? B Replace the default algorithm with something less ambitious. In \paper, add #(define page-breaking ly:minimal-breaking) This runs more quickly. C The third way is different. Put each \score inside a \bookpart block (making \pageBreak redundant). This runs quickly too, BUT you may notice there are no page numbers (issue 715). In \paper, add the workaround print-first-page-number = ##t Then you can get rid of ragged-right and line-break-permission. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Slurs and repeats
Tim McNamara wrote: Is there a correct way to do this that I haven't been able to figure out? No. Not yet. But see the recent thread at http://lists.gnu.org/archive/html/lilypond-user/2009-02/msg00028.html Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Strange output from convert-ly
Mats Bengtsson wrote: try to nail down which conversion rule The rule for 2.1.27 (re tuning) prints this. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Writing text in a measure
Gilles Sadowski wrote: This seems to work for me (see attached files). But don't you need an \instrumentSwitch command near the end? Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Writing text in a measure
Kees van den Doel wrote.
on 2.12.2 it does *not* work. The output is attached. Bug?
It seems to me that LSR 258 is demonstrating only whiteout.
It is not demonstrating how to deal with the concomitant
horizontal layout problems, because it cheats here:
- uses ragged-right = ##f (with only one measure) to get lots of space
- uses extra-offset to move the text into this space.
And a newish bit of automagic confuses the issue:
- 2.12 does short snippets with ragged-right by default;
- 2.10 doesn't, and test2.ly specifies 2.10.
And the s4-\markup of test2.ly doesn't put the text halfway up.
You could do something like LSR 475 to get Lilypond to do the positioning.
http://lsr.dsi.unimi.it/LSR/Item?id=475
slashAndBurn = {
\once \override NoteHead #'stencil = #ly:text-interface::print
\once \override NoteHead #'text = #(markup #:whiteout
" Play loud random notes, then burn your instrument (30 s) " ) }
mm = \relative c'' {
a4 b c d |
\slashAndBurn a1 | % "a": vertical position "1": notehead only
e4 d e c |
}
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Text over fermata
Joseph Haigwrote: I get the text under the fermata. How can I force it above? Use \once \override Script #'script-priority = #-100 as mentioned in "Controlling the vertical ordering of scripts" in NR 1.3.1. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Parenthesizing chord names
Tim McNamara wrote:
Rather than writing a separate ending, I'd like to just parenthesize
the last three chords over the final two bars so they would render:
F(Ab7Dbmaj7C7)
ChordName outputs via text-interface, so the easiest way should be
\once \override ChordNames.ChordName #'text = "("
But this has no effect. It probably acts too early,
i.e. before the Chord_name_engraver has written its result to #'text.
Trevor answered a similar question a year ago:
http://lists.gnu.org/archive/html/lilypond-user/2008-03/msg00275.html
His solution modified the stencil, letting it overwrite #'text
just before printing.
As "addBrackets" it wrapped only a single chord, but you could
derive a left_only and a right_only version easily enough.
But if you want the bracket standing alone, how about setting up
a superfluous chord at the right place, and overwritung that?
See the snippet below; overwriteCN could also do things like "N.C."
Cheers,
Robin
%
\version "2.12.1"
overwriteCN = #(define-music-function (parser location text) (string?)
#{\once \set ChordNames.chordChanges = ##f
\once \override ChordNames.ChordName #'stencil = #(lambda (grob)
(ly:grob-set-property! grob 'text (markup $text))
(ly:text-interface::print grob)
)
#})
harmoniesA = \transpose f f {\chordmode {
f2:maj7 d2:m7 |
g2:m7 c2:7.9- |
f2 aes2:7 |
des2:maj7 c2:7 |
}}
harmoniesB = \transpose f f {\chordmode {
f2:maj7 d2:m7 |
g2:m7 c2:7.9- |
f4 \overwriteCN "(" f4 aes2:7 |
des2:maj7 c4:7 \overwriteCN ")" c4:7 |
}}
melody = \transpose f f' { \key f \major \time 4/4
\times 2/3 {a4 g'4 f'4} a4. e'8 |
d'4 bes8[ d8] a4 a8[ f8] ~ |
f1 ~ |
f1 |
}
\score {<<
\new ChordNames { \set chordChanges = ##t \harmoniesA }
\new ChordNames { \set chordChanges = ##t \harmoniesB }
\new Staff { \melody }
}
\layout {
indent = 0
ragged-right = ##f
}
%
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Parenthesizing chord names
Robin Bannister wrote:
As "addBrackets" it wrapped only a single chord, but you could
derive a left_only and a right_only version easily enough.
I wanted to see if I could make such a pair deliver something close
to what the OP illustrated, and managed this using \put-adjacent.
This itself requires a direction parameter (#LEFT / #RIGHT),
so I ended up with a onesided version. See below.
Features:
- adjustable bracket separation
- preserves chordname alignment
- compatible with non-default chordNameFunction
Cheers,
Robin
%
\version "2.12.1"
besideCN = #(define-music-function
(parser location which-side added-text) (integer? string?)
#{\once \override ChordNames.ChordName #'stencil = #(lambda (grob)
(ly:grob-set-property! grob 'text
(markup #:put-adjacent 0 $which-side ; #LEFT or #RIGHT
(ly:grob-property grob 'text) $added-text))
(ly:text-interface::print grob))
#})
harmoniesA = \transpose f f {\chordmode {
f2:maj7 d2:m7 |
g2:m7 c2:7.9- |
f2 aes2:7 |
des2:maj7 c2:7 |
}}
harmoniesB = \transpose f f {\chordmode {
f2:maj7 d2:m7 |
g2:m7 c2:7.9- |
f2 \besideCN #LEFT "(" aes2:7 |
des2:maj7 \besideCN #RIGHT " )" c2:7 |
}}
melody = \transpose f f' { \key f \major \time 4/4
\times 2/3 {a4 g'4 f'4} a4. e'8 |
d'4 bes8[ d8] a4 a8[ f8] ~ |
f2 ~ f2 ~ |
f2 ~ f2 |
}
\score {<<
\new ChordNames { \set chordChanges = ##t \harmoniesA }
\new ChordNames { \set chordChanges = ##t \harmoniesB }
\new Staff { \melody }
}
\layout {
indent = 0
ragged-right = ##f
}
%
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Again: stemBoth problem
Hu Haipeng wrote:
> I don't know whether this gives two stems
No, it doesn't.
It is just a chord, and a chord (in one voice) has only one stem.
In this case the still active \stemUp makes its stem go in a
different direction to the following \stemDown notes and so the
accompanying (automatic) beaming looks rather silly.
If you apply \stemDown to the chord too, the beamimg looks better,
but the "I" scale gets (a notehead but) no stem on reaching this chord.
\stemBoth provokes the silly beamimg here too. You need something like
stemBothTwoOne = #(define-music-function (parser location m) (ly:music?)
#{ << \voiceTwo $m \new Voice { \voiceOne $m } >> \oneVoice #})
to improve things in this particular case.
And you must know that \stemBoth doubles up not just the notes
but everything else as well - e.g. the "II" indication.
To modify only the second d of the prime chord, you would need to use
the \tweak command. But it can't modify stems, as noted in NR 5.3.4
http://lilypond.org/doc/v2.12/Documentation/user/lilypond/The-tweak-command
Maybe these are trivial difficulties compared to those you constantly
cope with, but, as a general priciple, I would have thought you would be
better off going with the flow:
not fighting Lilypond but rather
letting Lilypond do its graphic thing as much as possible.
This would mean accepting
> separate voices with plenty of confusing spacer notes
as the lesser of two evils.
musicI = \relative c' { c8(^"I" d e f g a b c | d) s2.. | s1 }
musicII = \relative c' { s1 | d'8(_"II" c b a g f e d) | s1 }
<< \voiceOne \musicI \\ \voiceTwo \musicII >>
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: smaller distance between first Staff and TimeSig
Stefan Thomas wrote: I can't reduce the distance between the TimeSig and the first Staff of the Score. How can I do it? Um, - don't override max-stretch? Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: glissando up from no note to a note
Chip wrote:
it just resulted in messed up measures
A judicious use of time distortion may help you here.
\transpose c c'{
\hideNotes g,32\glissando \unHideNotes c'4*7/8 c'4 c'4 r4 |
\hideNotes c''32\glissando \unHideNotes c'4*7/8 c'4 c'4 r4 |
a1*3/4\fermata \hideNotes d'4\glissando \unHideNotes |
ees8->[ c8]-> r4 r2 |
}
And then patiently adjust padding and minimum-length ...
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: glissando up from no note to a note
Andrew Wilson wrote: Shouldn't this be r2*3/4 \hideNotes d8\glissando \unHideNotes a'8 fs d b That works too. (Modifying the rest simplifies the beaming.) A subsequent proposal moved the rest more into the gap: s8 r2*1/2 \hideNotes a8\glissando \unHideNotes a'8 fs d b and I suppose the s8 fell off somewhere on the way to the list. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TrillSpanner edge-text
Benjamin Smedberg wrote: > the "tr" mark is still there. Yes, you can't easily tell how near you are to getting it right. Try \override TrillSpanner #'(bound-details left text) = ##f Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: repeat percent and chords
Kees Serier wrote:
I want to have the percent sign for a duplicate chord
in the next measure (in \chordmode).
I don't know how particular you are. Would this be good enough?
percentCN = \once \override ChordNames.ChordName #'stencil =
#(lambda (grob) (grob-interpret-markup grob (markup "%")))
harmonies = \chordmode {
c1 g1 e1:m \percentCN e1:m \percentCN e1:m a1:m bes1 c1 }
\score {<< \new ChordNames { \set chordChanges = ##f \harmonies } >>}
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: repeat percent and chords
Kees Serier wrote: but it is the "normal" percent sign with open zeros, where the repeat sign has filled zeros Yes, well, those repeat signs are site-mixed as it were, and I have no idea how to persuade the contractor to do an unscheduled job in unfamiliar surroundings. But I did find something a bit more suitable - an arabic percent. The proper sort has its dots up on their tips, like diamonds. But this font hasn't bothered with that, which is ok by me. So try this markup expression instead: (markup #:bold #:fontsize 1 #:char #x066A) Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: repeat percent and chords
Kees Serier wrote:
I get Guile errors
GUILE signaled an error for expression started here:
markup #
:bold #:fontsize 1 #:char #x066A
Well, it works at my end. Something is corrupted.
My best theory is that your version now ends
#'stencil = markup #:bold #:fontsize 1 #:char #x066A)))
i.e. that the middle bit has disappeared.
If it's not that, try this version with less Scheme in it:
simile = \markup { \bold \fontsize #1 \char ##x066A }
percentCN = \once \override ChordNames.ChordName #'stencil =
#(lambda (grob) (grob-interpret-markup grob simile))
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Problem with arpeggio across voices and fingering
Nick Payne wrote: What I want is the fingering just to the left of the notes and the arpeggio just to the left of the fingering. I'm pretty sure you ought to change the order in which these things are hung onto the side of the notes. But I'm afraid I can't help you with that. As regards horizontal tweaking, this is hampered by the fingering being referenced to the arpeggio. If both are referenced to the note it gets more manageable. Here is a hack which does such juggling: \once \override Staff.Arpeggio #'direction = #RIGHT \once \override Staff.Arpeggio #'padding = #-4 Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: repeat percent and chords
Neil Puttock wrote:
it's possible to duplicate its code in Scheme:
Or its appearance in markup ;-)
simile = \markup {
\combine \translate #'(0.3 . 1.5) \draw-circle #0.2 #0 ##t
\combine \translate #'(1.7 . 0.5) \draw-circle #0.2 #0 ##t
\rotate #90 \translate#'(0 . 2) \beam #2 #-1 #0.5 }
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: drum-sticking (textscript) order weird behavior
Roel Spruit wrote::
somehow the order in the output is reversed
That's queer.
With me (2.12) they both read R L from top to bottom.
However, with 2.10 they both read L R from top to bottom.
Are you using an intermediate version? ;-)
Is this suitable as a workaround?
LR = \markup \column { "L" "R" }
The collision is a known bug (247). See
http://lists.gnu.org/archive/html/bug-lilypond/2008-06/msg00105.html
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: repeat percent and chords
Kees Serier wrote:
Looks good, but how to use it, I'm only a beginning Lilypond user :-(
I have a vague feeling you may not have received
my reply diagnosing your arabic percent problem:
Kees Serier wrote:
I get Guile errors
GUILE signaled an error for expression started here:
markup #
:bold #:fontsize 1 #:char #x066A
Well, it works at my end. Something is corrupted.
My best theory is that your version now ends
#'stencil = markup #:bold #:fontsize 1 #:char #x066A)))
i.e. that the middle bit has disappeared.
If it's not that, try this version with less Scheme in it:
simile = \markup { \bold \fontsize #1 \char ##x066A }
percentCN = \once \override ChordNames.ChordName #'stencil =
#(lambda (grob) (grob-interpret-markup grob simile))
This third version replaces just the simile markup in the above first line,
so you should end up with:
simile = \markup {
\combine \translate #'(0.3 . 1.5) \draw-circle #0.2 #0 ##t
\combine \translate #'(1.7 . 0.5) \draw-circle #0.2 #0 ##t
\rotate #90 \translate #'(0 . 2) \beam #2 #-1 #0.5 }
percentCN = \once \override ChordNames.ChordName #'stencil =
#(lambda (grob) (grob-interpret-markup grob simile))
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Transpose
Ossie Wilson wrote:
I have attached the Ly file
After a cursory look, I would say this file is
badly mangled as regards key signatures.
In part one at bar 29 it helps to say
\key dfinstead of\key cs
because the subseqent notes are e.g. df, gf, ...
Also part one should declare _at_least_ one
additional key change: at bar 13, to \key gf \major
This is odd because to insert this in the "low" voices
you have to first split up the initial 26 silent bars.
But then again, at the top it says
"Generated from a MIDI File by LyFromMIDI ..."
So \transpose isn't really your problem at the moment.
You have to get it looking right in the original first.
Cheers,
Robin
P.S. And yes, Win98 users are stuck at 2.8. \version "2.8.6"
\paper {
#(set-paper-size "a4")
line-width = 20\cm
print-page-number =##t
printfirst-page-number = ##t
between-system-space = 0.1 \cm
after-title-space = 0.1 \cm
ragged-bottom =##f
ragged-first-bottom = ##f
top-margin = 0.16 \cm
head-separation = 0.04 \cm
bottom-margin = 0.1 \cm
left-margin = 0.4 \cm
}
#(set-global-staff-size 18)
\include "english.ly"
\header {
composer = "Richard Rodgers"
poet = "Oscar Hammerstein II"
copyright = "" %"Copyright © 2006 by O.A.Wilson"
title = "If I Loved You"
subtitle = ""
tagline ="" % "Generated from a MIDI File by LyFromMIDI and then Typeset by LilyPond"
}
melodyone = {
\time 2/4
\key g \major
\clef treble
\stemNeutral
% Bar 1
\tempo 4 = 104
R1*2/4
% Bar 2
R1*2/4
% Bar 3
R1*2/4
% Bar 4
r4 d'8 d' \break
% Bar 5
g'4 g'8 g'
% Bar 6
g'2
% Bar 7
g'8 d' g' a'
% Bar 8
g'4 r8 d'8 \break
% Bar 9
g'4 g'8 g'
% Bar 10
g'8. d'16 g'8 a'
% Bar 11
g'2 ~
% Bar 12
g'4 r8 g'8 \break
% Bar 13
\key gf \major
gf'8. gf'16 gf'8 gf'
% Bar 14
gf'8 gf'4 gf'8
% Bar 15
gf'8. gf'16 gf'8 gf'
% Bar 16
gf'8 r8 gf'8 gf' \break
% Bar 17
gf'4. gf'8
% Bar 18
gf'4 gf'8 gf'
% Bar 19
gf'2 ~ \break
% Bar 20
gf'8 \breathe r8 gf'8^\markup {\italic {meno mosso } } gf'
% Bar 21
bf'2
% Bar 22
bf'2 ~
% Bar 23
bf'2 ~ \break
% Bar 24
bf'4^\fermata \breathe r8 bf'8
% Bar 25
bf'8.^\markup {\italic { poco rit. }} ef'16 ef'8 ef'
% Bar 26
ef'4. ef'16 ef'
% Bar 27
f'8 af' df' f' \break
% Bar 28
c'2^\fermata \bar "||"
% Bar 29
\key df \major
\time 4/4
df'2^\markup {\italic "a tempo (" \smaller \note #"4" #1 " = 82)"} f'
% Bar 30
bf'4 bf'2. \break
% Bar 31
df''4 ~ \times 2/3 {df''8 c'' bf'} af'4 ~ \times 2/3 {af'8 gf' f' }
% Bar 32
ef'4 df' f'2
% Bar 33
ef'2 gf' \break
% Bar 34
c''4 c''2 df''4
% Bar 35
af'1 ~
% Bar 36
af'2. r4 \break
% Bar 37
df'2^\markup {\italic "piu mosso" } f'
% Bar 38
bf'4 bf'2.
% Bar 39
df''4 ~ \times 2/3 {df''8 c'' bf'} af'4 ~ \times 2/3 {af'8 gf' f'} \break
% Bar 40
ef'4 df' f'2
% Bar 41
ef'2 gf'
% Bar 42
c''4 c''2 df''4 \break
% Bar 43
df''1 ~
% Bar 44
df''2 ~ df''4 r4 \mark \markup { \musicglyph #"scripts.segno" }
% Bar 45
\bar "||" df''2 c''4 bf' \break
% Bar 46
af'4 gf' r4 af'8 bf'
% Bar 47
c''2 c''
% Bar 48
c''2 ~ c''4. r8 \break
% Bar 49
df''2 c''4 bf'
% Bar 50
af'4 gf' af' bf'
% Bar 51
ef''2 ef'' \break
% Bar 52
ef''2 ~ ef''4. r8
% Bar 53
df''2 f'
% Bar 54
bf'4 bf'2. \break
% Bar 55
df''4 ~ \times 2/3 {df''8 c'' bf'} af'4 ~ \times 2/3 {af'8 gf' f' }
% Bar 56
ef'4 df' f'2
% Bar 57
ef'2 gf' \break
% Bar 58
c''4 c''2 df''4^\markup { \hspace #3.4 "to CODA" } \mark \markup { \musicglyph #"scripts.coda" }
% Bar 59
f''1 ~
% Bar 60
f''2. r4 \break
% Bar 61
ef''2 f''
% Bar 62
gf''4 gf''2. ~
% Bar 63
gf''2. r4 \break
% Bar 64
bf'2^\markup { \italic rit. } c''
% Bar 65
df''4 df''2. ~
% Bar 66
df''2 r2^\markup { \hspace #-4.5 {\large \bold {"D.S. al " \raise #1 \musicglyph #"scripts.coda" " CODA" }}} \bar "||" \break
}
% End of Notes
melodytwo = {
\time 4/4
\key df \major
\clef treble
\stemNeutral
% Bar 67
\set Score.currentBarNumber = #67
f''1^\markup { \hspace #'-4 \raise #2 { \large \bold \musicglyph #"scripts.coda" \raise #-1 " CODA" } } ~
% Bar 68
f''2. r4
% Bar 69
ef''2 f''2 \break
% Bar 70
gf''4 gf''2. ~
% Bar 71
gf''2. r4
% Bar 72
bf'2^\markup { \italic "rit." } c''
% Bar 73
df''1^\markup { \italic "a tempo" } \break
% Bar 74
df''1 ~
% Bar 75
df''1 ~
% Bar 76
df''2. r4 \breathe
% Bar 77
R1^\fermataMarkup \break
% Bar 78
\bar "|."
}
textone = \lyricmode {
When I worked in the mill, weav -
Re: How to input keysignature or timesignature in \markup?
Wei-Wei Guo wrote: I still have no idea how to input some music symbols, such as a short piece of pure staff, timesignature, keysignature, and so on. Search the snippet repository for "engravers". In particular, try out the (complete) snippet in http://lsr.dsi.unimi.it/LSR/Item?id=280 Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: shift lyrics closer to staff
Marek Klein wrote:
I tried it using the commented line, but it didn't work
You can make the cantus more approachable.
Adjust the -2 to taste.
\include "gregorian.ly"
\score {
<<
\new VaticanaVoice = "cantus" {
\override Staff.VerticalAxisGroup #'minimum-Y-extent = #'(-2 . 4)
\[ c'\melisma c' \flexa a \]
...
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LaissezVibrer tie on single note of chord
Nick Payne wrote:
Is this possible without faking the chord by creating two voices?
Sometimes I like to show in my piano fingering that
one finger of a chord should temporarily act as a pivot
while the other fingers are moving to the the next chord.
Maybe there is a recognised symbol for that, I don't know.
Introducing a subsequent short note so that you can
tie to it is overkill, and distracts the (sight-)reader.
I had two problems with using laissezVibrer for this:
- it applies to the whole chord
- it affects the spacing.
So I recently cooked up the following stencil override.
The pseudo-tie is ignored by the spacing, which is what I wanted.
But that probably won't suit you.
And it's bigger; so it doesn't mix well with the real thing.
%
% laissezVibrer using feta char overlay: dir: UP or DOWN (or pad per magnitude)
#(define (flvSt dir) (lambda (grob)
(define dirsign (if (positive? dir) + -) )
(let* ((pos (ly:grob-property grob 'staff-position))
(height (if (odd? pos) +0.8 +0.55)) (angle +90))
(ly:stencil-combine-at-edge (ly:note-head::print grob) 0 1
(grob-interpret-markup grob (markup #:with-dimensions '(0 . 0) '(0 . 0)
#:concat (#:hspace (abs dir)
#:raise (dirsign height)#:rotate (dirsign angle)
#:musicglyph "accidentals.rightparen" ))) 0 0
flvUP = \once \override NoteHead #'stencil = #(flvSt UP)
flvDOWN = \once \override NoteHead #'stencil = #(flvSt DOWN)
% or \tweak #'stencil ___ditto
flvUPtw =
#(define-music-function (parser location mus) (ly:music?)
(set! (ly:music-property mus 'tweaks) (acons 'stencil
(flvSt UP) (ly:music-property mus 'tweaks))) mus)
flvDOWNtw =
#(define-music-function (parser location mus) (ly:music?)
(set! (ly:music-property mus 'tweaks) (acons 'stencil
(flvSt DOWN) (ly:music-property mus 'tweaks))) mus)
%
\relative c' {
\laissezVibrer s4
<\flvDOWNtw a \flvUPtw e'> s4
s4
<\flvDOWNtw a e'> s4
}
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tip/Trick: Double-Breve or Single-Breve-with-Double-Sidebars
Kieren MacMillan wrote: This function should be good at least as far back as v2.10. \draw-line was introduced after 2.10. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LaissezVibrer tie on single note of chord
Nick Payne wrote:
the laissezVibrer tie specified in the bass voice also appears
on the two simultaneous notes in the treble voice.
This is because of the names you gave your voices.
They happen to be the same as those automatically chosen by
the << { } \\ { } >> construct.
So at this point the voice named "1" gets not only
- 8.from the treble, but also
- a8. from the bass,
and it combines these to a chord with three notes.
The \laissezVibrer requested for that moment in voice "1"
is applied to (all) the notes occurring in voice "1".
If you rename the treble voice, this bass note is left uncombined
and you can see it no longer shares a stem with the treble notes.
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LaissezVibrer tie on single note of chord
Nick Payne wrote:
Is this possible without faking the chord by creating two voices?
Is this more what you are looking for?
It is not all that easy to use:
- you have to work out the position, e.g. -9, by yourself
- and it won't move when you transpose.
See IR 3.2.84.
%
singleLV =
#(define-music-function (parser location pos dir) (integer? integer?)
#{
\override LaissezVibrerTieColumn #'tie-configuration =
#(make-list 8 (cons $pos $dir) )
$(make-music 'EventChord 'elements
(list (make-music 'LaissezVibrerEvent)))
#})
%
treble = \relative c {
4 \singleLV #-9 #DOWN 8. g''32( f) g8. e16
}
bass = \relative c {
4
\once \override Stem #'flag-style = #'no-flag e'8.
r16 r8. 16
}
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Custom guitar chords
Miklos Vajna wrote:
First, currently the output has "Bm" for my chord,
but actually I would like to have it as 'Bm \super "omit3"/A'.
Like this? (verbatim)
replaceCN = #(define-music-function (parser location new) (markup?)
#{\once \override ChordNames.ChordName #'stencil =
#(lambda (grob) (grob-interpret-markup grob $new)) #})
BmsusA = \markup {Bm \super "omit3"/A}
\chords { e1:sus4 g e:m \replaceCN \BmsusA b:m }
Cheers,
Robin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Fingerings with Flat Symbol
Jonathan Townes wrote: the use of fingerings would be much faster and require less typing This nice aspect of fingerings is due to the parser knowing what a fingering looks like. But this is defined as being a single digit, so you only have ten things you can ask for (corresponding to 0 .. 9). Writing your own version of fingering::calc-text lets you choose what these ten things are, but you can't get any more than ten. So you are limited to ten combinations, which is nowhere near enough. Cheers, Robin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
