RE: staff section
Hi Till Might the tempo indication and metronome marks be better placed in the Rhythm section? If you think so let me know, as I'm working on Rhythms right now. Trevor D -Original Message- From: [EMAIL PROTECTED] [mailto:lilypond-user-bounces+t.daniels=treda.co.u [EMAIL PROTECTED] Behalf Of Till Rettig Sent: 24 February 2008 13:19 To: lilypond-user Mailinglist Subject: 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 ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Full bar rests in multi-voiced piano scores -- question and a suggestion
OK, I think that's partially what I am asking about. I would just
never have found that myself. I would have asked the wrong question.
I think that Zbynek and I might be asking the same question. Language
is the barrier for both of us.
Let me re-phrase my question to see if I understand this:
Normally a half or whole rest sits on the middle line. The exception
is where there are multiple voices on one staff. There is yet another
exception to the exception. In piano music, even though there may be
two voices which are resting, for clarity the two rests which would
sit one above the other, are merged into one rest as if there were
only one voice.
In my case, Lilypond is not acting in this manner. This action will
have to be invoke manually. It isn't an explicit placement, it is an
invocation of a usual case that Lilypond isn't acting on.
This is something akin to the\override Staff.NoteCollision
#'merge-differently-dotted = ##t, but instead of notes being merged in
what would be considered a collsion, I want to override the usual
placement of the rests and instead, place them as if there were only
one voice.
I almost found what I was looking for then lost it. In some way I need
to override the placement of the rests. I think it was about having a
grob sit x number above middle C.
Override rest collision and place rests from both voices in the same
place in the score.
I'm using the word grob for the first time and I hope I've used it
correctly. I think this is what the other post was about. But I have
now clarified what I want lilypond to do.
I want to get this right because I think this is something important
for the documentation. Understanding how to ask a question is primary
in getting an answer. This question seems to have been a hard one to
ask.
cheers,
david
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
RE: Full bar rests in multi-voiced piano scores -- question and asuggestion
Hi David
I've made a note to add something about this in the section of the NR that
deals with rests. I should get to that in the next few days.
Trevor D
-Original Message-
From: [EMAIL PROTECTED]
[mailto:lilypond-user-bounces+t.daniels=treda.co.u
[EMAIL PROTECTED] Behalf Of
David Fedoruk
Sent: 25 February 2008 09:37
To: Lilypond mailing list
Subject: Re: Full bar rests in multi-voiced piano
scores -- question and
asuggestion
OK, I think that's partially what I am asking
about. I would just
never have found that myself. I would have asked
the wrong question.
I think that Zbynek and I might be asking the
same question. Language
is the barrier for both of us.
Let me re-phrase my question to see if I understand this:
Normally a half or whole rest sits on the middle
line. The exception
is where there are multiple voices on one staff.
There is yet another
exception to the exception. In piano music, even
though there may be
two voices which are resting, for clarity the two
rests which would
sit one above the other, are merged into one rest
as if there were
only one voice.
In my case, Lilypond is not acting in this
manner. This action will
have to be invoke manually. It isn't an explicit
placement, it is an
invocation of a usual case that Lilypond isn't acting on.
This is something akin to the \override
Staff.NoteCollision
#'merge-differently-dotted = ##t, but instead of
notes being merged in
what would be considered a collsion, I want to
override the usual
placement of the rests and instead, place them as
if there were only
one voice.
I almost found what I was looking for then lost
it. In some way I need
to override the placement of the rests. I think
it was about having a
grob sit x number above middle C.
Override rest collision and place rests from both
voices in the same
place in the score.
I'm using the word grob for the first time and I
hope I've used it
correctly. I think this is what the other post
was about. But I have
now clarified what I want lilypond to do.
I want to get this right because I think this is
something important
for the documentation. Understanding how to ask a
question is primary
in getting an answer. This question seems to have
been a hard one to
ask.
cheers,
david
See
http://lists.gnu.org/archive/html/lilypond-user/20
04-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
Re: free LilyPond advertising
On 24 Feb 2008, at 21:46, Nicolas Sceaux wrote: 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 On Mac OS X, keyboard layouts can be created using Ukelele http:// scripts.sil.org/ukelele, though I don't know if the sound generation is possible. :-) Hans Åberg ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Full bar rests in multi-voiced piano scores -- question and a suggestion
Mats Bengtsson [EMAIL PROTECTED] writes:
So far, there's no automatic support in LilyPond to avoid collisions
between multi-measure rests and other objects. Their vertical
position is determined by the staff-position property, which by
default is set to zero. The \voiceOne macro sets staff-position to
+4 and \voiceTwo sets it to -4. So, to merge the rests from two
separate voices, just set the staff-position to the same value so
that they will be printed on top of each other. What I proposed in
the cited solution was to use \revert MultiMeasureRest
#'staff-position after \voiceOne and \voiceTwo, which reverts the
value of the property to the default 0. Of course, you probably
still want to keep the raised and lowered positions of full bar
rests in measures where the other voice has some music and
unfortunately, I don't know any nice automatic solution for that,
except for using the \partcombine function, which is known to have
several other limitations and bugs.
You could also do the following:
% either this:
mmOneVoice = { \override MultiMeasureRest #'staff-position = 2 }
% or this, which also works with collapsed rests:
mmOneVoice = { \override MultiMeasureRest #'staff-position =
#(lambda (grob)
(let ((elts (ly:grob-object grob 'elements)))
(if elts
(if (ly:grob-array? elts)
(let* ((mmrest (ly:grob-object
(ly:grob-array-ref elts 0)
'multi-measure-rest))
(mcount (ly:grob-property mmrest 'measure-count)))
(if (= measure-count 1) 2 0)))
;; it doesn't matter what I return otherwise, but still...
9)))
}
mmVoiceOne = { \override MultiMeasureRest #'staff-position = #4 }
mmVoiceTwo = { \override MultiMeasureRest #'staff-position = #-4 }
...and then you use \mmOneVoice when you know all the voices in the
staff will have the same rests, and \mmVoiceOne or \mmVoiceTwo when
they won't.
-- Arvid
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Full bar rests in multi-voiced piano scores -- question and a suggestion
So far, there's no automatic support in LilyPond to avoid collisions
between
multi-measure rests and other objects. Their vertical position is
determined by
the staff-position property, which by default is set to zero. The
\voiceOne macro
sets staff-position to +4 and \voiceTwo sets it to -4. So, to merge the
rests from
two separate voices, just set the staff-position to the same value so
that they
will be printed on top of each other. What I proposed in the cited
solution was to
use
\revert MultiMeasureRest #'staff-position
after \voiceOne and \voiceTwo, which reverts the value of the property
to the
default 0. Of course, you probably still want to keep the raised and
lowered
positions of full bar rests in measures where the other voice has some music
and unfortunately, I don't know any nice automatic solution for that, except
for using the \partcombine function, which is known to have several other
limitations and bugs.
For ordinary rests and notes, the collision handling in LilyPond is much
more
advanced meaning that it works much better by default, but that it also
might
be more difficult to understand how to tweak it in the cases where the
default
doesn't give a satisfactory result.
/Mats
David Fedoruk wrote:
OK, I think that's partially what I am asking about. I would just
never have found that myself. I would have asked the wrong question.
I think that Zbynek and I might be asking the same question. Language
is the barrier for both of us.
Let me re-phrase my question to see if I understand this:
Normally a half or whole rest sits on the middle line. The exception
is where there are multiple voices on one staff. There is yet another
exception to the exception. In piano music, even though there may be
two voices which are resting, for clarity the two rests which would
sit one above the other, are merged into one rest as if there were
only one voice.
In my case, Lilypond is not acting in this manner. This action will
have to be invoke manually. It isn't an explicit placement, it is an
invocation of a usual case that Lilypond isn't acting on.
This is something akin to the\override Staff.NoteCollision
#'merge-differently-dotted = ##t, but instead of notes being merged in
what would be considered a collsion, I want to override the usual
placement of the rests and instead, place them as if there were only
one voice.
I almost found what I was looking for then lost it. In some way I need
to override the placement of the rests. I think it was about having a
grob sit x number above middle C.
Override rest collision and place rests from both voices in the same
place in the score.
I'm using the word grob for the first time and I hope I've used it
correctly. I think this is what the other post was about. But I have
now clarified what I want lilypond to do.
I want to get this right because I think this is something important
for the documentation. Understanding how to ask a question is primary
in getting an answer. This question seems to have been a hard one to
ask.
cheers,
david
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
Re: free LilyPond advertising
2008/2/25, Hans Aberg [EMAIL PROTECTED]: On 24 Feb 2008, at 21:46, Nicolas Sceaux wrote: I'm using a key map described here: http://nicolas.sceaux.free.fr/index.php/2006/07/01/8 On Mac OS X, keyboard layouts can be created using Ukelele http:// scripts.sil.org/ukelele, though I don't know if the sound generation is possible. :-) As far as I can see, what Nicolas describes is definitely *not* possible with a OS keyboard layout; his interesting solution uses processing features of Emacs. (My homebrew OSX keymap is interesting, too, but doesn't speak LilyPond...) -- Grüßlinge vom Südsee! fiëé visuëlle Henning Hraban Ramm ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
On 25 Feb 2008, at 13:23, Henning Hraban Ramm wrote: On Mac OS X, keyboard layouts can be created using Ukelele http:// scripts.sil.org/ukelele, though I don't know if the sound generation is possible. :-) As far as I can see, what Nicolas describes is definitely *not* possible with a OS keyboard layout; his interesting solution uses processing features of Emacs. (My homebrew OSX keymap is interesting, too, but doesn't speak LilyPond...) Producing strings might be possible. More advanced thing probably belong to the editor, not the keyboard map. Some like to use such with TeX, so perhaps TeXShop might do it. Otherwise, there is an AquaEmacs for the Aqua GUI, and an emacs-21 in Fink for X11, though I am not sure they handle UTF-8 well. Hans Åberg ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
Le samedi 23 février 2008 à 21:39 -0300, Han-Wen Nienhuys a écrit : 2008/2/23, Andrew Hawryluk [EMAIL PROTECTED]: http://www.musicbyandrew.ca/finale-lilypond-1.html Excellent analysis! I like these articles too! Rachmaninoff's prelude benchmarking is done with the same quality as in the essay on lilypond.org. Can someone (one of you documentation guys?) link to this from the website? as a news entry on the front-page and from the essay? Done! I also added a link in About - Publications. Cheers, John ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
Le dimanche 24 février 2008 à 20:31 -0300, Han-Wen Nienhuys a écrit : 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: [hmmm, the #filename links are broken; we get the full path name now. Is this something recent? John?] This has been so since a 2.11.x release (I don't remember), and I don't get this with compiling myself, this happens only with GUB. Since I don't build with GUB (yet), I don't know the cause of this problem; I've tried something in lys-to-tely.py, I'm not sure at all it will work. Cheers, John ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Concave beams (was: free LilyPond advertising)
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.
-Rune
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: page breaks related to header size
On Mon, 2008-01-14 at 01:59 -0800, Risto Vääräniemi wrote: Dear All, Risto Vääräniemi wrote: Has this issue taken some steps backwards? I compiled both of Paul's examples in this thread using versions 2.11.32 and 2.11.37. The first one with headers takes two pages on both versions. The second one without a header takes two pages on 2.11.32 and *three* pages on 2.11.37. Just a reminder of the discussion. :-) Sorry, I missed this email. Is this still an issue? If so, could you send the example that fails in an email? I tried 2 examples given by Paul in this thread and they both took up 2 pages with latest git. But maybe I didn't find the right example... Joe ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Collisions in tuplet beams across staffs
On Sun, 2008-02-24 at 22:12 -0300, Han-Wen Nienhuys wrote: 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? Yes, it was caused by my previous messing around with cross-staff tuplet brackets. Fixed now in git. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: NR 1.1 comment
On Sun, 24 Feb 2008 15:48:15 +0200
Till Rettig [EMAIL PROTECTED] wrote:
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?
Delete them all. That info shouldn't be in 1.6; it should go in
1.6.x.y. I would also delete the info about @code{staff symbol}; again,
that isn't appropriate at the toplevel node of that section.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
where is the local documentation?
i don't know where i must seek to find the local documentation... ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
Le 25 févr. 08 à 14:11, Hans Aberg a écrit : On 25 Feb 2008, at 13:23, Henning Hraban Ramm wrote: On Mac OS X, keyboard layouts can be created using Ukelele http:// scripts.sil.org/ukelele, though I don't know if the sound generation is possible. :-) As far as I can see, what Nicolas describes is definitely *not* possible with a OS keyboard layout; his interesting solution uses processing features of Emacs. (My homebrew OSX keymap is interesting, too, but doesn't speak LilyPond...) Producing strings might be possible. More advanced thing probably belong to the editor, not the keyboard map. Some like to use such with TeX, so perhaps TeXShop might do it. Otherwise, there is an AquaEmacs for the Aqua GUI, and an emacs-21 in Fink for X11, though I am not sure they handle UTF-8 well. It's not just about producing strings. It's also about parsing the previous content (to find out, say, the current duration, or octave), and remembering previous typings (accidentals for instance). It's also about modifying the previous content (change an alteration, a duration, an octave), or even a whole region of text (transposition for instance). All these things belong to the editor, as does the assoiated key map. But this is quite far from the original topic. nicolas ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
Here's the .ly files I used.
Waouh thanks !
Thanks for your newspaper !
Good good advertisement !
To prove that LilyPond is formidable, beam can be adapted easily with :
\once \override Beam #'positions = #'(-y1 . -y2)
%%---
RightHandTwo = \relative c'' {
bes, ees4 r \change Staff = LH \stemUp bes16 ees f g bes \change
Staff = RH \stemDown ees f bes
r8\pp bes,16(\( c) ees f fis aes g ees8 des16 c ces bes ees\)
r8 ees,16(\( f) ees' bes c f ees c8 bes16 aes bes c g\)
r8 c,16(\( e)
\once \override Beam #'positions = #'(-4.7 . -3.7) {f g aes bes}
\once \override Beam #'positions = #'(-3.7 . -4.7) {c aes8 g16}
aes f bes bes,\)
s8
}
%%
--
Martial
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: free LilyPond advertising
On 25 Feb 2008, at 21:34, Nicolas Sceaux wrote: It's not just about producing strings. It's also about parsing the previous content (to find out, say, the current duration, or octave), and remembering previous typings (accidentals for instance). It's also about modifying the previous content (change an alteration, a duration, an octave), or even a whole region of text (transposition for instance). All these things belong to the editor, as does the assoiated key map. Have you thought about it in this terms: What syntax in LilyPond would minimize this Emacs programming? Hans Åberg ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Full bar rests in multi-voiced piano scores -- question and a suggestion
AH! ok the light is begining to shine on this for me! This makes perfect sense. So far, there's no automatic support in LilyPond to avoid collisions between multi-measure rests and other objects. Their vertical position is determined by the staff-position property, which by default is set to zero. The \voiceOne macro sets staff-position to +4 and \voiceTwo sets it to -4. So, to merge the rests from two separate voices, just set the staff-position to the same value so that they will be printed on top of each other. What I proposed in the cited solution was to use \revert MultiMeasureRest #'staff-position after \voiceOne and \voiceTwo, which reverts the value of the property to the default 0. Of course, you probably still want to keep the raised and lowered positions of full bar rests in measures where the other voice has some music and unfortunately, I don't know any nice automatic solution for that, except for using the \partcombine function, which is known to have several other limitations and bugs. Full bar rests are the biggest issue. It looks like this is the answer I need. For ordinary rests and notes, the collision handling in LilyPond is much more advanced meaning that it works much better by default, but that it also might be more difficult to understand how to tweak it in the cases where the default doesn't give a satisfactory result. The individual tweaks always need specific attention. That is just the way music is. Exceptional cases everywhere and then composers invent new ones! That said, it looks like these tweaks will not be that difficult to work through. Arvid's solutions in the next post looks interesting and I'll give it a try and see what happens. Thanks for the help! And since this is scheduled to be made part of the documentation I'm happy :) -- David Fedoruk B.Mus. UBC,1986 Certificate in Internet Systems Administration, UBC, 2003 http://recordjackethistorian.wordpress.com Music is enough for one's life time, but one life time is not enough for music Sergei Rachmaninov ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
GDP: \articulation and -\articulation
These are both valid:
{
c'2-\accent
c'2\accent
}
Should we keep the - version in the docs at all? Does it really add
anything (especially since most people use the plain \ version) ?
It might be good as an introduction to ^ and _, but OTOH we
can do ^ and _ with items that don't have any -, such as
ties ~.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
GDP: linking to ^_ section
Does this formula work for the ^_ thing? If we agree on this
sentence, we'll use this throughout the docs:
Dynamics (or whatever) may be manually placed above or below the
staff, for details see @ref{Controlling direction and placement}.
Implicit in this is my tentative decision to go with Controlling
direction and placement.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: \articulation and -\articulation
On Tue, 26 Feb 2008 00:39:21 -0500
Bryan Stanbridge [EMAIL PROTECTED] wrote:
Graham Percival wrote:
Should we keep the - version in the docs at all? Does it really add
anything (especially since most people use the plain \ version) ?
We might want to keep the -\ version, because it can be used in
sequences of modifiers after notes. Sometimes Lily doesn't like it
when you want to do something like
{ c'\mp\fermata\accent\markup {\bold forcefully} }
Interesting! However, as this example indicates, it's not
specific to articulations. We'll add info to LM 3 and
NR 3 about this.
Since there's nothing specific about articulations here, we'll
remove it from NR 1.3.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: \articulation and -\articulation
On Mon, Feb 25, 2008 at 9:50 PM, Graham Percival [EMAIL PROTECTED] wrote: Interesting! However, as this example indicates, it's not specific to articulations. We'll add info to LM 3 and NR 3 about this. Since there's nothing specific about articulations here, we'll remove it from NR 1.3. Just to be clear about this: -- In NR 1.3, we will only be explaining the \ syntax for articulations and ornamentations. -- The - syntax will only be explained for the `shorthands' Is this correct? Thanks, Patrick ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: staff section
On Sun, 24 Feb 2008 15:19:04 +0200 Till Rettig [EMAIL PROTECTED] wrote: 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. That's what it was like in the old docs, but we've moved away from situation-specific divisions. As you note, we use such notation for non-orchestral situations anyway. I'm open to renaming the whole section, though. 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) Nope. That's covered in LM 3. If somebody doesn't read that, we officially don't care about them. 1.6.1.2 Grouping staves (about system start delimiters I'm totally fine with renaming this section, but IMO it should remain as 1.6.1.1. I'd also be tempted to reverse the order of groupings in that subsection -- ie start with no brace, then go through Piano, Choir, StaffGroups, and finally GrandStaff. (maybe: 1.6.1.3: Deeper nesting of staff groups) Sorry, I don't understand this comment. -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 Well, the Staff section was never intended to be only single-staff stuff -- after all, it contains GrandStaff. That said, I wouldn't mind if you wanted to split 1.6.2 into single-staff and multiple staves, as long as no section only had a single subsection. 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? Rehearsal marks are in 1.2.5.4, since that's close to bar numbers. I think it would be stretching it to put tempo in there as well. Staff certainly doesn't seem ideal, but I'm not certain where else we could put it. -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. That kind of thing would be a snippet. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: \articulation and -\articulation
On Mon, 25 Feb 2008 22:08:09 -0800 Patrick McCarty [EMAIL PROTECTED] wrote: On Mon, Feb 25, 2008 at 9:50 PM, Graham Percival [EMAIL PROTECTED] wrote: Interesting! However, as this example indicates, it's not specific to articulations. We'll add info to LM 3 and NR 3 about this. Since there's nothing specific about articulations here, we'll remove it from NR 1.3. Just to be clear about this: -- In NR 1.3, we will only be explaining the \ syntax for articulations and ornamentations. -- The - syntax will only be explained for the `shorthands' Is this correct? To be clear about this... probably. Almost certainly? At the moment, I'm envisioning a sentence-link to the When to add - subsection in NR 3, just like we have a sentence-link to Controlling direction and placement. But I only learned about the - issue an hour or two ago. I don't want to say definitely until I find out a bit more about this. For now, only explain the \ syntax for articulations (and add that example). Dump a FIXME: comment for the shorthands and move on to other material in your section. I estimate that I won't have any kind of final decision until the weekend. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
GDP glossary question: complex meters
BACKGROUND We now have a number of different terms to refer to several closely related concepts: * polymeter * polymetric time signature * double time signature * compound time signature ( Elsewhere -- just to add them to the mix -- I've seen: * mixed meter / mixed time signatures * additive time signatures * alternating time signatures ) Last month, we (meaning y'all) had a discussion about the one true polymeter: Valentin's definition (group A), where different meters are used _simultaneously_ on different staves; and Ralph's definition (group B), with regular alternation between different meters. [I'm not interested in resolving that discussion, just standardizing the terminology we use.] LilyPond handles group A quite easily, by simply moving the Timing_translator to the Staff context. Group B, due to its polymorphous nature (and resemblance to Hydra), is handled unevenly. * LilyPond deals with mixed meters (where meter alternates without a specific pattern) pretty well * Double -- aka alternating -- time signatures are not supported explicitly, but they can be faked [NR 1.2.3.4]. * Additive meters are covered in a snippet ... named compound-time-signatures.ly (that's where I got 'compound time signature) (I'm not sure if one can extend this last one in LilyPond to more complex examples, like when the numerator is an additive expression, and the denominator is a single digit, e.g. (3+2+3)/8.) SO, MY QUESTION How can we normalize the terminology? Here are my thoughts on the matter, trying to distill this into a controlled lexicon -- * polymeter -- the most generic term * sequential polymeter -- Ralph's definition * regular * irregular * simultaneous polymeter -- Valentin's definition * regular and irregular (theoretically) And here's what happens to the list of terms above: * polymetric time signature Deleted: although it implies sequential polymeter, it has too many possible interpretations to be useful. * double time signature * compound time signature * additive time signatures * alternating time signatures Become See also _sequential polymeter, regular_ * mixed meter / mixed time signatures Becomes See also sequential polymeter, irregular_ So ... what are your thoughts? Thanks! Kurt ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Collisions in tuplet beams across staffs
Great, thanks! On Mon, 2008-02-25 at 15:49 +0200, Joe Neeman wrote: On Sun, 2008-02-24 at 22:12 -0300, Han-Wen Nienhuys wrote: 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? Yes, it was caused by my previous messing around with cross-staff tuplet brackets. Fixed now in git. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
