Re: Backwards compatibility: \compressMusic, \scaleDurations, WHY WHY WHY
On Tue, 5 Aug 2008 17:03:58 -0700 Patrick McCarty [EMAIL PROTECTED] wrote: You do raise a lot of interesting points though. I'm not the best person to address these concerns though. No he doesn't. At least, he hasn't raised any new points, nor anything that we haven't considered. 2.12 should be the last time there's major syntax changes. I've done everything possible to include more people in lilypond development and discussing syntax changes. You'd have to be hiding under a rock to not notice everything GDP has been doing, both in terms of docs *and* in terms of improving lilypond usability. I have absolutely no sympathy for people who complain after the fact when they've done nothing to get involved previously. If you want stability, use 2.10. If you can handle unstability, use 2.11. But don't complain when the unstable branch is MAOING UNSTABLE. Updating your syntax once a year when a new stable version comes out is no big deal. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Backwards compatibility: \compressMusic, \scaleDurations, WHYWHY WHY
Graham Percival wrote Wednesday, August 06, 2008 7:58 AM On Tue, 5 Aug 2008 17:03:58 -0700 Patrick McCarty [EMAIL PROTECTED] wrote: You do raise a lot of interesting points though. I'm not the best person to address these concerns though. No he doesn't. At least, he hasn't raised any new points, nor anything that we haven't considered. 2.12 should be the last time there's major syntax changes. If you want stability, use 2.10. If you can handle unstability, use 2.11. Furtherful, all the stable releases remain available indefinitely. People engaged on major projects do not need to upgrade immediately after a new stable release is announced. They can phase in the new release as and when it is convenient to them and after all necessary coordination and planning has been done. Cheers, - Graham Trevor ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: NR 1.3 Expressive marks, second draft
Hi,
Unfortunately, I haven't had the time to be very active in the review of
the GDP drafts, but I happened
to look into New dynamic marks of 1.3.1 and have some comments:
- The markup command for \roundf is unnecessarily complicated and the
result looks bad. The \center-align markup command is intended to
produce a column of (internally) center aligned markups. If you only
have a single line markup, then you should use \hcenter instead. Also,
the spacing between the parenthesis and the f is probably unintended.
Finally, there are some redundant braces (that you may want to keep for
readability). I would propose to instead use
roundf = \markup { \hcenter \concat { \bold { \italic ( }
\dynamic f \bold { \italic ) } } }
or (without the redundant braces)
roundf = \markup { \hcenter \concat { \bold \italic (
\dynamic f \bold \italic ) } }
- The main reason to use make-dynamic-script instead of a pure \markup
is not to get the horizontal alignment correct with respect to the note
head, but to get correct vertical positioning when you have both an
absolute dynamic and a hairpin starting/ending on the same note, for
example. Compare the following two examples to see the difference:
roundf = \markup { \hcenter \concat { \normal-text \bold \italic (
\dynamic f \normal-text \bold \italic ) } }
boxf = \markup { \bracket { \dynamic f } }
roundfdyn = #(make-dynamic-script roundf)
boxfdyn = #(make-dynamic-script boxf)
\relative c' {
c4_\roundf \ d e f
g,1_\boxf \!
c4_\roundfdyn \ d e f
g,1_\boxf \!
}
- As illustrated in the example above, it's not absolutely necessary to
learn the Scheme syntax of the markup commands to use
make-dynamic-script. A simpler solution is to first define a normal
markup, and then use that as the argument to make-dynamic-script.
/Mats
Patrick McCarty wrote:
I would like to announce the second draft of NR 1.3 Expressive marks.
Please proofread this section, and let me know if you find any
omissions or errors. Suggestions for additional snippets to include
(or replace) are greatly appreciated as well.
http://web.uvic.ca/~gperciva/
Thanks,
Patrick
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: markup dynamics wrong size
The best solution for you is probably to use #(make-dynamic-script ... )
to define all your dynamic commands, see subsection New dynamics.
Then, they will behave exactly as all the other dynamics.
I haven't investigated how much tweaks would be involved to make
ordinary \markup commands work better in the centered dynamics context,
but you will certainly always suffer from the same lack of vertical
alignment that I just pointed out in an email with subject line Re:
GDP: NR 1.3 Expressive marks, second draft on the mailing list. There,
you can also find hints on how to use #(make-dynamic-script ) without
having to learn Scheme syntax for markup commands.
/Mats
Eric Flesher wrote:
Wondering if anyone has experienced the following problem:
When creating new centered dynamics in a piano staff in ver. 2.11.55
(and several earlier versions) using \markup, three things happen:
1. the markup text created is significantly larger than the normal
dynamic size
2. the text does not align with other dynamic markings
3. the presence of the markup text forces additional space between the
staves
The dynamic marking concerned is contained in a variable thus:
pocoF = \markup { \italic poco \dynamic f }
and is deployed locally as follows:
\times 4/5 { s16 s\mp s s-\pocoF s\ } \times 4/5 { s8\! s\mp s16 } s4
(I would include more code, but the file is extremely long.)
Any idea what might be wrong here, and how this could be fixed?
Thanks,
EF
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lyrics following split voices
Francisco
The LM's role (at least in my view) is to introduce concepts and
explanations in a logical order. It makes no attempt to be either rigorous
or comprehensive, neither should it. The NR's role, in contrast, is to
present complete and accurate facts, sweetened with a smattering of
examples.
So, for the example in question, the NR should certainly state categorically
what the voice names are in the various constructs, and examples showing the
differences would be fine. But I don't think there is any need to put
lengthy explanations in the NR - it's a reference document - they really
need to go in the LM.
So maybe we need an explanation of using voice naming in this way somewhere
in the LM. Any suggestions? And the NR should certainly list all the
context names that are assigned by default somewhere. Perhaps I'll work
that into the section on Contexts. What do you think?
Trevor
- Original Message -
From: Francisco Vila [EMAIL PROTECTED]
To: Mats Bengtsson [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: Paul Scott [EMAIL PROTECTED]; LilyPond User
lilypond-user@gnu.org
Sent: Wednesday, August 06, 2008 12:47 AM
Subject: Re: lyrics following split voices
2008/8/5 Mats Bengtsson [EMAIL PROTECTED]:
I'm surprised that nobody answered exactly this question. If you name
your
main voice 1, then the upper voice of the {...} \\ {...} construct
will stay the same Voice context as the single voice.
That's true, it is explained in LM 3.2.1 I'm hearing Voices
...tangentially. One has to deduct this when he reads 'The Voice
contexts bear the names 1, 2, etc.'
I propose: to add some lines explaining this very case: how to make
the single voice to keep being the same, although a second voice
arrives. LM 3.2.2 Explicitly instantiating voices does explain that
(the red diamonds example), but does not mention the trick of calling
the voice 1 ! It rather uses a simple .. \new Voice construct.
Note, though that the
{...} \\ {...} construct will add property settings equivalent to
the
\voiceOne command, so you have to explicitly insert a \oneVoice
afterwards
to revert to the default settings:
Again, this is only tangentially explained in LM 3.2.2 because the
\oneVoice command is used with no previous \\construct !
I could not have figured this, without your help. Thanks!
Now I suppose I have to take the compromise to write this down in NR
Simultaneous Notes.
--
Francisco Vila. Badajoz (Spain)
http://www.paconet.org
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: color notehead according to absolute pitch
kenny, how about #(define (color-notehead grob) (pitch-to-color (ly:event-property (ly:grob-property grob 'cause) 'pitch))) #(define (pitch-to-color pitch) (cond ((and (eqv? (ly:pitch-octave pitch) 0) (eqv? (ly:pitch-alteration pitch) 0) (eqv? (ly:pitch-notename pitch) 6)) (x11-color 'red)) ((and (eqv? (ly:pitch-octave pitch) 0) (eqv? (ly:pitch-alteration pitch) -1/2) (eqv? (ly:pitch-notename pitch) 6)) (x11-color 'green)) ((and (eqv? (ly:pitch-octave pitch) 1) (eqv? (ly:pitch-alteration pitch) 0) (eqv? (ly:pitch-notename pitch) 6)) (x11-color 'blue)) ((and (eqv? (ly:pitch-octave pitch) 0) (eqv? (ly:pitch-alteration pitch) 0) (eqv? (ly:pitch-notename pitch) 5)) (x11-color 'orange)) ((and (eqv? (ly:pitch-octave pitch) 0) (eqv? (ly:pitch-alteration pitch) 0) (eqv? (ly:pitch-notename pitch) 4)) (x11-color 'orange)) ) ) and any kind schemers reading how would you refactor this to use lists, along the lines of (0 0 6 'red) (0 -1/2 6 'green) (1 0 6 'blue) ((0 0 5 ) (0 0 4) 'orange) thanks d On 5 Aug 2008, at 23:06, Damian leGassick wrote: thanks steven cond - yes, i was trying to use case kenny - can you figure it out from here? if not i'll try tomorrow morning london time d On 5 Aug 2008, at 21:10, Steven Weber wrote: Use the (cond) expression. Here's a simplified version of your pitch-to-color function that colors all c's red and all f's blue: #(define (pitch-to-color pitch) (cond ((eqv? (ly:pitch-notename pitch) 0) (x11-color 'red)) ((eqv? (ly:pitch-notename pitch) 3) (x11-color 'blue)) ) ) --Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Damian leGassick Sent: Tuesday, August 05, 2008 5:53 AM To: lilypond-user@gnu.org Subject: Re: color notehead according to absolute pitch On 5 Aug 2008, at 05:39, Jay Anderson wrote: Kenny Stephens kfstephensii at yahoo.com writes: Our church has a handbell group whose members are not all musically literate. To keep themselves from having to learn to read music, they mark their notes using differently colored highlighters. Is there a means by which I can color the notes based on its absolute pitch --- not its pitch class? Some of the music spans three octaves. The requirements are: 1) b4 and b5 are different colors. 2) b\flat4 and b4 are different colors. 3) different pitches can be assigned to the same color (some ringers play two or more handbells). I've only been playing around with Lilypond for about a week (though I've logged numerous hours) for typesetting organ music; but this is different. I did find an example using Scheme and 'staff-position,' but this fails condition 1. Ideas, suggestions or solutions would be appreciated. Using the same idea as the example you mentioned (http://lilypond.org/doc/v2.11/Documentation/user/lilypond-learning/Advanced -tweaks-with-Scheme ) you can base the color on the pitch: #(define (color-notehead grob) (pitch-to-color (ly:event-property (ly:grob-property grob 'cause) 'pitch))) Now you'd just have to figure out how to implement the pitch-to- color function. For example this colors all the flat notes blue: #(define (pitch-to-color pitch) (if (eqv? (ly:pitch-alteration pitch) -1/2) (x11-color 'blue))) You might want to get a little fancy to make sure enharmonic spellings of the same pitch are the same color, but for most cases that shouldn't be a problem. -Jay ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user I can get as far as: #(define (color-notehead grob) (pitch-to-color (ly:event-property (ly:grob-property grob 'cause) 'pitch))) #(define (pitch-to-color pitch) (if (and (eqv? (ly:pitch-octave pitch) 0) (eqv? (ly:pitch-alteration pitch) -1/2) (eqv? (ly:pitch-notename pitch) 6)) (x11-color 'blue))) which sets only the b-flat above middle c to be blue. can't work out how to simultaneously colour the b-natural, say, red - i'd love to know too Damian ___ 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 ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Still confused about context vs. new
I personally have *never* needed to use \new. \context implicitly instantiates a new context if the one named doesn't yet exist, so \new is redundant, *except* where you want multiple distinct contexts with the same name, or you're using unnamed contexts (which, internally, is the same thing) Distinct objects should (as a general rule) be named distinctly, so that leaves the only place to use \new: when you want unnamed contexts. Yes, it's certainly possible to use \new vs. \context in this way. However, I think that it's conceptually easier and more pedagogical to use the following strategy: - Use \new whenever you want a new context, be it named or anonymous. - Use \context only when referring to an already existing context . As you have pointed out, this is not enforced by LilyPond, but I still think it's a good habit and good way to teach about LilyPond. However, there are some fine details about the use of named contexts that I don't understand fully. I'll start a separate email thread about that in a moment. /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Backwards compatibility: \compressMusic, \scaleDurations, WHY WHY WHY
On Wed, Aug 6, 2008 at 3:58 AM, Graham Percival [EMAIL PROTECTED] wrote: On Tue, 5 Aug 2008 17:03:58 -0700 Patrick McCarty [EMAIL PROTECTED] wrote: You do raise a lot of interesting points though. I'm not the best person to address these concerns though. No he doesn't. At least, he hasn't raised any new points, nor anything that we haven't considered. 2.12 should be the last time there's major syntax changes. I've Heh, There are still a couple of very weak and unintuitive areas in lily (part combining, setting lyrics to melodies), that -if ever addressed- might require syntax changes. -- 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
Expert question on named contexts
Since I have only used LilyPond for 11 years, I have some remaining
questions on how it works.
Can anybody tell me exactly what happens with the context names in the
following example.
\relative c'
\new Staff \new Voice = myvoice { c d e f }
\new Staff \context Voice = myvoice { g f e d }
Clearly, I get two Voice contexts, even though they are given the same
name.
It's also clear that the input is ambigous, since it both states that
the two voices
should be treated as a single Voice context, but also that they should
be part of
separate Staff contexts (which means that they cannot be the same Voice
context).
Apparently, LilyPond lets the latter requirement override the former one.
However, what happens to the context names? Is the Voice context in the
lower
stave given some random unknown name or do both have the same name but are
kept separate because of the context hierarchy. In the latter case, is
it even possible
to refer to the Voice context of the lower stave using the name
myvoice, under
some circumstance?
/Mats
--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: NR 1.5 Simultaneous, second draft
Karl Hammar wrote:
That is strange, why do you need to do the \new DrumVoice-lines in
drummode? Example of 2.5.1.3:
\new DrumStaff
\new DrumVoice = 1 { s1 *2 }
\new DrumVoice = 2 { s1 *2 }
\drummode {
bd4 sn4 bd4 sn4
{ \repeat unfold 16 hh16 }
\\
{ bd4 sn4 bd4 sn4 }
}
Since the {...} \\ {} construct will create new Voice contexts
by default, i.e. it doesn't
understand automatically that it's within a DrumStaff and therefore
should create DrumVoice
contexts instead. However, if there already are contexts available named
1 and 2, then they
will be used by the {...} \\ {} construct.
/Mats
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lyrics following split voices
Trevor Daniels wrote:
So, for the example in question, the NR should certainly state
categorically what the voice names are in the various constructs, and
examples showing the differences would be fine. But I don't think
there is any need to put lengthy explanations in the NR - it's a
reference document - they really need to go in the LM.
So maybe we need an explanation of using voice naming in this way
somewhere in the LM. Any suggestions? And the NR should certainly
list all the context names that are assigned by default somewhere.
Perhaps I'll work that into the section on Contexts. What do you think?
Note that the use of the trick
\new Voice = 1 { ... {...} \\ {...} ... }
only works if you have a single Staff (or at most one Staff with
polyphony), since otherwise
you would have several \new Voice = 1 in the same score, which doesn't
work.
Therefore, it's fairly esoteric and perhaps something that shouldn't be
taught in the LM.
/Mats
Trevor
- Original Message - From: Francisco Vila
[EMAIL PROTECTED]
To: Mats Bengtsson [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: Paul Scott [EMAIL PROTECTED]; LilyPond User
lilypond-user@gnu.org
Sent: Wednesday, August 06, 2008 12:47 AM
Subject: Re: lyrics following split voices
2008/8/5 Mats Bengtsson [EMAIL PROTECTED]:
I'm surprised that nobody answered exactly this question. If you
name your
main voice 1, then the upper voice of the {...} \\ {...}
construct
will stay the same Voice context as the single voice.
That's true, it is explained in LM 3.2.1 I'm hearing Voices
...tangentially. One has to deduct this when he reads 'The Voice
contexts bear the names 1, 2, etc.'
I propose: to add some lines explaining this very case: how to make
the single voice to keep being the same, although a second voice
arrives. LM 3.2.2 Explicitly instantiating voices does explain that
(the red diamonds example), but does not mention the trick of calling
the voice 1 ! It rather uses a simple .. \new Voice construct.
Note, though that the
{...} \\ {...} construct will add property settings equivalent
to the
\voiceOne command, so you have to explicitly insert a \oneVoice
afterwards
to revert to the default settings:
Again, this is only tangentially explained in LM 3.2.2 because the
\oneVoice command is used with no previous \\construct !
I could not have figured this, without your help. Thanks!
Now I suppose I have to take the compromise to write this down in NR
Simultaneous Notes.
--
Francisco Vila. Badajoz (Spain)
http://www.paconet.org
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
automatic note splitting and ties
Dear lilypond-users,
I have a problem with ties in connection with automatic note splitting. I
don't understand why the ties in the below quoted example look so strange:
Is it a bug?
\score {
\new Staff {
\new Voice \with {
\remove Note_heads_engraver
\consists Completion_heads_engraver
}
r2
r2 e c' 4 f des' 8 des' ees' 4 - c' e'
r8 e c' 4 f des' 8 des' ees' 4 - c' e' b f' r8 r4
r2 e c' 4 f des' 8 des' ees' 8~ - des' ees' 8 c' e'
} %staff ende
}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
strange tempo
I need to create a tempo marking that would look like this: \tempo 4 ~ 4. = 53 ...if \tempo worked like that. I was trying to cobble something together by creating a markup containing music. My plan was to print a quarter tied to a dotted quarter, move a text script using offset and remove the engravers for staff lines, clef, time sig, etc. I ran into a bug that makes this impossible; combining ties or dots with \remove Staff_symbol_engraver leads to a segmentation fault. Help? -David ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lyrics following split voices
Mats, you wrote, Wednesday, August 06, 2008 1:26 PM
Trevor Daniels wrote:
So, for the example in question, the NR should certainly state
categorically what the voice names are in the various constructs, and
examples showing the differences would be fine. But I don't think
there is any need to put lengthy explanations in the NR - it's a
reference document - they really need to go in the LM.
So maybe we need an explanation of using voice naming in this way
somewhere in the LM. Any suggestions? And the NR should certainly
list all the context names that are assigned by default somewhere.
Perhaps I'll work that into the section on Contexts. What do you think?
Note that the use of the trick
\new Voice = 1 { ... {...} \\ {...} ... }
only works if you have a single Staff (or at most one Staff with
polyphony), since otherwise
you would have several \new Voice = 1 in the same score, which doesn't
work.
Therefore, it's fairly esoteric and perhaps something that shouldn't be
taught in the LM.
Wise words. Maybe we should stick to describing the
situation regarding Voice names somewhere in the
Contexts explained section, way down in NR 5.1.1,
which I'll write as soon as I understand them properly
(although that hasn't stopped me on some earlier
occasions;) That way beginners will be better protected
from wrong impressions.
/Mats
Trevor
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: strange tempo
Then don't remove the engraver, just set the stencil to #f or the grob transparent. David Bobroff wrote: I need to create a tempo marking that would look like this: \tempo 4 ~ 4. = 53 ...if \tempo worked like that. I was trying to cobble something together by creating a markup containing music. My plan was to print a quarter tied to a dotted quarter, move a text script using offset and remove the engravers for staff lines, clef, time sig, etc. I ran into a bug that makes this impossible; combining ties or dots with \remove Staff_symbol_engraver leads to a segmentation fault. Help? -David ___ 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: strange tempo
Thanks! That seems to work. -David Bertalan Fodor (LilyPondTool) wrote: Then don't remove the engraver, just set the stencil to #f or the grob transparent. David Bobroff wrote: I need to create a tempo marking that would look like this: \tempo 4 ~ 4. = 53 ...if \tempo worked like that. I was trying to cobble something together by creating a markup containing music. My plan was to print a quarter tied to a dotted quarter, move a text script using offset and remove the engravers for staff lines, clef, time sig, etc. I ran into a bug that makes this impossible; combining ties or dots with \remove Staff_symbol_engraver leads to a segmentation fault. Help? -David ___ 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: strange tempo
Why not follow the approach used in http://lsr.dsi.unimi.it/LSR/Item?id=204 ? /Mats David Bobroff wrote: I need to create a tempo marking that would look like this: \tempo 4 ~ 4. = 53 ...if \tempo worked like that. I was trying to cobble something together by creating a markup containing music. My plan was to print a quarter tied to a dotted quarter, move a text script using offset and remove the engravers for staff lines, clef, time sig, etc. I ran into a bug that makes this impossible; combining ties or dots with \remove Staff_symbol_engraver leads to a segmentation fault. Help? -David ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- = Mats Bengtsson Signal Processing School of Electrical Engineering Royal Institute of Technology (KTH) SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: automatic note splitting and ties
Which LilyPond version are you using?
Exactly what is it that you think looks strange? Is it the tie
introduced by the note splitting or the
one you specified manually? When I tried to remove the automatic note
splitting from your example,
the remaining tie looked exactly the same.
/Mats
Stefan Thomas wrote:
Dear lilypond-users,
I have a problem with ties in connection with automatic note
splitting. I don't understand why the ties in the below quoted example
look so strange:
Is it a bug?
\score {
\new Staff {
\new Voice \with {
\remove Note_heads_engraver
\consists Completion_heads_engraver
}
r2
r2 e c' 4 f des' 8 des' ees' 4 - c' e'
r8 e c' 4 f des' 8 des' ees' 4 - c' e' b f'
r8 r4
r2 e c' 4 f des' 8 des' ees' 8~ - des' ees' 8
c' e'
} %staff ende
}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: markup dynamics wrong size
In addition to my previous answer: The size of the markup text is larger
since the template contains
the line:
\override TextScript #'font-size = #2
If you just remove that line, you should get the same size as the normal
dynamics.
The question is why the setting was done in the first place. Perhaps
it's just a remainder
from some ancient version where this setting made sense, and nobody has
used the
template with text or \markup command lately.
/Mats
Eric Flesher wrote:
Wondering if anyone has experienced the following problem:
When creating new centered dynamics in a piano staff in ver. 2.11.55
(and several earlier versions) using \markup, three things happen:
1. the markup text created is significantly larger than the normal
dynamic size
2. the text does not align with other dynamic markings
3. the presence of the markup text forces additional space between the
staves
The dynamic marking concerned is contained in a variable thus:
pocoF = \markup { \italic poco \dynamic f }
and is deployed locally as follows:
\times 4/5 { s16 s\mp s s-\pocoF s\ } \times 4/5 { s8\! s\mp s16 } s4
(I would include more code, but the file is extremely long.)
Any idea what might be wrong here, and how this could be fixed?
Thanks,
EF
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Downloading
I am using a Mac computer OS 10 version 8. Can I download lilypond? Thanks for answering Dolores Dickey ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
timing, lyrics, chords, melody
Hi,
Trying to make my first lilypond song and put let it be on score but I
can't make the timing of the lyrics fit with the melody... :
\version 2.11.53
melody = \relative c' {
\clef treble
\key c \major
\time 4/4
\partial 4
g8 a c4 c d a c c d e f f f e e d d2 e4 e f e e d2
e4 d4 c2
}
harmony = \chordmode { r8 r c2 g
a:min f4:maj7f:6
c2 g f c
}
text = \lyrics {When I find my-self in times of trou-ble,
Mother Mary comes to me,
Speaking words of wishdom
let it be.
}
\score {
\new ChordNames {
\harmony
}
\new Staff {\melody }
\new Lyrics { \text }
\layout { }
\midi { }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: NR 1.3 Expressive marks, second draft
On Wed, Aug 6, 2008 at 1:44 AM, Mats Bengtsson [EMAIL PROTECTED] wrote:
- The markup command for \roundf is unnecessarily complicated and the result
looks bad. The \center-align markup command is intended to produce a column
of (internally) center aligned markups. If you only have a single line
markup, then you should use \hcenter instead. Also, the spacing between the
parenthesis and the f is probably unintended. Finally, there are some
redundant braces (that you may want to keep for readability). I would
propose to instead use
roundf = \markup { \hcenter \concat { \bold { \italic ( }
\dynamic f \bold { \italic ) } } }
or (without the redundant braces)
roundf = \markup { \hcenter \concat { \bold \italic (
\dynamic f \bold \italic ) } }
Yes, that does look a lot better. Thanks.
- The main reason to use make-dynamic-script instead of a pure \markup is
not to get the horizontal alignment correct with respect to the note head,
but to get correct vertical positioning when you have both an absolute
dynamic and a hairpin starting/ending on the same note, for example. Compare
the following two examples to see the difference:
roundf = \markup { \hcenter \concat { \normal-text \bold \italic (
\dynamic f \normal-text \bold \italic ) } }
boxf = \markup { \bracket { \dynamic f } }
roundfdyn = #(make-dynamic-script roundf)
boxfdyn = #(make-dynamic-script boxf)
\relative c' {
c4_\roundf \ d e f
g,1_\boxf \!
c4_\roundfdyn \ d e f
g,1_\boxf \!
}
Okay, I see.
- As illustrated in the example above, it's not absolutely necessary to
learn the Scheme syntax of the markup commands to use make-dynamic-script. A
simpler solution is to first define a normal markup, and then use that as
the argument to make-dynamic-script.
This is really great! Thanks for your insight, Mats. I will
incorporate this into the docs.
-Patrick
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [PATCH] Re: Duration dots and Bar lines on custom Staves.
2008/7/27 Han-Wen Nienhuys [EMAIL PROTECTED]:
I don't understand the original code. 'me' should already be the
staff-symbol
That's only true for Staff_symbol_referencer::on_line () before the patch.
The revised version, Staff_symbol::on_line (), deals with two separate
cases, i.e., standard staves with 'line-count and exotic staves with
'line-positions. It doesn't return the correct boolean value when
called for ties and dots, since in these cases 'me' isn't the
staff-symbol and line_count (me) will be zero here:
return ((abs (pos + line_count (me)) % 2) == 1);
You can see the result in the regtest example below (based on current
git); as it stands, on_line () only works properly when
'line-positions is set.
As a better solution than the quick fix I posted previously, I propose
moving on_line () back to staff-symbol-referencer.cc and creating a
new method get_line_positions () to retrieve 'line-positions safely.
Is this patch OK?
Regards,
Neil
From b2b04a389c16bb93e54028a6fd931eeb565a8090 Mon Sep 17 00:00:00 2001
From: Neil Puttock [EMAIL PROTECTED]
Date: Wed, 6 Aug 2008 22:09:48 +0100
Subject: [PATCH] Revised fix for Staff_symbol_referencer::on_line ()
---
lily/include/staff-symbol-referencer.hh |3 +-
lily/include/staff-symbol.hh|1 -
lily/staff-symbol-referencer.cc | 35 ++-
lily/staff-symbol.cc| 30 --
4 files changed, 36 insertions(+), 33 deletions(-)
diff --git a/lily/include/staff-symbol-referencer.hh b/lily/include/staff-symbol-referencer.hh
index 4a43a94..8ae0ed8 100644
--- a/lily/include/staff-symbol-referencer.hh
+++ b/lily/include/staff-symbol-referencer.hh
@@ -39,7 +39,8 @@ public:
static Real get_position (Grob *);
static Real staff_radius (Grob *);
static int get_rounded_position (Grob *);
- static Interval extent_in_staff (Grob *);
+ static Interval extent_in_staff (Grob *);
+ static SCM get_line_positions (Grob *);
};
int compare_position (Grob *const , Grob *const );\
diff --git a/lily/include/staff-symbol.hh b/lily/include/staff-symbol.hh
index 6791e7b..4dacde8 100644
--- a/lily/include/staff-symbol.hh
+++ b/lily/include/staff-symbol.hh
@@ -24,7 +24,6 @@ public:
static int get_steps (Grob *);
static int line_count (Grob *);
- static bool on_line (Grob *me, int pos);
DECLARE_SCHEME_CALLBACK (print, (SCM));
DECLARE_SCHEME_CALLBACK (height, (SCM));
DECLARE_GROB_INTERFACE();
diff --git a/lily/staff-symbol-referencer.cc b/lily/staff-symbol-referencer.cc
index dbff024..81ad054 100644
--- a/lily/staff-symbol-referencer.cc
+++ b/lily/staff-symbol-referencer.cc
@@ -20,6 +20,15 @@ Staff_symbol_referencer::line_count (Grob *me)
return st ? Staff_symbol::line_count (st) : 0;
}
+SCM
+Staff_symbol_referencer::get_line_positions (Grob *me)
+{
+ Grob *st = get_staff_symbol (me);
+ return st
+? st-get_property (line-positions)
+: SCM_EOL;
+}
+
bool
Staff_symbol_referencer::on_line (Grob *me)
{
@@ -35,7 +44,31 @@ Staff_symbol_referencer::on_staff_line (Grob *me)
bool
Staff_symbol_referencer::on_line (Grob *me, int pos)
{
- return Staff_symbol::on_line (me, pos);
+ SCM line_positions = get_line_positions (me);
+ if (scm_is_pair (line_positions))
+{
+ Real min_line = HUGE_VAL;
+ Real max_line = -HUGE_VAL;
+ for (SCM s = line_positions; scm_is_pair (s); s = scm_cdr (s))
+ {
+ Real current_line = scm_to_double (scm_car (s));
+ if (pos == current_line)
+ return true;
+ if (current_line max_line)
+ max_line = current_line;
+ if (current_line min_line)
+ min_line = current_line;
+
+ }
+ if (pos min_line)
+ return (( (int) (rint (pos - min_line)) % 2) == 0);
+ if (pos max_line)
+ return (( (int) (rint (pos - max_line)) % 2) == 0);
+
+ return false;
+}
+ else
+return ((abs (pos + Staff_symbol_referencer::line_count (me)) % 2) == 1);
}
bool
diff --git a/lily/staff-symbol.cc b/lily/staff-symbol.cc
index 6fefc48..a22c24b 100644
--- a/lily/staff-symbol.cc
+++ b/lily/staff-symbol.cc
@@ -167,36 +167,6 @@ Staff_symbol::height (SCM smob)
return ly_interval2scm (y_ext);
}
-bool
-Staff_symbol::on_line (Grob *me, int pos)
-{
- SCM line_positions = me-get_property (line-positions);
- if (scm_is_pair (line_positions))
-{
- Real min_line = HUGE_VAL;
- Real max_line = -HUGE_VAL;
- for (SCM s = line_positions; scm_is_pair (s); s = scm_cdr (s))
- {
- Real current_line = scm_to_double (scm_car (s));
- if (pos == current_line)
- return true;
- if (current_line max_line)
- max_line = current_line;
- if (current_line min_line)
- min_line = current_line;
-
- }
- if (pos min_line)
- return (( (int) (rint (pos - min_line)) % 2) == 0);
- if (pos max_line)
- return (( (int) (rint (pos - max_line)) % 2) == 0);
-
- return false;
-}
- else
-return ((abs (pos + line_count (me)) % 2) == 1);
-}
-
ADD_INTERFACE
Re: NR 1.3 Expressive marks, second draft
On Mon, Aug 4, 2008 at 7:51 AM, Francisco Vila [EMAIL PROTECTED] wrote: 2008/8/3 Trevor Daniels [EMAIL PROTECTED]: Hi Francisco Not a bad suggestion. I've tried to fix the issues you mentioned - still not perfect, but better. Revised code attached. Trevor: great. Measures filled of eighth notes are much prettier in my original, here I suppose that the shortest common duration is 1/8, otherwise all noteheads look as if they were left shifted, but I don't know where exactly to put the setting. This would also fix the two fortissimos crossed by the bar line. Hi Franciso, Trevor, I will try improving this in the near future. Thanks for your contributions! -Patrick ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
