GDP: staff section
Hi GDP-helpers! I started now finally with the staff section of NR1. As with the repeat section, I would also suggest some new grouping. The order of the section is now the following: # 1.6 Staff notation * 1.6.1 Displaying staves o 1.6.1.1 System start delimiters o 1.6.1.2 Staff symbol o 1.6.1.3 Hiding staves * 1.6.2 Writing parts o 1.6.2.1 Metronome marks o 1.6.2.2 Instrument names o 1.6.2.3 Quoting other voices o 1.6.2.4 Formatting cue notes I was first wondering why writing parts is here at all, but I guess this should not be discussed too broad now, because it had been discuessed when we decided about the GDP chapter order. I was just thinking that combining parts and writing parts would be together something like a orchestral chapter -- even though you use it also in chamber music and the like. So I hope this grouping as it now is is intuitive enough to a new user that he figures out where to look for. The 1.6.1 section is really unevenly distributed over the three subsubsections, I was thinking of introducing a new subsection: modifying staves which would contain most of 6.1.1 and 6.1.2 So the new section model could be: 1.6 Staff notation 1.6.1 Displaying/writing/setting staves 1.6.1.1 Initiating a new staff (short basics, also one sentence about \new and \context, here should also go the example about starting stopping additional staves) 1.6.1.2 Grouping staves (about system start delimiters (maybe: 1.6.1.3: Deeper nesting of staff groups) 1.6.2 Modifying staves 1.6.2.1 Staff symbol, (and how to modify the different parameters) 1.6.2.2 Ossia staves 1.6.2.3 Hiding staves 1.6.3 Writing parts ... I have concentrated for now on this part leaving the parts section alone, I want to come back to it only when the first part is in better condition. There are still some general questions for the parts section for which I would like to hear some feedback: -Why is the metronome mark described here? It applies as well to a whole score (where it would be agreedly on the top stave...), and I think it should go together with a general description on how to write tempo indications (and also with a workaround to align the indication with the key or the meter, not with the first note of the first bar). Where could this section go? It is currently discussed in text marks, 1.8.1.4, but meant to write rehearsal marks, not tempo indications. -I think it is actually almost a bug in lilypond that there is no easy way to center the beginning of a tempo indictation on the key symbol, so I think it is important to provide at least an workaround clearly marked as such for this purpose. -We see the parts section as the sections that explains everything general about single parts -- so in this sense the metronome mark belongs here and also the tempo indication. But to me (and my German ears) the section caption points at preparing parts for each instrument of a bigger score. So I think we should change this section's caption. Ideas? -To me there is a distinction between the two first subsubsections (metronome marks and instrument names) and the two last (quoting voices and cue notes): the first two I would see more generally apllying to staves for each instrument/voice, the two last are what I understand by the word part, mainly concerned about the case where one has only one's own part and needs to get some context into it. So I could even imagine still a new subsection: 1.6.3 Additions to specific staves 1.6.3.1 tempo indication 1.6.3.2 metronome mark 1.6.3.3 instrument name 1.6.4 Adding context to a single part 1.6.4.1 quoting 1.6.4.2 cue notes But this is only a first thought. Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
GDP: NR 1.1 comment
Hi, I just noticed that the staff contexts of the examples in 1.1.3.5 are PianoStaff. In 1.6 there is only mentioned GrandStaff. Which one is the preferred one to be used? I would mention both in 1.6, but I think we should develop guidelines which context names to use. Maybe the PianoStaff is (at least to others than English native speakers) more understandable? So the context would be called PianoStaff in 1.6.1 but I would also mention that there is a GrandStaff context? So far I have understood that they are both equal. Is this true? Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: \time; staccato MIDI output
Hi Trevor,
Taking the \time's out of the definitions is the best
approach. As timing is done by default at the score level
it is not necessary to include \time commands in both parts.
So I would write it this way (I prefer to explicitly declare
the Staves):
[snip]
Thanks. I think I'll use this approach.
It should be possible to replace a staccato note with one of
half the value followed by a spacer with the same duration
using Scheme, but you'd need to fully digest section 6 of
the Notation Reference first. You would have to unpick the
input stream, look for staccatos, expand them, and rebuild
the input stream.
As for staccatos, I twigged that I can use a simpler approach to start
off with. I can change the staccato notes as they're inserted, instead
of doing it afterwards. The key is to define the musical expressions in
functions, so that a different definition of addStaccato is used for
print output versus MIDI output.
Defining addStaccato for print output is easy, as it's almost the
addMarcato example in the docs. I haven't quite got it working for MIDI
output yet, but I almost know what I'm doing :-). It's just modifying
(make-music) expressions of a particular form into a different form...
Then when that works, I can extend it to change staccatos after
they've been inserted.
So just FYI I'm using something like this:
addStaccato = #(define-music-function (parser location event-chord)
(ly:music?)
(
; function which adds a staccato ArticulationEvent, for layout
; output
)
instrumentOne =
#(define-music-function (parser location)
()
#{
\relative
{
{ c'4 c4 c4 } \addStaccato c d |
}
#}
)
\score
{
\instrumentOne
\layout {}
}
addStaccato = #(define-music-function (parser location event-chord)
(ly:music?)
(
; function which replaces EventChords with a SequentialMusic of a
; shorter chord followed by a RestEvent. For MIDI output.
)
\score
{
\instrumentOne
\midi {}
}
Regards,
--
Iain Nicol
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
Am 24.02.2008 um 14:29 schrieb till: Andrew Hawryluk-2 wrote: OK. maybe this isn't advertising, but as a recovering Finale user I have been taking notes about what it was like to try LilyPond for the first time. The first three installments of those writings are now posted on my site and, of course, the LilyPond output looks marvellous: http://www.musicbyandrew.ca/finale-lilypond-1.html Really nice, thank you for that! I was just wondering what is it then that you like so much in Finale? You said both are good, but for different things. What is this thing? Is it that it is easier to correct typesetting errors in Finale? Greetings Till Being in a similar situation, it's a lot quicker to get something into finale and see it on paper, or hear a rough sketch in MIDI. In terms of pure notation, what takes 10 minutes in lilypond often takes 5 in Finale. But, when it comes to fixing things, because finale needs to have so many things fixed, usually across every part or every page of a score, what takes 20 minutes in lilypond can take 80 minutes in finale. So, for just getting something quick, that doesn't really have to look good, finale is definitely faster, but for something beautiful that's easy to fix, lilypond is definitely preferred, at least on my end. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
Hi James, for just getting something quick, that doesn't really have to look good, finale is definitely faster Several years ago, I would have called myself a Finale expert: in addition to over a decade of use (typesetting well over a hundred scores, including my Master's Thesis, starting with Finale v2), I was even paid as a Finale tutor while I was doing my Master's (1994-7). Therefore, I feel like I can speak from a pretty good place of competence in this regard... With the one possible exception of playing the music into Finale from a MIDI keyboard, my experience is PRECISELY THE OPPOSITE of yours: using just a computer with (QWERTY) keyboard and mouse, I can get *any* score into Lilypond at least as quickly as I could into Finale, and most scores I figure I get the notes on to the page in 25-50% of the time required for Finale. The tweaking -- which ALWAYS takes longer with Finale -- just cements Lilypond's advantage. So, I'm curious... 1. Are you simply talking about Step-Time Entry (or whatever they currently call note-entry using a MIDI keyboard), or with QWERTY keyboard and mouse? 2. If you still find Finale faster at note-entry without a MIDI keyboard, what is slowing you down? (e.g., Do you not have good standard templates set up? Is there something about the syntax that consistently trips you up or confuses you?) Best regards, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
optionally wrapping a two-line title
[Lilypond 2.11.37]
Hi y'all!
I've got
\header
{
title = Fantasy Variations on a Theme by Charpentier
}
and *only* in certain places (e.g., the \scoreTitleMarkup) I'd like
to have this on two lines [split before the on], whereas in other
places (e.g., the footer, colophon, etc.) I'd like the complete line.
What's the best way to accomplish this?
I've considered using subtitle to hold the second line, and then
concatenating them when I need to... but that's less clean than I'd
like.
Any suggestions would be greatly appreciated!
Best regards,
Kieren.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
Hi Joseph, Another third-party view What makes Finale and Sibelius nice in many situations is that they are not just notation tools but _composition_ tools, which allow you to enter into a dialogue between notation, playback and performance. As a result, it tends to smooth the passage between experimental and sketching stages of composition and producing the final score. Lilypond is more suitable for a case where you already know precisely what you want to notate. Good point. I do *all* of my composition with paper and pen(cil), and only use the computer for engraving -- therefore, none of the [undeniable] benefits you mention are applicable to me (i.e., my compositional process). Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
till wrote: I was just wondering what is it then that you like so much in Finale? You said both are good, but for different things. What is this thing? Is it that it is easier to correct typesetting errors in Finale? Another third-party view What makes Finale and Sibelius nice in many situations is that they are not just notation tools but _composition_ tools, which allow you to enter into a dialogue between notation, playback and performance. As a result, it tends to smooth the passage between experimental and sketching stages of composition and producing the final score. Lilypond is more suitable for a case where you already know precisely what you want to notate. To take an example, recently I was working with a friend on some songs: I used Rosegarden to sketch out the notes and rhythms and to play around with some ideas we wanted tested, and then later used Lilypond to produce the final notation. With Finale, a step would have been removed in that process. Further benefits of Finale/Sibelius: you can concern yourself purely with what the score looks like and not have to worry about the underlying data structures (this is a disadvantage sometimes, too); typo spotting and correction is indeed easier (the close relationship with playback helps here); and it's much easier to be very precise with the visuals of your notation. I'm very, very fussy about the precise placement of dynamic marks and other such notation and this is non-trivial with Lilypond. Of course, Lilypond has some BIG advantages. For example, what other notation program can understand and logically and correctly interpret a 7/10 time signature? Perhaps not a big issue for a lot of people, but it does say a lot about the power and flexibility of Lilypond's data structures. -- Joe ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Lilypond on Mac Leopard: AppleScript solution
Hallo all, For those of you on Mac OS X Leopard: To make it easier to use Lilypond under Leopard, I wrote an AppleScript and an information page. You can find both at http://ivo.bouwmans.name/lilypondleopard/. (Several people asked me to send this info to the user list, so here you are.) I hope you will find it useful. Comments and suggestions are welcome! -- Vriendelijke groeten, = Best wishes, = Afablajn salutojn, Ivo www.ivo.bouwmans.name ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
I was just wondering what is it then that you like so much in Finale? You said both are good, but for different things. What is this thing? Is it that it is easier to correct typesetting errors in Finale? Yes, I left most of that discussion for later, but to be brief, Finale's advantages for myself include: - I already know how to do almost everything that I regularly need and have gotten pretty fast, but on LP I'm still a bubmling beginner who has to look stuff up all the time. - For single-note melodic passages, my LilyPond typing skills are only marginally slower than entering the data into Finale by any method, but for piano music with large chords (and especially in keys with many sharps/flats) I am much faster entering a whole chord at time from MIDI keyboard. - Instantly playback (proofread) whatever passage you just entered, not the entire MIDI file - Some multi-staff editing operations are much easier in Finale, e.g. in a score with a dozen staves I want to insert four empty measures after measure 43. - Compatablilty with the rest of the world. I was once able to reduce an hour of orchestral music to an eight piece ensemble without entering any notes because the composer was willing to send me his Finale files. After that experience I will probably never uninstall Finale. Of course, as I begin to understand the best ways to do things in LilyPond it gets easier and easier, but these are some of the hurdles that a recovering Finale user goes through. Cheers, Andrew ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
Le 24 févr. 08 à 18:27, Andrew Hawryluk a écrit : I was just wondering what is it then that you like so much in Finale? You said both are good, but for different things. What is this thing? Is it that it is easier to correct typesetting errors in Finale? Yes, I left most of that discussion for later, but to be brief, Finale's advantages for myself include: - [...] - Instantly playback (proofread) whatever passage you just entered, not the entire MIDI file Note that using a clever enough editor, you can have instant audio feedback when entering notes for LilyPond too. And indeed this is very useful. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
Nicolas Sceaux wrote: Note that using a clever enough editor, you can have instant audio feedback when entering notes for LilyPond too. And indeed this is very useful. Can you give some examples and some comparisons? ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: NR 1.1 comment
Quoting Till Rettig [EMAIL PROTECTED]: Hi, I just noticed that the staff contexts of the examples in 1.1.3.5 are PianoStaff. In 1.6 there is only mentioned GrandStaff. Which one is the preferred one to be used? I would mention both in 1.6, but I think we should develop guidelines which context names to use. Maybe the PianoStaff is (at least to others than English native speakers) more understandable? So the context would be called PianoStaff in 1.6.1 but I would also mention that there is a GrandStaff context? So far I have understood that they are both equal. Is this true? In version 2.11, the only difference between the two is that PianoStaff contains the instrument name engraver. In version 2.10 and earlier, there were more differences. The PianoStaff then produced a fixed distance between the staves, since the cross-staff slurs and beams didn't work otherwise. This limitation has been fixed in 2.11. /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
Le 24 févr. 08 à 19:56, Joseph Wakeling a écrit : Nicolas Sceaux wrote: Note that using a clever enough editor, you can have instant audio feedback when entering notes for LilyPond too. And indeed this is very useful. Can you give some examples and some comparisons? I use a home made emacs mode, named lyqi, which makes it possible to enter notes and change their duration, alteration, octave, etc, with few key strokes, and with audio feedback. The page, with some source code, can be found here: http://nicolas.sceaux.free.fr/lilypond/lyqi.html I'm using a key map described here: http://nicolas.sceaux.free.fr/index.php/2006/07/01/8 Using that, I've entered all the scores that can be found there (save Giulio Cesare, that I've typeset before, using denemo). I would not enter music without it now, because of the speed I acquired, except keyboard music maybe (lyqi lacks polyphony support). It would be great if the canonical LilyPond editor, jEdit+LilyPondTool, had such a feature, for the few people that have tried quick insert mode find it very valuable for these two advantages: speed and instant pitch error check. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
Some more usability notes. I'm only a folk singer and guitar player, but a professional typesetter. My first notation program was some crap that I got with an used Mac (forgot the name, it was discontinued). On Linux I tried some very early version of LilyPond but never got it to work (font issues, AFAIR). The same with MusiXTeX. For some years I worked with Harmony Assistant by Myriad. It's a rather cheap shareware and very good for its price - it has interesting audio features and its notation output is at least usable for print - but ugly in comparison to Finale or LilyPond. I can't play keyboard, therefore MIDI keyboard input is no way; placing notes with a mouse needs forever; character keyboard input is usable and fast, but limited. I really liked how I could copy paste passages and transpose (parts of) them with a few keystrokes. Lyrics handling was nasty and got other bugs to workaround with every version. You still find a lot of samples in my Liederliste homepage. Can't remember why I tried LilyPond in 2005 again - I guess I was looking for better printable notes. (I do a Unitarian church magazine that features a song in every issue.) Using TeX for some years and programming since age 14 I had no threshold using the command line interface. Until now I've good templates for my usual kind of work - folk songs with one or two voices or choir settings. For lyrics I sometimes have to use dirty tricks (e.g. if the number of syllables differs in a repeat), but otherwise I'm very happy. Note and chord input works often blindly typing and is rather fast. But LilyPond code is kind of a write only format - even with only one measure per line and some remarks inbetween it gets very hard to read or to find some stuff, and I miss a relation between the same measure in different voices, that makes debugging sometimes very hard. (point click often doesn't work right.) My former girlfriend, an Irish folk fiddler, could hardly read notes and was used to write down her tunes as c d e f g with spacing indicating note length. When I gave her a simple LilyPond template, she could stick with most of her habits and learned to use simple stuff like \repeat very fast, even if she didn't understand most computer stuff. So LilyPond *maybe* even good for beginners. ;-) My choir director uses Finale, and I guess he doesn't tweak much, so some parts of our choir notes are rather ugly, esp. lyrics alignment (as proven by the OP). No, I don't think I can convince him to use LilyPond ;-) And as I'm used to LilyPond's soft, classical engraving, I find Finale's just a bit too cool and pointy. And I guess his printer is too low-res... What I miss using LilyPond: - EPS or PDF output without unneccessary whitespace and without additional files! (for placement in a layout app or processing with TeX) - possibilities to tweak the MIDI for nicer results (not LilyPond's scope, I know) - automatic pickup measures in line breaks (no, Harmony can't do that, but I saw it in Capella) - save transposed parts as source - some special chord notation (after reading the latest discussion on jazz chords I guess my ideas are doable, though...) - simpler possibilities for additional lyrics below the scores (song sheets) - sound prehear with cursor in the note preview - better overview in longer parts (don't know how - code folding, measure counter...?) The last two would be features of an editor/previewer and not of LilyPond itself. Maybe jEdit/LPT can already do that, but most Java apps are just too slow on my old Mac G4, and I hate this typical Java GUI (Swing?)... Greetlings from Lake Constance --- fiëé visuëlle Henning Hraban Ramm http://www.fiee.net http://angerweit.tikon.ch/lieder/ https://www.cacert.org (I'm an assurer) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
Ok, here's the rub: we have this mechanism called concave beams, see http://lilypond.org/doc/v2.11/input/regression/collated-files#beam-concave.ly: Beams whose inside notes get closer to the beam than the edge notes should be horizontal. This is pretty obvious for single-voice notes; for chords it gets hairier: which part of the chord notes do we use to decide this? Right now, we use the notes farthest away from the beam. We could use the top notes (the highest is the melody?) instead. What do you think? [hmmm, the #filename links are broken; we get the full path name now. Is this something recent? John?] 2008/2/24, Werner LEMBERG [EMAIL PROTECTED]: OK. maybe this isn't advertising, but as a recovering Finale user I have been taking notes about what it was like to try LilyPond for the first time. The first three installments of those writings are now posted on my site and, of course, the LilyPond output looks marvellous: http://www.musicbyandrew.ca/finale-lilypond-1.html *Very* nice, especially the references to lilypond bugs :-) Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
On 24.02.2008, at 16:36, Kieren MacMillan wrote: Hi James, for just getting something quick, that doesn't really have to look good, finale is definitely faster Several years ago, I would have called myself a Finale expert: in addition to over a decade of use (typesetting well over a hundred scores, including my Master's Thesis, starting with Finale v2), I was even paid as a Finale tutor while I was doing my Master's (1994-7). Therefore, I feel like I can speak from a pretty good place of competence in this regard... With the one possible exception of playing the music into Finale from a MIDI keyboard, my experience is PRECISELY THE OPPOSITE of yours: using just a computer with (QWERTY) keyboard and mouse, I can get *any* score into Lilypond at least as quickly as I could into Finale, and most scores I figure I get the notes on to the page in 25-50% of the time required for Finale. The tweaking -- which ALWAYS takes longer with Finale -- just cements Lilypond's advantage. So, I'm curious... 1. Are you simply talking about Step-Time Entry (or whatever they currently call note-entry using a MIDI keyboard), or with QWERTY keyboard and mouse? 2. If you still find Finale faster at note-entry without a MIDI keyboard, what is slowing you down? (e.g., Do you not have good standard templates set up? Is there something about the syntax that consistently trips you up or confuses you?) Best regards, Kieren. oh, I don't (didn't) use the MIDI entry much. I used mostly the simple entry, with keyboard commands modified from igor engraver. I think it's just that I have to completely re-work the way I think to put music into lilypond. Oh, I get the stuff into lilypond easily enough, lilypond requires me to adapt to it to put music in, while finale adapts to me to put music in (i.e., I can change the QWERTY keyboard commands to something that makes sense to me in finale.) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Concave beams (was: free LilyPond advertising)
2008/2/24, Rune Zedeler [EMAIL PROTECTED]:
Han-Wen Nienhuys skrev:
This is pretty obvious for single-voice notes; for chords it gets
hairier: which part of the chord notes do we use to decide this?
I think we should look at both top notes and bottom notes. We should
only make the beam horizontal if they agree that the pattern is concave.
(I.e. form a pattern of the top notes. Form another pattern of the
bottom notes. If both patterns are concave then make the beam horizontal)
If we have something like { \stemUp c d e g f } Then we do not want a
horizontal beam.
Hmm .. I'm not sure. I've put the 'look at upper note' in Git since it
concords with the data we have, but the real problem is that we're
short of data. I've created a test file beam-concave-chord.ly, to add
future test cases, to document any decisions we make.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Collisions in tuplet beams across staffs
2008/2/22, Oscar van Eijk [EMAIL PROTECTED]: Any suggestions? Is this a bug? Yes; without delving deeper into this, I'd say it might be related to the recent changes wrt. page layout. Joe? -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Full bar rests in multi-voiced piano scores -- question and a suggestion
Hello:
A question about rests in multi-voiced piano scores: Most of the time
I am now using a four voiced layout for writing classical piano music.
The problem is with full bar rests. The rests can be moved on the
staff by using b'2\rest without problem, but when the rest is a full
bar long the syntax is R2 (in 2/4 time). Lilypond would normally
figure out that these rests should be merged. But since I'm using this
four voiced layout, I think lilypond doesn't figure out that these
rests should be merged into one. How do i get Lilypond to do this
automatically? I'm not sure how its done manually either.
rhOne = {
\clef treble
\time 2/4
\mark Sehr rasch
\key c \minor
\voiceOne
\relative c'
\override Staff.NoteCollision #'merge-differently-dotted = ##t
\times 4/5 { \stemNeutral g'16[ d' \chlh bf d g, ] } \chrh r8
| % bar 40
\repeat volta 2 {
r8
| % bar
40
R2
| % bar
41
r2
| % bar
42
r2
| % bar
43
b'4\rest b'8\rest
}
}
rhTwo = {
\clef treble
\relative c
\time 2/4
\key c \minor
\voiceTwo
s4*2
| % bar 39
s4*2
| % bar 40
R2
| % bar 41
s4*2
| % bar 42
}
lhTwo = {
\clef bass
\time 2/4
\key c \minor
\relative c
\voiceTwo
\override Staff.NoteCollision #'merge-differently-dotted = ##t
\partial 16 \skip 16
s4*2
| % bar 39
s4*2
| % bar 40
s4*2
| % bar 41
\repeat volta 2 { g16[ fs ]
|
g16[ af f g ] ef[ f d ef ]
| % bar 41
c16-[ d ef g ] c'[ d' ef' b ]
| % bar 42
c'-[ b c' e ] af-[ g af e ]
| % bar 43
f-[ e f d ] g[ f ef d ]
| % bar 44
}
}
\score{
\context PianoStaff
\set PianoStaff.instrumentName = \markup { \large \bold { { 7 }}}
\context Staff = rh {
\context Voice = rhupper { \rhOne }
\context Voice = rhlower { \rhTwo }
}
\context Staff = lh {
\context Voice = lhupper { \lhOne }
\context Voice = lhlower { \lhTwo }
}
\layout {
\context { \RemoveEmptyStaffContext }
\context {
\Score
\override NonMusicalPaperColumn % this
actually works well! (∂œ)
#'line-break-system-details = #'((alignment-offsets .
(0 -12)))
}
\version 2.11.28
}
\midi { }
}
While its not all four voiced, almost all the time there is a need for
at least one extra staff. So, simply having them there means that I
don't have to add voices on the fly as much. This also serves well
when voices switch from one hand to the other alternately. At first I
assumed it was overkill but at this point I think its the way to
Re: Full bar rests in multi-voiced piano scores -- question and a suggestion
See http://lists.gnu.org/archive/html/lilypond-user/2004-03/msg00198.html
/Mats
David Fedoruk wrote:
Hello:
A question about rests in multi-voiced piano scores: Most of the time
I am now using a four voiced layout for writing classical piano music.
The problem is with full bar rests. The rests can be moved on the
staff by using b'2\rest without problem, but when the rest is a full
bar long the syntax is R2 (in 2/4 time). Lilypond would normally
figure out that these rests should be merged. But since I'm using this
four voiced layout, I think lilypond doesn't figure out that these
rests should be merged into one. How do i get Lilypond to do this
automatically? I'm not sure how its done manually either.
rhOne = {
\clef treble
\time 2/4
\mark Sehr rasch
\key c \minor
\voiceOne
\relative c'
\override Staff.NoteCollision #'merge-differently-dotted = ##t
\times 4/5 { \stemNeutral g'16[ d' \chlh bf d g, ] } \chrh r8
| % bar 40
\repeat volta 2 {
r8
| % bar
40
R2
| % bar
41
r2
| % bar
42
r2
| % bar
43
b'4\rest b'8\rest
}
}
rhTwo = {
\clef treble
\relative c
\time 2/4
\key c \minor
\voiceTwo
s4*2
| % bar 39
s4*2
| % bar 40
R2
| % bar 41
s4*2
| % bar 42
}
lhTwo = {
\clef bass
\time 2/4
\key c \minor
\relative c
\voiceTwo
\override Staff.NoteCollision #'merge-differently-dotted = ##t
\partial 16 \skip 16
s4*2
| % bar 39
s4*2
| % bar 40
s4*2
| % bar 41
\repeat volta 2 { g16[ fs ]
|
g16[ af f g ] ef[ f d ef ]
| % bar 41
c16-[ d ef g ] c'[ d' ef' b ]
| % bar 42
c'-[ b c' e ] af-[ g af e ]
| % bar 43
f-[ e f d ] g[ f ef d ]
| % bar 44
}
}
\score{
\context PianoStaff
\set PianoStaff.instrumentName = \markup { \large \bold { { 7 }}}
\context Staff = rh {
\context Voice = rhupper { \rhOne }
\context Voice = rhlower { \rhTwo }
}
\context Staff = lh {
\context Voice = lhupper { \lhOne }
\context Voice = lhlower { \lhTwo }
}
\layout {
\context { \RemoveEmptyStaffContext }
\context {
\Score
\override NonMusicalPaperColumn % this
actually works well! (∂œ)
#'line-break-system-details = #'((alignment-offsets .
(0 -12)))
}
\version 2.11.28
}
\midi { }
}
While its not all four voiced, almost all the time there is a need for
at least one extra staff. So, simply having them there means that I
don't have to add voices on the fly as much. This also serves well
when voices switch from one hand to
