Documentation of music functions
In the NR 6.3.3. and 6.3.4., there are nice examples of building a music function. The music functions are documented with standard Scheme doc strings: funcName = #(define-music-function (parser location var-list) (var-types?) "This is the doc string for the function." return-value) In ly/music-function-init.ly, the music functions are documented differently: funcName = #(define-music-function (parser location var-list) (var-types?) (_i "This is the doc string for the function.") return-value) What is the difference between these two syntaxes, and which should I use to add doc-strings to addChordShape, storePredefinedDiagram, pointAndClickOn, and pointAndClickOff, which are predefineds I created? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
NR5 and 6 feedback
I don't know who's been editing NR5, but it's really nice! I was using it
to make some tweaks, and I really appreciate the improved quality it has
since a couple of years ago.
I really think that LilyPond's documentation is pretty close to excellent
now. I can find what I need and figure out how to do things. Thanks to all
who have worked on it, especially Graham for setting out the policies that
make the docs really useful.
I have some suggestions for whomever is doing NR5 and 6. If nobody is, I'll
be happy to make the changes myself, but I don't want to step on somebody
else's toes.
In the section on break-visibility in NR 5.4.6, 7 of the 8 possible values
for the break-visibility property are shown, along with a statement that
center-visible (the value of which is never defined, and must be inferred by
the reader) is not predefined.
It seems to me that we ought to go ahead and define center-visible in
scm/output-lib.scm and add it to the table. It would make that section
easier to read and more complete.
Second issue: In NR 6.1.1, Overview of music functions, the list of
argument types includes pair? which is ascribed to "A pair of variables". I
think it would be better to say "A Scheme pair, which includes lists." The
pair? check is preferred to the list? check because it's faster.
Also, in NR 6.1.1, I get a bit of a misunderstanding. 6.1.1 is supposed to
be an overview of all music functions, but it says:
--- Beginning of quote
Making a function which substitutes a variable into LilyPond code is easy.
The general form of these functions is
function =
#(define-music-function (parser location var1 var2...vari... )
(var1-type? var2-type?...vari-type?...)
#{
...music...
#})
where
variith variable
vari-type?type of ith variable
...music...normal LilyPond input, using variables as #$var1, etc.
End of quote
This is the general form only for "variable substitution" type functions,
because it mentions #{ ...#} which is only used when writing LilyPond
input-style music. Lots of other music styles can be written instead. In
fact, most of the functions I write just use Scheme music definitions. I
think the "variable substitution type functions are described in NR6.1.2.,
so I think this definition should be moved to NR 6.1.2.
I think that NR 6.1.1. should contain something like the following:
Music functions can be defined to simplify repetitive tasks and to allow a
greater degree of control over LilyPond output. Music functions will often
be used when a simple LilyPond variable definition cannot achieve the
desired result.
Music functions can be as simple as variable substitution expressions.
They can also use the full power of Scheme. This section describes some
common uses for music functions and provides some examples as a guide for
creating music functions.
End of recommended text for NR 6.1.1.
I think the title of section 6.1.7. should be changed to "Predefined music
functions" instead of "Available music functions". And I think the
introductory text:
"The following commands are music functions"
Should be changed to:
"The following commands are predefined music functions. The definitions for
these functions are found in ly/*-init.ly."
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
More suggestions for NR 6
Section NR 6.4.3, at the end of known issues and warnings, should add the following: "One workaround for this problem is to put the arguments into a Scheme list: #(define-markup-command (foo layout props arg-list) (pair?) ...) You could then apply it as \markup \foo #'(1 "bar" 2 "baz") Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
NR 6.5.2., 6.7
I read NR 6.5.2 and couldn't understand the example. It describes the usage of applyOutput, and presents a function for its use, but never shows how it is applied. An actual example here would be wonderful. N.R 6.7 shows the use of Scheme code as an articulation. The reason why this works is unclear to me, but I can see there is some power here. An explanation would be really helpful. The articulation that is added is not a Scheme function, but rather the return part of a Scheme function. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation of music functions
2008/11/5 Carl D. Sorensen <[EMAIL PROTECTED]>: > (_i "This is the doc string for the function.") > What is the difference between these two syntaxes, and which should I use to > add doc-strings to addChordShape, storePredefinedDiagram, pointAndClickOn, > and pointAndClickOff, which are predefineds I created? Doesn't (_i "") provide gettext localization for doc strings? (In which case it makes sense not to mention it in the NR, since it is meant for users and not for multi-language developers.) Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation of music functions
On 11/5/08 8:33 AM, "Valentin Villenave" <[EMAIL PROTECTED]> wrote: > 2008/11/5 Carl D. Sorensen <[EMAIL PROTECTED]>: > >> (_i "This is the doc string for the function.") > >> What is the difference between these two syntaxes, and which should I use to >> add doc-strings to addChordShape, storePredefinedDiagram, pointAndClickOn, >> and pointAndClickOff, which are predefineds I created? > > Doesn't (_i "") provide gettext localization for doc strings? (In > which case it makes sense not to mention it in the NR, since it is > meant for users and not for multi-language developers.) Thanks for answering my questions. So I guess that developers should write the doc strings without the _i, and the translators will add the _i when they translate the doc string? I wasn't asking for this documentation in the NR, but it needs to be somewhere, IMO. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation of music functions
2008/11/5 Carl D. Sorensen <[EMAIL PROTECTED]>: > Thanks for answering my questions. So I guess that developers should write > the doc strings without the _i, and the translators will add the _i when > they translate the doc string? ... Or developers can write doc strings with _i anyway, just in case someone wants to translate them at some later point. That being said, I can't remember having seen any Scheme function localized yet (whereas the C++ code it generally well localized, though not necessarily translated). > I wasn't asking for this documentation in the NR, but it needs to be > somewhere, IMO. As a matter of fact, doc strings for music-functions are currently not gathered anywhere AFAICT (unlike markup commands, or instance). So localizing them or not doesn't really matter; moreover automatically-generated doc pages (such as the IR and NR Appendices) will probably never be translated (not in decades to come, at least). Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: share note stem between voice
I have copied this to devel, as well as to user, because I'd like to get
permission to add the function setHeadColor to ly/music-function-init.ly.
On 11/3/08 5:51 AM, "Daniel Cheng" <[EMAIL PROTECTED]> wrote:
> It have some special feature, and I want to replicate it.
>
> See http://img235.imageshack.us/my.php?image=stemnr2.png
>
> Red note-heads are voice 1, Blue note-head are voice 2.
>
> As you can see:
>- both voice share the same stem
>- the stem directory always towards voice 2
>- when two voice are on the same note, two stem are drew
>
> I know I can use the \stemUp / \stemDown to do this manually,
> but I want to know if there are any easier ways.
At first I thought it would be trivial to do this, but all of the
straightforward ways I tried didn't work the way I wanted them to.
\override applies to all noteheads in the current voice at the current
moment, so I couldn't get two different color notes on the same stem in the
same voice.
When I used two music expressions in parallel with << \\ >>, the stems on
the three eighth notes in the second measure were in opposite directions for
the two voices.
When I used two music expressions is parallel with << \\ >> and \oneVoice, I
got two sets of beams/flags.
The answer I finally arrived at is to put both sets of the notes in the same
voice so they share stems properly, but in separate music expressions so I
can change their colors using a music function.
So I finally wrote a music function to color all of the note heads in a
music expression using tweaks. I think it gives just what you want. Here's
an example:
% Beginning of LilyPond code
\version "2.11.64"
% Here we define music functions to set the notehead color
% for a note.
setHeadColor =
#(define-music-function (parser location note-head-color music)
(pair? ly:music?)
(_i "Set all note-heads in @code{music} to @code{not-head-color}.")
; set-notehead-color is a helper function
; use let and lambda definition for set-notehead-color because
; define-music-function won't let user do define at top level
; and I have no variables I want to define in the let block
(let ((set-notehead-color (lambda (head-color music)
(if (music-is-of-type? music 'note-event)
(begin
(set! (ly:music-property music 'tweaks)
(acons 'color head-color
(ly:music-property music 'tweaks)))
music)
music
;main body of function
(music-map (lambda (y) (set-notehead-color note-head-color y))
music)))
% End of music function definition
voiceOneNotes = \relative c' {
\time 3/4
f4 e8 e4 g8 |
d8 d d g4 a8 |
c2 r4
}
voiceTwoNotes = \relative c' {
\time 3/4
d4 b8 b4 e8 |
g8 g g d4 d8 |
c'2 r4
}
\score {
\new Voice {
<<
{
\setHeadColor #blue \voiceOneNotes
}
{
\setHeadColor #red \voiceTwoNotes
}
>>
}
}
% End of LilyPond code
HTH,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation of music functions
On 11/5/08 8:49 AM, "Valentin Villenave" <[EMAIL PROTECTED]> wrote: > 2008/11/5 Carl D. Sorensen <[EMAIL PROTECTED]>: > >> Thanks for answering my questions. So I guess that developers should write >> the doc strings without the _i, and the translators will add the _i when >> they translate the doc string? > > ... Or developers can write doc strings with _i anyway, just in case > someone wants to translate them at some later point. That being said, > I can't remember having seen any Scheme function localized yet > (whereas the C++ code it generally well localized, though not > necessarily translated). There are some _i strings in scm/music-functions.scm, which is how I knew to even ask the questions. > >> I wasn't asking for this documentation in the NR, but it needs to be >> somewhere, IMO. > > As a matter of fact, doc strings for music-functions are currently not > gathered anywhere AFAICT (unlike markup commands, or instance). So > localizing them or not doesn't really matter; moreover > automatically-generated doc pages (such as the IR and NR Appendices) > will probably never be translated (not in decades to come, at least). There is a page in the NR (NR 6.1.7) which appears to be a gathering of doc-strings in the file identifiers.tely. That's what got me started on this whole issue. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR5 and 6 feedback
Carl
I'm partly through editing NR 5 but I broke off to try to complete NR 1.2
and other sections in NR 1 and NR 2, which I see as needing to be finished
before 2.12. No one has yet touched NR 6, apart from perhaps dumping things
in here from elsewhere. It would be really great if you could adopt NR 6
and bring it to the standard of the rest of the docs. Then, if I haven't
got back to NR 5 by then I'd be happy for you to add to that too, but it's
really NR 6 that needs attention right now. You'd be ideal to do that.
I seem to remember suggesting adding center-visible some time ago, but then
it slipped away. It surely should be added for neatness, even though it's
hard to think of a use for it. I'd support your doing this.
Trevor
- Original Message -
From: "Carl D. Sorensen" <[EMAIL PROTECTED]>
To: "lily-devel"
Sent: Wednesday, November 05, 2008 1:44 PM
Subject: NR5 and 6 feedback
I don't know who's been editing NR5, but it's really nice! I was using it
to make some tweaks, and I really appreciate the improved quality it has
since a couple of years ago.
I really think that LilyPond's documentation is pretty close to excellent
now. I can find what I need and figure out how to do things. Thanks to all
who have worked on it, especially Graham for setting out the policies that
make the docs really useful.
I have some suggestions for whomever is doing NR5 and 6. If nobody is, I'll
be happy to make the changes myself, but I don't want to step on somebody
else's toes.
In the section on break-visibility in NR 5.4.6, 7 of the 8 possible values
for the break-visibility property are shown, along with a statement that
center-visible (the value of which is never defined, and must be inferred by
the reader) is not predefined.
It seems to me that we ought to go ahead and define center-visible in
scm/output-lib.scm and add it to the table. It would make that section
easier to read and more complete.
Second issue: In NR 6.1.1, Overview of music functions, the list of
argument types includes pair? which is ascribed to "A pair of variables". I
think it would be better to say "A Scheme pair, which includes lists." The
pair? check is preferred to the list? check because it's faster.
Also, in NR 6.1.1, I get a bit of a misunderstanding. 6.1.1 is supposed to
be an overview of all music functions, but it says:
--- Beginning of quote
Making a function which substitutes a variable into LilyPond code is easy.
The general form of these functions is
function =
#(define-music-function (parser location var1 var2...vari... )
(var1-type? var2-type?...vari-type?...)
#{
...music...
#})
where
variith variable
vari-type?type of ith variable
...music...normal LilyPond input, using variables as #$var1, etc.
End of quote
This is the general form only for "variable substitution" type functions,
because it mentions #{ ...#} which is only used when writing LilyPond
input-style music. Lots of other music styles can be written instead. In
fact, most of the functions I write just use Scheme music definitions. I
think the "variable substitution type functions are described in NR6.1.2.,
so I think this definition should be moved to NR 6.1.2.
I think that NR 6.1.1. should contain something like the following:
Music functions can be defined to simplify repetitive tasks and to allow a
greater degree of control over LilyPond output. Music functions will often
be used when a simple LilyPond variable definition cannot achieve the
desired result.
Music functions can be as simple as variable substitution expressions.
They can also use the full power of Scheme. This section describes some
common uses for music functions and provides some examples as a guide for
creating music functions.
End of recommended text for NR 6.1.1.
I think the title of section 6.1.7. should be changed to "Predefined music
functions" instead of "Available music functions". And I think the
introductory text:
"The following commands are music functions"
Should be changed to:
"The following commands are predefined music functions. The definitions for
these functions are found in ly/*-init.ly."
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR5 and 6 feedback
OK, NR 6 is mine.
It won't happen very fast, but I'll work on it as I can.
Carl
On 11/5/08 12:14 PM, "Trevor Daniels" <[EMAIL PROTECTED]> wrote:
> Carl
>
> I'm partly through editing NR 5 but I broke off to try to complete NR 1.2
> and other sections in NR 1 and NR 2, which I see as needing to be finished
> before 2.12. No one has yet touched NR 6, apart from perhaps dumping things
> in here from elsewhere. It would be really great if you could adopt NR 6
> and bring it to the standard of the rest of the docs. Then, if I haven't
> got back to NR 5 by then I'd be happy for you to add to that too, but it's
> really NR 6 that needs attention right now. You'd be ideal to do that.
>
> I seem to remember suggesting adding center-visible some time ago, but then
> it slipped away. It surely should be added for neatness, even though it's
> hard to think of a use for it. I'd support your doing this.
>
> Trevor
>
>
> - Original Message -
> From: "Carl D. Sorensen" <[EMAIL PROTECTED]>
> To: "lily-devel"
> Sent: Wednesday, November 05, 2008 1:44 PM
> Subject: NR5 and 6 feedback
>
>
> I don't know who's been editing NR5, but it's really nice! I was using it
> to make some tweaks, and I really appreciate the improved quality it has
> since a couple of years ago.
>
> I really think that LilyPond's documentation is pretty close to excellent
> now. I can find what I need and figure out how to do things. Thanks to all
> who have worked on it, especially Graham for setting out the policies that
> make the docs really useful.
>
> I have some suggestions for whomever is doing NR5 and 6. If nobody is, I'll
> be happy to make the changes myself, but I don't want to step on somebody
> else's toes.
>
> In the section on break-visibility in NR 5.4.6, 7 of the 8 possible values
> for the break-visibility property are shown, along with a statement that
> center-visible (the value of which is never defined, and must be inferred by
> the reader) is not predefined.
>
> It seems to me that we ought to go ahead and define center-visible in
> scm/output-lib.scm and add it to the table. It would make that section
> easier to read and more complete.
>
>
> Second issue: In NR 6.1.1, Overview of music functions, the list of
> argument types includes pair? which is ascribed to "A pair of variables". I
> think it would be better to say "A Scheme pair, which includes lists." The
> pair? check is preferred to the list? check because it's faster.
>
> Also, in NR 6.1.1, I get a bit of a misunderstanding. 6.1.1 is supposed to
> be an overview of all music functions, but it says:
>
> --- Beginning of quote
>
> Making a function which substitutes a variable into LilyPond code is easy.
> The general form of these functions is
>
> function =
> #(define-music-function (parser location var1 var2...vari... )
> (var1-type? var2-type?...vari-type?...)
> #{
> ...music...
> #})
> where
>
> variith variable
> vari-type?type of ith variable
> ...music...normal LilyPond input, using variables as #$var1, etc.
>
> End of quote
>
> This is the general form only for "variable substitution" type functions,
> because it mentions #{ ...#} which is only used when writing LilyPond
> input-style music. Lots of other music styles can be written instead. In
> fact, most of the functions I write just use Scheme music definitions. I
> think the "variable substitution type functions are described in NR6.1.2.,
> so I think this definition should be moved to NR 6.1.2.
>
> I think that NR 6.1.1. should contain something like the following:
>
> Music functions can be defined to simplify repetitive tasks and to allow a
> greater degree of control over LilyPond output. Music functions will often
> be used when a simple LilyPond variable definition cannot achieve the
> desired result.
>
> Music functions can be as simple as variable substitution expressions.
> They can also use the full power of Scheme. This section describes some
> common uses for music functions and provides some examples as a guide for
> creating music functions.
>
> End of recommended text for NR 6.1.1.
>
> I think the title of section 6.1.7. should be changed to "Predefined music
> functions" instead of "Available music functions". And I think the
> introductory text:
>
> "The following commands are music functions"
>
> Should be changed to:
>
> "The following commands are predefined music functions. The definitions for
> these functions are found in ly/*-init.ly."
>
>
> Thanks,
>
> Carl
>
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Remarks about the building process
Some nitpicks during the building process, on a fresh repository: 1- the configure script: For a long time now, I always get this: configure: WARNING: autoconf <= 2.59 with g++ >= 3.3 gettext test broken. configure: WARNING: Trying gcc, cross fingers. It does not break anything; it is just boring since: # autoconf --version autoconf (GNU Autoconf) 2.61 # g++ --version g++ (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) I consider this kind of thing might even become "dangerous": as we say in French: " A force de crier au loup..." (after having yelled so often at the wolf...) 2- The make stage: I don't report this kind of warnings: conversion to 'xx' from 'yy' may alter its value or part-combine-iterator.cc:22: warning: 'typedef' was ignored in this declaration but those ones just bother me, since I am unable to analyze what is going on: key-engraver.cc: In member function 'void Key_engraver::create_key(bool)': key-engraver.cc:83: warning: suggest parentheses around && within || [...] note-collision.cc: In function 'void check_meshing_chords(Grob*, Drul_array > >*, const Drul_array, std::allocator > > >&, const Drul_array > >&)': note-collision.cc:292: warning: suggest explicit braces to avoid ambiguous 'else' [...] vaticana-ligature-engraver.cc: In member function 'virtual void Vaticana_ligature_engraver::transform_heads(Spanner*, std::vector >)': vaticana-ligature-engraver.cc:561: warning: suggest explicit braces to avoid ambiguous 'else' vaticana-ligature-engraver.cc:678: warning: suggest explicit braces to avoid ambiguous 'else' [...] volta-repeat-iterator.cc: In member function 'void Volta_repeat_iterator::add_repeat_command(scm_unused_struct*)': volta-repeat-iterator.cc:69: warning: suggest parentheses around && within || flex -Cfe -p -p -oout/lexer.cc lexer.ll lexer.ll:595: multiple <> rules for start condition longcomment lexer.ll:621: warning, rule cannot be matched lexer.ll:624: warning, rule cannot be matched lexer.ll:693: warning, -s option given but default rule can be matched I truly hope someone understands my questioning. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation of music functions
Hi Carl, 2008/11/5 Carl D. Sorensen <[EMAIL PROTECTED]>: > There are some _i strings in scm/music-functions.scm, which is how I knew to > even ask the questions. Unfortunately, the internationalization macro doesn't work; any function using it ends up with the description `Undocumented; FIXME'. I posted a thread about this a while ago (http://lists.gnu.org/archive/html/lilypond-devel/2008-07/msg00185.html), but nobody replied. :) I've had a hunt around the docs generation files, but can't work out why it's broken. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation of music functions
On 2008/11/05 20:04 +, Neil Puttock wrote: > Unfortunately, the internationalization macro doesn't work; any > function using it ends up with the description `Undocumented; FIXME'. > I posted a thread about this a while ago > (http://lists.gnu.org/archive/html/lilypond-devel/2008-07/msg00185.html), > but nobody replied. :) > > I've had a hunt around the docs generation files, but can't work out > why it's broken. When I get to fully internationalize automatically generated documentation, I'll have to look at this, but there are more urgent TODOs on the i18n front. (my useless post of the day :-P) Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCHES] Re: Remarks about the building process
On 2008/11/05 20:57 +0100, Jean-Charles Malahieude wrote:
> Some nitpicks during the building process, on a fresh repository:
>
>
> 1- the configure script:
> For a long time now, I always get this:
>
> configure: WARNING: autoconf <= 2.59 with g++ >= 3.3 gettext test broken.
> configure: WARNING: Trying gcc, cross fingers.
>
> It does not break anything; it is just boring since:
>
> # autoconf --version
> autoconf (GNU Autoconf) 2.61
>
> # g++ --version
> g++ (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
>
> I consider this kind of thing might even become "dangerous":
> as we say in French: " A force de crier au loup..." (after having yelled
> so often at the wolf...)
It looks like the wolf has been killed, the second attached patch works
for me; is it OK to apply it to master? I don't know whether autoconf
2.60 gettext/g++ test has been fixed, I assumed it's not for the sake of
safety.
> 2- The make stage:
>
> I don't report this kind of warnings:
> conversion to 'xx' from 'yy' may alter its value
> or
> part-combine-iterator.cc:22: warning: 'typedef' was ignored in this
> declaration
>
>
> but those ones just bother me, since I am unable to analyze what is
> going on:
> I truly hope someone understands my questioning.
My zen answer is
http://www.nojhan.net/geekscottes/index.php?strip=7
Quick translation for non-French readers:
— What comes after death do you think?
— I believe you are reincarned in a world where all GNU software
compiles with no warning.
— Would it happen because you've been good or you've been nasty?
See also the other attached patch.
Cheers,
John
diff --git a/lily/key-engraver.cc b/lily/key-engraver.cc
index d3b7eb0..cbd55d0 100644
--- a/lily/key-engraver.cc
+++ b/lily/key-engraver.cc
@@ -79,8 +79,8 @@ Key_engraver::create_key (bool is_default)
SCM new_alter_pair = scm_assoc (scm_caar (s), key);
Rational old_alter = robust_scm2rational (scm_cdar (s), 0);
if (new_alter_pair == SCM_BOOL_F
- || extranatural
- && (ly_scm2rational (scm_cdr (new_alter_pair)) - old_alter)*old_alter < Rational (0))
+ || (extranatural
+ && (ly_scm2rational (scm_cdr (new_alter_pair)) - old_alter)*old_alter < Rational (0)))
{
*tail = scm_cons (scm_car (s), *tail);
tail = SCM_CDRLOC (*tail);
diff --git a/lily/note-collision.cc b/lily/note-collision.cc
index 7abcc2a..5434442 100644
--- a/lily/note-collision.cc
+++ b/lily/note-collision.cc
@@ -290,20 +290,22 @@ check_meshing_chords (Grob *me,
{
Grob *staff = Staff_symbol_referencer::get_staff_symbol (me);
if (!Staff_symbol_referencer::on_line (staff, ups[0]))
- /*
- TODO: consider junking the else body.
- */
- if (to_boolean (me->get_property ("prefer-dotted-right")))
- {
- shift_amount = 0.5;
- }
- else
- {
- Grob *d = unsmob_grob (head_up->get_object ("dot"));
- Grob *parent = d->get_parent (X_AXIS);
- if (Dot_column::has_interface (parent))
- Side_position_interface::add_support (parent, head_down);
- }
+ {
+ /*
+ TODO: consider junking the else body.
+ */
+ if (to_boolean (me->get_property ("prefer-dotted-right")))
+ {
+ shift_amount = 0.5;
+ }
+ else
+ {
+ Grob *d = unsmob_grob (head_up->get_object ("dot"));
+ Grob *parent = d->get_parent (X_AXIS);
+ if (Dot_column::has_interface (parent))
+ Side_position_interface::add_support (parent, head_down);
+ }
+ }
}
/* For full or close half collisions, the right hand head may
diff --git a/lily/skyline.cc b/lily/skyline.cc
index 5297f63..362fbba 100644
--- a/lily/skyline.cc
+++ b/lily/skyline.cc
@@ -45,6 +45,7 @@
/* If we start including very thin buildings, numerical accuracy errors can
arise. Therefore, we ignore all buildings that are less than epsilon wide. */
#define EPS 1e-5
+#define EPSNULL 1e-12
static void
print_buildings (list const &b)
@@ -215,6 +216,9 @@ Skyline::internal_merge_skyline (list *s1, list *s2,
if (end >= s1->front ().end_)
s1->pop_front ();
+ if (abs (end - x) < EPSNULL)
+ break;
+
x = end;
}
result->reverse ();
diff --git a/lily/tie-formatting-problem.cc b/lily/tie-formatting-problem.cc
index 6aa5feb..fbd34c1 100644
--- a/lily/tie-formatting-problem.cc
+++ b/lily/tie-formatting-problem.cc
@@ -644,6 +644,7 @@ Tie_formatting_problem::score_aptitude (Tie_configuration *conf,
if (ties_conf
&& ties_conf->size () == 1)
+do
{
Direction d = LEFT;
Drul_array stems (0, 0);
diff --git a/lily/vaticana-ligature-engraver.cc b/lily/vaticana-ligature-engraver.cc
index c812684..d80d0da 100644
--- a/lily/vaticana-ligature-engraver.cc
+++ b/lily/vaticana-ligature-engraver.cc
@@ -550,66 +550,70 @@ Vaticana_ligature_engraver::transform_heads (Spanner *ligature,
else
glyph_name = "vaticana.inclinatum";
else if (prefix_set & DEMINUTUM)
- if (i == 0)
- {
- // initio debilis
- glyph_name = "vaticana.reverse.plica";
- }
- else if (prev
Re: share note stem between voice
Carl D. Sorensen wrote:
I have copied this to devel, as well as to user, because I'd like to get
permission to add the function setHeadColor to ly/music-function-init.ly.
Sorry for my bad English.
What I was asking is the stem directory (stem up / down),
not the color.
thank you anyway.
On 11/3/08 5:51 AM, "Daniel Cheng" <[EMAIL PROTECTED]> wrote:
It have some special feature, and I want to replicate it.
See http://img235.imageshack.us/my.php?image=stemnr2.png
Red note-heads are voice 1, Blue note-head are voice 2.
As you can see:
- both voice share the same stem
- the stem directory always towards voice 2
- when two voice are on the same note, two stem are drew
I know I can use the \stemUp / \stemDown to do this manually,
but I want to know if there are any easier ways.
At first I thought it would be trivial to do this, but all of the
straightforward ways I tried didn't work the way I wanted them to.
\override applies to all noteheads in the current voice at the current
moment, so I couldn't get two different color notes on the same stem in the
same voice.
When I used two music expressions in parallel with << \\ >>, the stems on
the three eighth notes in the second measure were in opposite directions for
the two voices.
When I used two music expressions is parallel with << \\ >> and \oneVoice, I
got two sets of beams/flags.
The answer I finally arrived at is to put both sets of the notes in the same
voice so they share stems properly, but in separate music expressions so I
can change their colors using a music function.
So I finally wrote a music function to color all of the note heads in a
music expression using tweaks. I think it gives just what you want. Here's
an example:
% Beginning of LilyPond code
\version "2.11.64"
% Here we define music functions to set the notehead color
% for a note.
setHeadColor =
#(define-music-function (parser location note-head-color music)
(pair? ly:music?)
(_i "Set all note-heads in @code{music} to @code{not-head-color}.")
; set-notehead-color is a helper function
; use let and lambda definition for set-notehead-color because
; define-music-function won't let user do define at top level
; and I have no variables I want to define in the let block
(let ((set-notehead-color (lambda (head-color music)
(if (music-is-of-type? music 'note-event)
(begin
(set! (ly:music-property music 'tweaks)
(acons 'color head-color
(ly:music-property music 'tweaks)))
music)
music
;main body of function
(music-map (lambda (y) (set-notehead-color note-head-color y))
music)))
% End of music function definition
voiceOneNotes = \relative c' {
\time 3/4
f4 e8 e4 g8 |
d8 d d g4 a8 |
c2 r4
}
voiceTwoNotes = \relative c' {
\time 3/4
d4 b8 b4 e8 |
g8 g g d4 d8 |
c'2 r4
}
\score {
\new Voice {
<<
{
\setHeadColor #blue \voiceOneNotes
}
{
\setHeadColor #red \voiceTwoNotes
}
>>
}
}
% End of LilyPond code
HTH,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
compilation error
With current git: Reading MusicXML from 00a-Basics-Pitches.xml ... Converting to LilyPond expressions... Traceback (most recent call last): File "../../../scripts/musicxml2ly.py", line 2518, in main() File "../../../scripts/musicxml2ly.py", line 2513, in main voices = convert (filename, options) File "../../../scripts/musicxml2ly.py", line 2432, in convert score = extract_score_structure (mxl_pl, staff_info) File "../../../scripts/musicxml2ly.py", line 311, in extract_score_structure score = musicexp.Score () AttributeError: 'module' object has no attribute 'Score' I'm using python 2.5. Probably Jan's last change is problematic? --- a/python/musicexp.py +++ b/python/musicexp.py @@ -1618,7 +1618,7 @@ class RhythmicStaff (Staff): def __init__ (self, command = "RhythmicStaff"): Staff.__init__ (self, command) -class Score (): +class Score: def __init__ (self): self.contents = None self.create_midi = False Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
